We’ve put together this wiki for Phoenix LiveView - please feel free to add any info you feel is worth including.
What is Phoenix LiveView?
As described by @darinwilson “Phoenix LiveView allows developers to add dynamic, client-side interactions to web pages, using code that runs in Elixir on the server”. This mean you could kiss goodbye to front end frameworks like React and the JS-hell that so many of us have been finding ourselves in these past few years! As you might imagine, the community is very excited about this!
For a more in-depth explanation, check out Darin’s excellent blog post on the topic.
Has there been anything like it previously? Has the idea been tried and tested at all?
We’ve put both of these questions together because the answer is yes and yes! There is a similar library in the Phoenix world called Drab, which has proven to be very popular in the community. LiveView tackles the same sort of problem but from a different angle - so if Drab is anything to go by, LiveView is going to be a huge hit
There is also another similar library that was announced at ElixirConf 2018, called Texas.
There’s now another new library, called Morphling… and… another called Whistle
Where can I get more details?
Chris McCord’s keynote is currently the best place to get details, followed by the blog posts on the topic as well as Chris and José’s comments in the numerous threads that have cropped up here on the forum.
Live view is not going to drop in a few days. Chris clearly said in his elixir conf talk, that once the book and phoenix 1.4 is out he can start further research into live view. By now it’s probably just a small prove of concept implementation far from a publishable state.
This is cool indeed, but what I really want to see controlled inputs and how @chrismccord plans (and if) to implement it. Like, when you type, events are being sent to server, server does something with the text and sends update back.
Good use case is for example input that converts entered text to lowercase, or an input that formats phone number.
Longer text inputs (text areas) with a lot of text in it is going to be another problem. Also, pasting text, entering / deleting text in the middle of input etc. is going to be hard without some smart diff algorithm.
I did some experiments with server-side updates, and form inputs were the thing that seemed to be the hardest to handle.
I’m wondering how interop with JS could work with LiveView… I have a bunch of React components and currently am happily using react-phoenix to render them.
A lot of use cases will work great in pure Elixir with LiveView but frequently I will need to client-side render a React component (that’s already loaded in JS scope on the page) with props in the middle of a LiveView component/module. Not sure how that would/could work with the DOM diffing strategy but it would be totally awesome. I think Chris mentioned in a podcast (or video, not sure) he was thinking about this.
As long as the javascript components follow the webcomponents spec then I wouldn’t see much issue unless the DOM swaps things out or mutates a property when it meant for an attribute or vice-versa or so (Drab handles this really well).
Something I’ve been missing is information of whether or not history alteration will be a first class citizen.
To be able to truly replace react we’ll need to be able to construct rich urls that can be updated by the liveviewing.
We’re close to an initial release, and we can’t wait to see the kinds of applications the community builds with LiveView. Our next step is building testing tools similar to Phoenix.ChannelTest, which will allow testing live views and client interaction purely in Elixir without a browser. We will also be shipping LiveView generators that will allow bootstrapping CRUD UIs like the existing phx.gen.html generator, but fully real-time out-of-the-box. Stay tuned!
Push state is definitely something I will explore once other areas settle, but I think standard URL navigation should still be the default. We supports redirects today, so I imagine there will be a transition primitive that would use pushstate, but not a goal for our initial release.
