strzibny
Hi all,
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?
Trending in Discussions
The obligatory hello world thread!
Who are you and where are you from? :stuck_out_tongue:
New
Hey there,
It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
Hey folks,
I wanted to share with you a project I’ve been working on for a while: It’s an Open Source (AGPLv3) newsletter tool. Think Ma...
New
Hi everyone :waving_hand:
I wanted to share something I’ve been building — NowBlind, a random chat app designed to help people discover ...
New
In my third year of college, around 2010, I found Erlang. A few years later, I found Elixir. I liked the ideas at once: many small proces...
New
Hi everyone,
I have 8 years of production experience with Erlang/OTP and I’m just starting to get to know Elixir. What would you learn f...
New
I’ve been tinkering with Lynx (by José) via hold_ledger. I used AI to write the code, a separate specification, the tests, and the Lean p...
New
Other Trending Topics
Hey there,
I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first.
...
New
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly)
AI dream has many faces, but general...
New
Localize is the next generation localisation library for Elixir. Think of it as ex_cldr version 3.0. The first version will be released ...
New
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself.
My main conc...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #elixirconf-us
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance











Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
bjunc
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.
strzibny
Thanks for your answer. Sounds like an interesting approach :).
kevn
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.