These are great, thanks!
One detail I noticed, on the new demo, the first dropdown gets cut off on the left-hand side by the limit of the browser. I’m on Mac, tried Firefox and Safari.
Might start to use these!
malloryerik
cmo
Same on mobile.
You might want to change the href="/" on the tabs etc so when someone clicks it they don’t get taken to the top of the page + reload the whole page.
File input w/error. If you round the corners of the element with the red background you might be able to clip the little red corners you get on the LHS of the button.
With regards to the JS modal component, is that actually a JS modal? It triggers the topbar page loading indicator and is very slow to display.
You might want to delay the page loading indicator as per the fly.io blog so it doesn’t appear so slow.
3
mplatts
Great feedback! We will be sure to implement all this. The modal is triggered by a live_patch … not sure you can make a modal load instantly unless you had all the insides of the modal ready to go. But usually you’d want to do some kind of database call in the handle_params call.
1
cmo
Yeah, the way I see it there are two types of modal. The type you describe and the one where you know the contents prior, which you can trigger with the JS commands. I assumed it was the second type due to the title of the page.
One other thing was in dark mode, the range slider is all grey. Maybe a coloured handle would make it look like it’s not disabled.
Pretty slick looking components 
0
thomasbrus
This is quite an interesting project. Phoenix.Component is such a great abstraction, it works really well in combination with heex templates.
I have some thoughts about Phoenix/Liveview in general but not quite sure how to sum them up yet 
I think we are in a bit of a tough spot with Phoenix/LiveView when it comes to building more advanced frontend components.
- LiveView is great but I think when a component mostly consist of frontend interactions and does not need the backend, then LiveView is an anti pattern since it introduces the possibility of lag/latency.
- This applies to modal dialogs too (since you need JS anyway to disable document scrolling, animation, etc.). Hitting a close button should always just work even when offline.
- Alpine.js get’s messy (beyond simple components)
- Stimulus.js is great but you are still writing a lot of code (it would work for modals, but not for even more advanced components, like multi select)
Another option is to wrap a React component in Stimulus, and render via Phoenix.Component, like so:
- Make a Phoenix Component with a multi_select/1 function
- Attach Stimulus controller (
data-controller="multi-select") - Render Mantine’s
<MultiSelect .. />via ReactDOM inconnect()of Stimulus controller - Some extra stuff to make it read/write value from hidden
<select>element. - Render via
<.multi_select form={...} field={...} options={...} />
It would be cool if we could leverage what is already available in React but still render it server-side, somehow. Then you could just write <MultiSelect …/> in a server side template, and it would get rendered server-side and rehydrated (kinda like Next.js) when you load the page.
I suppose my point is we are rebuilding part of what is already available in many of the great React UI libraries (such as https://mantine.dev/), but with lesser tools (tools less suitable for the job such as LiveView and Alpine.js).
These are just my thoughts as someone who enjoys writing frontend and backend code, but still prefers server-side rendered applications. Would love to hear about your thoughts.
1
cvkmohan
Nice thoughts @thomasbrus. In that sense may be svelte fits the bill better than React. It is disappearing framework 
But this, rebuilding is something that is a bit of concern to many I guess. May be webcomponents?
But undoubtedly, we are moving towards OnePersonFrameworks. Exciting times to be a Web App Developer.
1
chrismccord
Creator of Phoenix
This isn’t true. We have the JS interface as well as javascript hooks for handling purely client side interactions. Try out the tailwindUI dropdown on LiveBeats:
It features purely client-side interaction (no server trip), and it is fully accessible (keyboard nav, focus handling etc). So LiveView component libraries can be released to fully handle these kinds of things without React et al.
<.dropdown id={@id}>
<:img src={@current_user.avatar_url}/>
<:title><%= @current_user.name %></:title>
<:subtitle>@<%= @current_user.username %></:subtitle>
<:link navigate={profile_path(@current_user)}>View Profile</:link>
<:link navigate={Routes.settings_path(Endpoint, :edit)}>Settings</:link>
<:link href={Routes.session_path(Endpoint, :sign_out)} method={:delete}>
Sign out
</:link>
</.dropdown>
10
cvkmohan
Thanks @chrismccord. Wanted to answer in similar lines. I mean, I knew, for JS interface no server side trip is necessary. But, I am glad I didn’t. We could hear from horse’s mouth.
So now, we need component library - and - set of generators which use the same set of components. That will give a huge momentum.
3
thomasbrus
That’s neat, I had briefly looked at LiveView.JS but I was under the impression that it went over the wire but I see now it does not
2
cohawk
I agree.
I’ve been following this Petal Components library closely for a while now and have been thinking about purchasing the Petal PRO mostly for the generators using Petal Components (I’m really just waiting for the phx.gen.auth wrappings @mplatts & @nhoban).
But also browsing through the LiveBeats LiveView components code there are some slight differences, and an “official standard” component library would be preferred.
My .02
2