Phoenix LiveView hot reload has an option to preserve socket state

Learning Resources Guides/Tuts/Tips/Info
, ,
1

Sorry if it’s a common knowledge, but it’s something I just learned and wanted to share.

I’ve seen that mind-blowing demo of hot-reload in production recently presented by Chris. So I asked if we could have something like that in development as well: https://twitter.com/jskalc/status/1788293373792596166

It turns out, it’s there already! In your dev.exs Endpoint config add live_reload: notify section and update live_reload: patterns to match this:

# Watch static and templates for browser reloading.
config :my_app, MyAppWeb.Endpoint,
  live_reload: [
    notify: [
      live_view: [
        ~r"lib/my_app_web/core_components.ex$",
        ~r"lib/my_app_web/(live|components)/.*(ex|heex)$"
      ]
    ],
    patterns: [
      ~r"priv/static/(?!uploads/).*(js|css|png|jpeg|jpg|gif|svg)$",
      ~r"lib/my_app_web/controllers/.*(ex|heex)$"
    ]
  ]

Now when you update your live view code, your state will stay intact.

For me it’s a life-changer. I have to admit I wasted so much time without that feature :smiling_face_with_tear: Mostly when working with a bit more complex Live Views with forms or ephemeral state.

Did you know about it? Is it highlighted somewhere in the documentation / installation instructions but I just somehow missed it? :thinking:

18 Likes
2

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.

1 Like
3

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.

1 Like
4

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

8 Likes
5

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

2 Likes
6

The problem with documentation only is that one needs to know it is (maybe) an option and search for it.

I did (and would) expect it to be enabled as it’s a massive DX booster. When the view blows, recovery will trigger and as I just changed some state I would probably figure out myself I triggered the crash.

So I rather see it enabled by default or as commented code in the generated config (which every Phoenix dev will see quite soon, unlike all generator flags)

we need to make folks aware of the tradeoffs in the docs

Having it enabled by default seems to have -other- tradeoffs, not more, am I correct?

7

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.

3 Likes
8

That’s very cool.

Is there any way to get a component used by a LiveView to update the LiveView when it is changed? I’m getting the pubsub broadcast happening but the component change is not reflected in the UI. i.e. def handle_info({:phoenix_live_reload,... in Phoenix.LiveView.Channel is called when a component is edited, but UI is not updated until there is some interaction with it forcing a redraw of that part of the DOM.

1 Like