@mbuhot is giving a talk about Inertia.js at Elixir Sidney this week.

Youtube link for the meetup talk: https://www.youtube.com/watch?v=PEtGNztJaHg

I’ve been experimenting with InertiaJS and Phoenix for an implementation of the RealWorld Demo app.
GitHub - team-alembic/realworld-phoenix-inertia-react · GitHub (sorry for lack of docs!)

Overall it feels very simple, like good old MVC, but with React as your UI layer.

Having the page props immediately available so you never have loading states or error states from API requests is so nice.

The useForm hook is excellent, you submit your form data and let the server either respond with errors or redirect to a new page showing the result.

The backend is using Ash, so I followed @zachdaniel’s suggestion to implement the Inertia.Errors protocol which handles mapping errors from the domain layer onto form field errors.

The only issue I’ve run into was due to the way Inertia handles history navigation. By default it re-renders the page using the props originally provided when page was first loaded. In my case it caused inconsistency because parts of the page that would update in realtime by listening on a Phoenix Channel, but Inertia was unaware of those changes. I solved the problem by sending fresh state to the client after the Phoenix Channel joins.

To make it really nice I’d like to generate TypeScript types (maybe Zod schemas?) for any complex data types being rendered as props or sent over Phoenix Channels.

@mbuhot Thanks for the excellent talk! The repo you shared also helps answer a bunch of questions I had regarding simple things like flash messages and form handling. It’s going to save me a bunch of time trying to figure that stuff out on my own.

Ash does not define a JSON serializer like that automatically, primarily because it doesn’t really make a lot of sense to do given that different things can be loaded in different cases etc. However, if you must go that approach, you can derive a serializer if you like or use a tool like ash_json to derive one for you.

It is problematic that Inertia-phoenix integrates directly with Ecto in my opinion instead of providing behaviors that would let it work with anything. Likely integrating Ash with intertia-phoenix would necessitate making improvements to inertia-phoenix.

Wish I had a better answer for you Ultimately, this is the fundamental flaw that arises when libraries use Ecto.Schema as the integration point, instead of defining a behavior or protocol and making an Ecto.Schema implementation for it.