Simplify React and Phoenix using Inertia JS: A quick look
Вставка
- Опубліковано 29 чер 2024
- Some of the hardest parts of React development are routing and data fetching. The Inertia JS library, originally from the Laravel community, was recently brought to Phoenix by the folks behind SavvyCal.
Join me as I walk through a couple of demos that show how Inertia can fit into modern monolithic applications.
Links
Screen recording software I use (affiliate): screen.studio/@Yy75o
Project source repo: github.com/ChristianAlexander...
Inertia Phoenix docs: hexdocs.pm/inertia
Inertia Site: inertiajs.com/
Timestamps
Intro - 00:00
Inertia Demo - 1:22
Repo Walkthrough - 3:41
Database, Forms, and Validation - 4:40
Summary / Next Steps - 5:59 - Наука та технологія
Just echoing the prior comments - this video was really well done. I had looked at inertia and didn't grok it. This video cleared that right up!
Straight to the point, that's a great video and I am definitely gonna try inertia
great format, explanative but straight to the point!
This is great! Thanks for sharing!
so cool we have an adapter that is official now.
This is a really cool stack, thanks for sharing!
Awesome!
oh snap
Please create more stuff on phoenix
It would be interesting to see a comparison between this and LiveView
I considered diving deeper into that comparison, but realized in my mind it comes down to this:
If you don’t need to use React, Vue, or a ton of JavaScript that’s hard to fit into a hook, LiveView is probably the best choice for an Elixir team.
If you have extreme client-side functionality requirements or strong latency concerns, consider Inertia.
Very nice. I wonder if it will *only* work with React, or if it will mount any type of function component?
Inertia supports React, Vue, and Svelte out of the box. The protocol is pretty simple, so I imagine one could port it to anything else with a little effort if there isn’t already an unofficial adapter out there.
I get the argument about having to use React if you are forced to use a component library (ask yourself if its worth the complexity) but whats up with all the arguments about "high latency connection"? Its not like React doesn't need to also fetch stuff from the server and in form intensive web apps there is really no difference. You load the page. Fill the form and send it to the server.
The latency stuff comes up for immediate interactivity like opening a modal. There were arguments against Rails Hotwire a few weeks ago where the Hey calendar was compared to Google Calendar. Since the modal code was included in the calendar code bundle, the time from clicking the “new event” button to the modal showing was near-instant. In a Hotwire / Liveview context, this button press event would be sent to the server and HTML would be returned.
Agreed though: if a server round trip is required for both approaches, or if the JS bundle is excessively large, the advantage may swing back toward the server-rendered approach.
“It Depends” is definitely in play here.
@@CodeAndStuff Way too many people don't like "It Depends" because they want it to be easy but engineering is not and never will be easy so its ridiculous to cling to that. Imagine saying building a house is easy and there is only 1 way for everyone.
Thanks for claryfing the thing with the Modal :). Didn't know that.