Strategies for dealing with stale JS hooks in a frequently deployed app

Phoenix Forum Questions / Help
, ,
1

We run a midsized LiveView app and deploy multiple times a day and have been having issues with javascript hooks running older versions than the server.

This causes major headaches when fixing bugs because it will sometimes take multiple days before everyone has gotten the updated javascript. Or when a liveview is refactored and no longer responds to events that an old hook sends out, but the old hook stays around and still sends those events.

The only way to get the new version of the javascript / css is to do a full page reload. We are using phx-digest and have wired up a banner shown when static_changed is true but our users tend to ignore it.

Approaches we’ve considered

  1. Force immediate reload when static_changed
    This would lead to loss of work, as form inputs would be cleared and form recovery wouldn’t have a chance to run.
  2. Intercepting <.link /> clicks and turning them into full page navigations
    It will most likely improve the situation somewhat, but there would still be a lot of cases where old javascript is active
  3. Save state to session storage and do a reload
    An option that would guarantee we get the newest javascript as fast as possible, but that would introduce a lot more complexity and essentially mean implementing logic that liveview already deals with. I did find this issue that speaks to an intent to implement this in liveview, but it seems it was abandoned in favor of a different approach.

How is everyone dealing with these kinds of issues? Are there any plans to implement more robust automatic reloads on asset changes in liveview?

Appreciate any advice or war stories. Thanks!

2

I’ve seen this issue as well - but cannot provide a good solution right now.

3

I understand LiveView doesn’t solve it out of the box because there is no one single correct solution.

You seem to be aware of the mechanisms to control what to do, and tradeoffs. Likely different pages/LiveViews would require distinct approaches instead of a global solution – highly dependant on your app and expected behavior.

What I can offer is to suggest keeping your code changes forward/backward compatible. It is similar to database migrations and code changes.

E.g. you can keep event handlers in place for some time after you remove them from client code. You may change the event behavior to notify the user they must refresh the page.

Are you looking for a uniform solution for all LVs or would your app qualify for a more granular choice of approach?

1 Like