am keen to understand how this effects the rest of the ecosystem
how one might migrate a CRUD app ?
I saw someone asking about LiveQuery, I wonder how it will effect JSON api also
lots of questions
I am so thankful I never bought into the Javascript Frontend JSON API koolaid
dhs convinced me a couple of years ago with his screeds
chris_mccord has really shifted the paradigm
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).
@chrismccord has posted this on the DockYard blog
Has lots of useful info and cool examples - can’t wait to check it out 
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.
Any idea if this is coming? @chrismccord?
Exciting stuff!!!
What’s Next?
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 existingphx.gen.htmlgenerator, 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.
Looks awesome - can’t wait!
Nice to see error and reconnection handled..
One thing I worry about is outdated js/html running against updated server code - eg my 3 day old tab which now has outdated js/html, or a just deployed release when I’m still connected, and gets reconnected to “new” code that may contain changes - maybe need a manual min_version constant that one can set and if the client is too old phx-must-reload event happen, or something…
but I may just be overthinking it..