Thanks for the feedback!
There won’t be anything to configure debouncing wise, as it will only be annotating the DOM like you mentioned – phx-debounce="1000" or similar. Our greater JS interop story is still TBD. Today your only option is to wire up event handlers directly like onclick="myFunc(event"). There’s a lot explore here, but I’m intentionally punting on this for now until usecases help present a generalized solution.
The only purpose of this contrived example is to show the server can handle re-rendering and sending diffs such that 60fps animations are possible. It’s not a real usecase, but it’s a fun example to showcase our general performance. I disagree about not being a good showcase for many users causing many renders ¯_(ツ)_/¯
the “boom” is arbitrary. It could also be “this-will-explore” since it will cause a function clause error and intentional crash on the server. The purpose there was me testing the failure and recovery modes of parent/children/etc.
State wise, the same rules apply on the live view process as any other elixir process. The live view recovers to a known good state, which is an empty form in this example. For durable server specific state, you’d handle it the same way you handle it in Elixir today, which is to say it’s up to you to store outside the process as needed. This may sound like a hand-wavy answer, but I’ll repeat it’s the same story that we have in elixir processes today and restarting to a known good state is one of the things we want in recovery. For client specific state, we do have the live view session, and we will expose primitives that allow you to update the session with state programmatically. So things like last_seen_id for a chat app, or in your example, specific user inputs could be ‘persisted’ in the live view session and recovered on crash.
As I’ve mentioned in my talks, our goals are to start small and see where we programming model breaks down. I think we can go farther than a lot of people think. Strength wise as it exists today, I can confidently say LiveView will be great for:
-
bits of required rich interaction in your app. Think notifications, async job statuses, progress bars, dashboards, widgets, etc
-
interactive forms. Think ‘client-side’ validations, dynamic forms that update inputs/options based on selections, must-step wizards, etc
-
any realtime updates you wish to push out to users or have users’ page info update based on things happening in the system. I’m going to flip your comment back at you:
more than *magic to socketify a CRUD resource*think of how many pages our web applications render where otherwise static data could be live if the cost to support it was sufficiently low. Today that cost is too high for most tooling without buying into a ton of complexity, even for pages that are ultimately dumb “CRUD” data. LiveView makes it trivial to enhance these “CRUD” pages with realtime updates that deliver instant UX increases, so don’t be too quick to discount this side of things, after all how many of us are building glorified spreadsheets, SPA or not?
-
any rich interaction where the server is required to be there. Think autocomplete and search results – things that are impossible or impractical to cache on the client and don’t make sense in any optimistic UI context. (google can’t cache their search index in an SPA for example)
So to close, we know the areas LiveView isn’t a good fit – highly latent clients, usecases where optimistic UI is required, desktop-like interfaces, offline support. What specific usecases we venture into in this brave new world… we’ll find out together
