well $hit .. this quality is comparable with Fireship :O .. and it's about Elixir / Phoenix where I am switching right now from JS madness :O 🙌 perfection!
Seriously good walkthrough of the JS commands. Thank you! You mentioned that the next version of Phoenix won't come with a modal, why is that? It seems like it's a common and important component to have.
Thanks! I found out about the modal removal from core_components while researching this video. It turns out modals won't be used in UIs generated by the phx mix tasks, so this PR removed the modal when changing the generator: github.com/phoenixframework/phoenix/pull/5900
really good! the repo is super useful as well. Thanks :) as suggestions for future videos I'd be interested in phoenix streams or forms, in case it helps
I'm glad you've enjoyed the videos! It depends. I'd choose livesvelte or inertia if the project strictly requires a library that only plays well with a framework like Svelte or React, or if the team working on it has deep experience with those frameworks and timelines are tight. The best stack is the one that a team is most productive with, and tradeoffs are unavoidable. That being said, you can get a ton out of the box with LiveView JS-bailing out to hooks when / if needed. I'd definitely recommend trying out a LiveView-first approach and seeing if it meets your needs, knowing you have options.
Thanks for the feedback and the suggestion! I'll consider it in the future. In the mean time, I have covered live_svelte which has a very interesting and productive developer experience.
Great video! I have been looking into LiveView JS functionality to see if these pieces you show could be used for optimistic UI updates. Can those JS commands you show respond to the server? and could they be used for this use case shown in this video from time 3:05:26 ua-cam.com/video/jXyTIQOfTTk/v-deo.htmlsi=QrgTSO9dm-A47jf9&t=11126 Or would you need to use something like Live Svelte?
That's a bit of a tricky one. There's some documentation on optimistic UIs in the liveview docs (here: hexdocs.pm/phoenix_live_view/syncing-changes.html), but it doesn't directly cover the optimistic create use case. If you strictly want the exact same behavior as that tutorial-updating the UI with a page-local state-you probably should use something like Live Svelte or build a traditional SPA (but you can still use Phoenix Channels with it to make the comms go over a websocket and enable server-to-client push). Technically, this could be written as a phx hook, but I imagine it'd be more complicated than it would be worth. If your requirements are a bit more flexible, look at async assigns (docs: hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#module-async-operations). In my experience, most of the time spent waiting for a create operation isn't a result of a slow network link. With async assigns, you can create a placeholder assignment on the socket with a loading and error state. The server can immediately push a patch to the page to show a loading indicator or optimistic item in a table, then when the processing finishes it can patch to look like a complete entry. I'm considering making a video on async assigns in the future because it's a pretty interesting solution to things like this. Let me know if you end up pursuing any of these paths!
@@CodeAndStuff Thanks so much for the reply and info. I will look into the info you have provided. I would love to see a video on the async assigns. I am wondering if there are ways to make live view sites feel as snappy as SPAs. I find navigating live view sites a bit slow compared to spa.
Htmx and LiveView JS commands are similar, but different. While they both use HTML attributes to provide frontend and backend interactions, Htmx attributes are directly written and perform API calls. On the other hand, LiveView JS commands are written in Elixir and serialized to an HTML attribute by the LiveView renderer. These commands don't perform API calls, instead relying on the websocket connection to the corresponding server process and receiving compact diffs in response.
This is a very easy and comprehensive video, well done.
the video and examples were so well made I want to watch more.
I just found your channel and I can't believe how few subscribers you have. This is some top quality content!
Same here. Subscribed !
Wow, this is a hell of a good video. Thanks for such a detailed and easy-to-follow video. Acquired a new sub!
well $hit .. this quality is comparable with Fireship :O .. and it's about Elixir / Phoenix where I am switching right now from JS madness :O
🙌 perfection!
Thanks for the very kind feedback, and welcome to Elixir and Phoenix!
Seriously good walkthrough of the JS commands. Thank you!
You mentioned that the next version of Phoenix won't come with a modal, why is that? It seems like it's a common and important component to have.
Thanks! I found out about the modal removal from core_components while researching this video. It turns out modals won't be used in UIs generated by the phx mix tasks, so this PR removed the modal when changing the generator: github.com/phoenixframework/phoenix/pull/5900
Excellent overlap of introductory information and high-quality production!
Loved how you grouped the commands!
really good! the repo is super useful as well. Thanks :)
as suggestions for future videos I'd be interested in phoenix streams or forms, in case it helps
Thanks for the idea!
Thank you for all the great tutorials. Would you prefer doing it this way for future applications opposed to bringing in something like livesvelte?
I'm glad you've enjoyed the videos!
It depends.
I'd choose livesvelte or inertia if the project strictly requires a library that only plays well with a framework like Svelte or React, or if the team working on it has deep experience with those frameworks and timelines are tight.
The best stack is the one that a team is most productive with, and tradeoffs are unavoidable.
That being said, you can get a ton out of the box with LiveView JS-bailing out to hooks when / if needed. I'd definitely recommend trying out a LiveView-first approach and seeing if it meets your needs, knowing you have options.
Great work. Thank you.
Awesome video!
this is awesome. great job
Awesome project.
Thank you so much!!
this is so fucking cool, thanks man!
Excellent. Why no modal in the next version of Phoenix?
Looks like it's part of an effort to simplify the code generated by mix phx.gen.live.
github.com/phoenixframework/phoenix/pull/5900
I really enjoyed this video!, can you please make a video with phoenix elixir api authentication with svelte. It would be really appreciated.
Thanks for the feedback and the suggestion! I'll consider it in the future. In the mean time, I have covered live_svelte which has a very interesting and productive developer experience.
Are you hacking my brain? How do you always know what I want to know 😅
You caught me!
🔥
Why the decision to use inline render method and not have the dom elements in heex files?
It just simplifies the visuals for teaching.
Great video! I have been looking into LiveView JS functionality to see if these pieces you show could be used for optimistic UI updates. Can those JS commands you show respond to the server? and could they be used for this use case shown in this video from time 3:05:26 ua-cam.com/video/jXyTIQOfTTk/v-deo.htmlsi=QrgTSO9dm-A47jf9&t=11126 Or would you need to use something like Live Svelte?
That's a bit of a tricky one.
There's some documentation on optimistic UIs in the liveview docs (here: hexdocs.pm/phoenix_live_view/syncing-changes.html), but it doesn't directly cover the optimistic create use case.
If you strictly want the exact same behavior as that tutorial-updating the UI with a page-local state-you probably should use something like Live Svelte or build a traditional SPA (but you can still use Phoenix Channels with it to make the comms go over a websocket and enable server-to-client push).
Technically, this could be written as a phx hook, but I imagine it'd be more complicated than it would be worth.
If your requirements are a bit more flexible, look at async assigns (docs: hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#module-async-operations). In my experience, most of the time spent waiting for a create operation isn't a result of a slow network link. With async assigns, you can create a placeholder assignment on the socket with a loading and error state. The server can immediately push a patch to the page to show a loading indicator or optimistic item in a table, then when the processing finishes it can patch to look like a complete entry.
I'm considering making a video on async assigns in the future because it's a pretty interesting solution to things like this. Let me know if you end up pursuing any of these paths!
@@CodeAndStuff Thanks so much for the reply and info. I will look into the info you have provided. I would love to see a video on the async assigns. I am wondering if there are ways to make live view sites feel as snappy as SPAs. I find navigating live view sites a bit slow compared to spa.
Why does this sound like Htmx? Are these both trying to do.same thing or are different? Thank you for this video
Htmx and LiveView JS commands are similar, but different. While they both use HTML attributes to provide frontend and backend interactions, Htmx attributes are directly written and perform API calls.
On the other hand, LiveView JS commands are written in Elixir and serialized to an HTML attribute by the LiveView renderer. These commands don't perform API calls, instead relying on the websocket connection to the corresponding server process and receiving compact diffs in response.
@CodeAndStuff Thank you very much for explaining this. Appreciate your efforts.
Then this is closer to SignalR
LV makes JS front-end more chaotic
Yours are the best tutorials on elixir man.
I would really love to work with elixir instead of java :(
Thanks! I’d love to write Elixir at work too, but companies love their JS, Python, Ruby, etc…
Some day Elixir will catch on!
at 12:47 you make the comment that the next version of phoenix won't include a modal by default. Where can I read more about that plan?
x.com/rootcert/status/1836035549377003551
github.com/phoenixframework/phoenix/pull/5900