This has been there for months (years?), but we haven’t been certain how we want to recommend usage yet or include by default. It’s the same considerations as production where you can footgun an upgrade into bad state, ie you introduce a new assign in the template and mount, but the running LV doesn’t have it. That said, the LV will blow up, immediately remount and all will be well, so even in most footgun cases you can get back to working state without intervention. All that said, we need to make folks aware of the tradeoffs in the docs, and potentially have it be opt-in as needed vs always enabled for every LV. I definitely understand the QoL improvement this brings in dev – which was the whole reason we added it

It’s harder than that. The example I gave of a missing assign that immediately crashing and remounts is the happy path which recovers to a good state, but there are other cases where the app can enter a bad state and not crash (ie you setup pubsub subscriptions or other stateful bits in mount that don’t happen for exisitng process, or you have timers that need to fire, or you had timers that were firing but you removed them and their handle_info clauses and they blow up the process at some point in the future. There’s not try/catch here that saves you. It’s less about transient errors which aren’t a big deal in dev and more about breaking apps in confusing ways, especially for folks that don’t really know what’s going on/why. So I think a non remount live reload is best opt-in where folks could add matches in their config for specific files, or some similar mechanism. Of course it’s fine to go all in and manually refresh as necessary if you know what’s going on, but as a general default it’s tricky to allow users to get into confusing or bad state that shouldn’t be possible to happen.

Thanks for explaining! I had a feeling it’s not a new thing.

It gave me a huge productivity boost. Considering how much engagement my tweet received, it was also useful to others.

I understand your reasoning about being careful to set it as a default, but it would be great to raise awareness. I see these hopefully reasonable options:

1. Set it as a default, and maybe automatically catch re-render errors when hot-updated with missing assign, so console won’t be cluttered by transient errors
2. Include commented out in the generated config, with a short explanation what it would do.
3. Mention it either in the installation instructions or LiveReload docs
4. Make it an CLI option in phx.new generator?

Personally I’d love to see 1) happen, or 2) if 1) is too dangerous. I might help with a PR if needed.

PS. Thanks to that feature, I was able to achieve amazing DX with my up-and-coming LiveVue library (LiveSvelte but for Vue + Vite). Updates both in JS and EX files are reflected instantly, keeping the state intact. It feels like cheating

With the liveviews under notify do you need to remember to manually refresh when you change how state is determined?

I have my CSS and surface templates under notify, which I saw in the surface slack recently, but not my liveviews. Hadn’t heard of the feature before that.

I think under the hood it uses Erlang code updates.

State stays intact, so it only re-renders HTML and sends diff to the browser. It’s the same as you might know from JavaScript hot reload, eg with Vite.

I must admit, for me it’s kinda a big deal.