[chrismccord]

In my ElixirConf keynote, I highlighted how automatic form recovery is on the roadmap, provided we can determine that such a recovery is possible on reconnect. More advanced dynamic forms will require manual recovery, and as you said it can be done today, with 20 lines of JS: https://gist.github.com/chrismccord/5d2f6e99112c9a67fedb2b85...

We are going to formalize the idea of a "stash" to send back up client state on reconnect, which would remove the need for this JS entirely. It is also worth noting that if someone packaged up that 20 line gist into a JS package, your application or anyone else could do `<form ... phx-hook="SavedForm">`, so "need to write JS anyway so might as well write a JS app" isn't quite accurate because it's a tiny escape hatch that doesn't require throwing away or rewriting any feature. Writing 20 lines of JS to keep shipping LV features is much different than rewriting an entire application in JS. I would actually argue the fact you have the escape hatch in this scenario is one of the merits of the library. Anyways, I hope we can keep you around once other features continue to land :)

[Ankhers]

I believe I have only heard about automatic recovery for forms. Would this "stash" you mentioned be more general for recovering state?

For what it's worth, I very much appreciate the work you and everyone involved has done for LV (and more generally, Phoenix).

[chrismccord]

Yes, in the above gist the connect are params used, so connect params are a general purpose mechanism for state recovery. In the above example a form is used, but on mount you can do whatever you'd like with the data. Thanks!

[elcritch]

Will the data in the “stash” need to be verified on the server? Currently I treat connect params as user data and parse and verify it. I’m unclear if a more general data stash would cause potential security issues.

Secondly, has there been any discussion for supporting server side draining or moving the process to another node?

[fouc]

Phoenix is built around a middleware known as Plug, and most things are Plugs, you can add a Plug to separately handle the verification I would guess

[Ankhers]

Awesome. I look forward to having this idea formalized and I will give it another go.

[ksec]

Other than State issues ( I am glad it is being work on ), How will LiveView works if your client is in say AUS / New Zealand and your Server is in US or EU with 200ms+ latency?

[porker]

Poorly according to some of the demos/experiments I've tried, which AFAICT were running on the US West Coast (I'm in the UK).

For some stuff this will matter (the test was a game, which isn't what I'd use LiveView for in production), but for others, where data has to go to the server anyhow- the delay is there, even if my nice JS frontend disguises how long it takes.

[ksec]

That is the thing I am wondering if there are any innovative way to solve this. If you are building a small Internal Web App, or if your business is mostly operating locally within region and not globally, LiveView could very well be the best thing since slice bread, but once you add 100ms+ to it, its experience quickly worsen to the point JS is far better.

[porker]

Deploy to multiple datacentres round the world, and always route an app user to the same one? But then you've got distributed databases to contend with (if required - or slow lookups against a central one).

I'd like to think Edge Compute could be used.

At the end of the day we're up against the speed of light and our options are limited.