I have a general question on whether anyone tried to combine LiveView and SPAs together? The thing is I can see nice use-cases for LiveView and would prefer avoiding building all those GraphQL mutations and front-end components for specific screens (kind of dashboard). At the same time we already built everything as SPA and so the login would have to be shared (we send JWT in headers). I guess the only problematic part is the login. Has anybody tried something like this? What route did you take? Is it better to avoid LiveView when building SPA?
I have tried it. In-fact, I’m working on a library called “Phoenuxt”; which combines LiveView with Nuxt.js.
Personally, I think the browser side of LiveView took the wrong approach. I would have liked to see two separate JS libraries; where the channel communication and DOM interaction were decoupled. This would create a more modular and less opinionated approach. In its current state, I don’t think it’s a practical replacement for an SPA (particularly an SSR SPA).
Additionally, for LiveView (and Elixir by extension) to gain adoption, I feel it will be important to be able to progressively swap out portions of a site with LiveView. Having opinionated UI/DOM interaction will make that difficult.
The approach I took with Phoenuxt was to create a JS socket channel library (uses the same channel as the regular LiveView logic), and a separate Nuxt.js component. The idea being that what LiveView calls a “view” in JS is now a Vue.js component. This means hot swapping, CSS chunking / code splitting, and even leveraging Vue’s component scripting for the LiveView hooks. It also means using VDOM instead of morphdom. It also means leveraging Vue’s transition logic between views, and leveraging Vue’s router logic for push state. The LiveView data is assigned to the Vue component’s props, allowing you to write Vue.js in your LiveView template! All this is abstracted away, and the backend is unchanged.
I haven’t released this yet to the public, but it’s my personal opinion that something like this will be necessary once we all get past the initial honeymoon phase of LiveView. There are a lot of modern web app considerations that need to be addressed, but it’s my personal opinion that it is totally doable.
We have done similar in a few instances where Angular loads it’s content containing custom HTML tags which hold the URL to a corresponding LiveView endpoint. The LiveView rendered template is loaded into each corresponding tag and once they are all loaded the LiveView socket is created from a callback.
This is not ideal as the socket needs to be reinitialized any time the JS framework changes the content on the page containing the custom tags.
A better way IMO, if possible, is to load LiveView first as the skeleton of the page then use phx-ignore and phx-hook to bootstrap JS components one by one. This requires extra work if you have an existing app with data resolving in it’s router layer, which will need to be moved to data attributes or loaded from the JS components.
