A few days ago I extracted a lot of functions I’m using in 2 different projects (one large phoenix LiveView project and a small PETAL app)
It basically answers to the following needs:
quickly package UI code into live_components
make components extensible from the templates (in the spirit of Tailwind & Alpine)
less boilerplate possible.
I first tried Surface, and even if I was impressed, it felt too heavy for me (btw it has more line of codes than LiveView itself) and I’d really prefer to stay closer to the underlying library (LiveView)
Just released 0.9.0 with new forward_assign/2 that will help writing nested components (you often need to propagate part of assigns to a child component)
Feature-wise there is now everything I wanted in this library.
It just needs a bit more example & documentation before a proper 1.0 release
I have a form I need to refactor and I might give it a shot while testing your library.
Thanks for continuing working on it and giving us heads-up, I missed the other announcements.
A glimpse of some of the components we’re writing with phx_component_helpers
A table with infinite scroll, sticky headers, sorting, filtering, placeholder, result counter … coming for really cheap to our front-end developpers
Code source is really neat with proper component encapsulation
As we started to get an ever growing list of components and were also looking to get stronger UI guidelines (I’m looking at you Tailwind colors ) we built our own storybook (inspired from React’s)
Thanks for this table sample. I was wondering how to handle the headers of a table and you gave me some good pointers.
I had mentioned a form refactor to dig a bit on your library but decided to start with a table. Seemed less complicated.
Don’t be shy on the examples when you get time, they sure help understanding how to properly use the library!
edit: @cblavier Sorry to ping you but I wanted to check something before going hammer here:
Am I’m right in assuming that your are passing the headers: [id: "ID", ...] as a normal assign with Map.put(assigns, :headers, assigns.headers) and not with any kind of helper function you provide within the library?
Something like:
def update(assigns, socket) do
assigns =
assigns
|> extend_class("some-class")
|> Map.put(:headers, assigns.headers)
{:ok, assign(socket, assigns)}
end
And then in your render/1 you do a comprehension with for {k, v} <- assigns.headers do?
Did I get it right?
And if this is the case, any reason you’re doing your headers with a keyword list instead of a simple list?
If some people here are interested, yes we might indeed open-source this live_components storybook in a foreseeable future.
But like the original storybook, it would be an empty shell that you’ll be able to fill with your own components. The components we’re developing, even if somewhat generic, are really closely fitting to our business needs.
I really like the storybook concept thus I would like to see it public if possible.
I started a library like yours only for my personal projects, but each time I see one of your posts here I think in making the switch, and now this storybook is really enticing me