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
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
New
The obligatory hello world thread!
Who are you and where are you from? :stuck_out_tongue:
New
I want to open this thread for you all to discuss and help those who really like Ash but are still hesitant to use it in a real project. ...
New
I was working on an Ecto migration and I needed a timestamp. So, for the nth time, I looked up the different data types for timestamps, a...
New
Fly’s CEO posted this recently - Turn And Face The Strange · The Fly Blog
It says that Fly is going all-in on sprites, which is a worry ...
New
We’re evaluating API mocking tools for OpenAPI-based projects and would love to hear what other teams are using.
We’re particularly inte...
New
Is there a word for the ~> symbol used in Version strings?
Do you also just call it a Squiggle Arrow™ ?!
New
Other Trending Topics
Hobbes is a low-level distributed database for the Elixir programming language.
Hobbes provides a simple, safe, and scalable storage lay...
New
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve.
They are GUI (Emerge) and State management (S...
New
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
There are three potential reasons for members of this forum to have a look at https://vutuv.de
You are tired or annoyed of LinkedIn.
Yo...
New
Aludel - LLM Evaluation Workbench
Aludel is an embeddable Phoenix LiveView dashboard for evaluating and comparing LLM prompts across mult...
New
Latest Phoenix Threads
Latest on Elixir Forum
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










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.