Let me preface this by saying I’m a huge fan of LiveView—this discussion is borne purely out of love for LiveView and respect to everyone that works on it. Using it is an amazing experience!

Frequently when I’m working on something new, I have major decision paralysis where LiveView is involved, and it often comes down to just the need to render something like a modal. Usually the thought process goes like this:

1. Find a LiveView Modal example or use the mix phx.gen.live generator
2. Remember that modals whose open/closed state as in the generator and most blog examples result in what I consider to be sub-optimal UX (In poor network conditions or even when a random network blip occurs, what users typically expect to be an instant interaction suddenly has noticeable and frustrating latency associated with it)
3. Find examples that use LiveView but show/hide the modal using JavaScript
4. Realize the only JS inter-op that works well so far (that I’ve found) is Alpine.js, but using Alpine.js has security implications I’m uncomfortable with (I want to avoid a CSP with script-src 'unsafe-eval', which Alpine.js requires)
5. Worry about having this debate for every component and wonder whether to just avoid the issue altogether and step back into the more familiar territory (for me) of a Phoenix API + React via Next.js, for example.

Even if CSP weren’t a concern, using a client-side library like Alpine.js still comes with a set of problems I’m not sure how to solve. Consider the following flow:

1. User shows a modal containing a LiveView-rendered form via Alpine.js
2. User submits the form, but errors come back and are rendered via LiveView
3. User changes their mind, closes the form via Alpine.js
4. The app sends a WebSocket frame to tell LiveView to clear form state
5. User changes their mind again, re-opens the form, but the “clear the form” message is still in transit, and the user sees their old errors, which then unexpectedly disappear when the “clear the form” message is finally processed and the modal contents re-rendered

Of course, this is a very specific and somewhat contrived example, but I think it illustrates the general theme that without careful consideration, LiveView can take you from dealing with the already-difficult problem of managing a single UI thread to dealing with a second UI thread for certain pieces of state.

The answer here just may be that LiveView is specifically not the right solution for UI elements like modals and other similar UI elements right now, but then having to build an app where some components work via LiveView like a single page with a form on it, and others require separate templating/state management/etc. on the client seems to add additional complexity that I would avoid with an architecture that has a single source of UI state.

I’m curious if others have thought about this, and especially if you’ve got an app in production or development using LiveView heavily, how are you dealing with it?