Although it had already been announced (but not released yet), Phoenix LiveView was presented to the audience at Lonestar ElixirConf with a promise from Chris McCord to be released as early as the end of the month but at least in the coming months.
Chris spoke about the motivations for building LiveView and stressed the goal of delaying the inevitable single page application path for as long as possible. How long that is will be determined after release when people have had time to use it.
I am personally quite optimistic about it and although I’m happy to keep writing JavaScript on the frontend whenever I need to, it will make building prototype apps to showcase Elixir’s real-time capabilities much easier.
The conceptual programming model for LiveView is very similar to that of React and other JavaScript libraries, in that each component has a parent-child relationship, with the default behaviour that if a child component fails, it can be restarted back to its last known state. It is in this way they behave like children in a supervision tree. The similarities between frontend view libraries like React and Elixir/Erlang supervision Trees is a topic I have written about before.
Also from Chris’s LoneStar talk he had just finished the implementation to run tests against LiveView, and before release wanted to implement LiveView generators and polish the documentation and guides.
I heard the video person showed up late and Chris was almost done with his speech! That’s very bad luck for the hundreds of us who couldn’t make it to Austin but are dying to hear him discuss LiveView!!
Let’s hope the videographer for Elixirconf EU doesn’t drop the ball as the speech should be similar.
Above was the question I once asked. Is is now possible to persist the chatbox using Turbolinks’ data-turbolinks-permanent, updating it with new messages through LiveView, and make rest of the page navigable through Turbolinks?
It will make may more types of Apps possible with LiveView + Turbolinks, and will save us from writing extra front-end code.
That’s even better if we’ll be getting even the functionality of Turbolinks for free and won’t need to add Turbolinks. Also there won’t be any compatibility issues, as it’ll be a single lib. But we’ll need a (somewhat) detailed tutorial which covers all of the Turbolinks features.
I can’t thank @chrismccord, @josevalim and others enough, for the awesome work they’re doing. Thank you!
Our live_link's and live_redirect's will also be much faster because it happens over the established websocket connection, so if you are doing things like pagination within a running live view, you don’t have to refetch current user/org/etc and do all the setup/teardown of the request
So for clarity, in the semi-short term are your plans to fully replicate Turbolinks inside of LiveView? In other words, being able to just load new content in (with push state) behind the scenes and now only the body of your page will be swapped out between page views with no extra work at all?
This makes a tremendous difference for the better in page loads because the browser doesn’t need to parse all of your CSS and JS on every request.
Although Turbolinks does quite a bit more than that too, which is nice. I’m currently using it in a Phoenix app today but it would be nice to drop it for LiveView eventually.
