Hacker News Reader

Comment by Ankhers | Hacker News Reader

As someone that writes Elixir at $DAYJOB, I was really looking forward to replacing some JS with LiveView. However, after having used it for a simple feature, I'm not entirely sure if I will continue to use it. I realize it is still pre 1.0 and that there is still a lot of work being done on it.

My biggest complaint is that if your server restarts for any reason (say, a rolling restart), you currently lose all state that was on the server[0]. There appears to be some kind of workaround for forms currently, but for anything more complex, I would need to write JS in order to attempt to not have my page get reset to the default view. So if I need to write JS already, I may as well just write JS (or something that transpiles or JS/WASM) to have fewer moving parts.

[0] https://elixirforum.com/t/liveview-and-rolling-restarts/2397...

View on HN

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 :)

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).

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!

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

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?

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

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?

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.

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.

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.

Thanks for mentioning, this is good to keep in mind. I'm just getting started with LiveView for the first time on an internal admin. I don't have an educated opinion yet, but I'm excited about it after watching all of the ElixirConf talks.

Out of interest, what are the other problems you've encountered with it? We're considering porting our whole app to LiveView.

An issue that I was having is that LV did not have any releases on hex. So you had to pull from github and pray you got a working version. This was recently fixed though, so you should always try pulling for hex if you are able.

My last "problem" is less of a problem with LV and more of a contraint of my system. I cannot guarantee that everyone using this application will have network access 100% of the time. So for a certain subset of my users, LV would not be ideal.

Reply on news.ycombinator.com