chrismccord
Phoenix LiveView 1.0.0-rc.0 is out!
LiveView 1.0.0-rc.0 is out!
This 1.0 milestone comes almost six years after the first LiveView commit. I published a Phoenix blog highlighting our developments along the way, a few fun demos, and what we’re up to next.
Existing applications on 0.20.x should have a quick upgrade. We have one backwards compatible change that you can add back via a phx-feedback-for shim. Full changelog with shim notes:
Changelog
Backwards incompatible changes for 1.0
LiveView 1.0 removes the client-based phx-feedback-for annotation for showing and hiding input feedback, such as validation errors. This has been replaced by Phoenix.Component.used_input?/2, which handles showing and hiding feedback using standard server rendering.
A backwards-compatible shim can be used to maintain phx-feedback-for in your existing applications:
- Save the
phx_feedback_dom.jsshim to your localassets/js/phx_feedback_dom.js. - Import it into your
assets/js/app.js. - Add a new
domoption to yourLiveSocketconstructor, or wrap the existing value:
import {Socket} from "phoenix";
import {LiveSocket} from "phoenix_live_view"
import phxFeedbackDom from "./phx_feedback_dom"
let csrfToken = document.querySelector("meta[name='csrf-token']").getAttribute("content");
let liveSocket = new LiveSocket("/live", Socket, {
params: {_csrf_token: csrfToken},
dom: phxFeedbackDom({})
})
1.0.0-rc.0
(2024-05-08)
Backwards incompatible changes
- Remove
phx-feedback-forin favor ofPhoenix.Component.used_input?. See the changelog for a backwards compatiblephx-feedback-forshim to add to existing applications.
Removal of previously deprecated functionality
live_component/2andlive_component/3helpers (not the function component) have been removed
Bug fixes
- Fix attributes of existing stream items not being updated on reset
- Fix nested LiveView within streams becoming empty when reset
- Fix
phx-mountedfiring twice, first on dead render, then on live render, leading to errors when a LiveComponent has not yet mounted - Fix
JS.toggle_classerror when used with a transition
Enhancements
- Warn on mismatched client and server versions
Happy hacking!
–Chris
Most Liked
DevotionGeo
That’s fantastic news! Huge congratulations and thanks
to Chris McCord (@chrismccord) and the team for reaching this milestone.
This is a major achievement for the Elixir community!
It would be great to hear from course creators and book authors about when their Phoenix LiveView content will be updated for version 1.0.0. This will ensure new developers jumping into LiveView.
Here’s a quick rundown of some key content creators:
- Courses:
- Mike Clark (@mikeclark) and Nicole Clark: Phoenix LiveView at Pragmatic Studio
- Peter Ullrich (@PJUllrich): Build an MVP with Elixir
- Geoffrey Lessel (@geo): Build It With Phoenix
- German Velasco (@germsvel): Testing LiveView
- Book:
- Sophie DeBenedetto (@SophieDeBenedetto) and Bruce Tate (@redrapids): Programming Phoenix LiveView for Pragmatic Bookshelf (@PragProg)
- Peter Ullrich (@PJUllrich): Building Table Views with Phoenix LiveView for Pragmatic Bookshelf (@PragProg)
Hopefully, they can chime in and share their update timelines!
Feel free to edit, add more learning material, and mention their authors.
chrismccord
no, not something we’ll ever ship ![]()
The whole promise of LiveView is you can add “realtime” the moment you need it, without suddenly rewriting everything and brining all this complexity. If you want good interactions with the backend, LiveView is the best choice from latency and overhead perspectives. With The LiveWire approach, you’ll have more load on the server because you’re hitting the database more frequently, doing TLS more frequently, etc. Payloads will be much larger. The only argument is memory footprint, of which the 1.0 blog outlines how a 1GB server has a theoretical max of 25k concurrent users, so even with real app workflows, many thousands of concurrent LiveView users would be no problem on small servers. As LostKonbrakai said, we have longpoll as well, with auto longpoll fallback if websockets fail, so websockets themselves also should not be a concern.
Nicodemus
Awesome news! I’ve been wondering, is :phoenix_live_view going to be merged into the :phoenix hex package? It seems like this has been the plan since :phoenix_live_view contains Phoenix.Component. I know for newbies it’s very confusing why they have to go to :phoenix_live_view on hexdocs to find the documentation for function components that they’re using in layouts and non-live views. Maybe a Phoenix 2.0 release that bundles it all together? Or at least moves Phoenix.Component into :phoenix?







