DOM changes from client-side JS are wiped away on refresh

[j-f1]

I’m not sure what the best solution to this would be, but it can be pretty disruptive to have DOM modifications — especially those automatically applied on page load — get wiped away.

For example, Bootstrap dropdowns are closed and HTML attributes added to top-level tags like html and body are wiped away.

Since load and DOMContentLoaded handlers are not called again (and scripts are not re-run), the page can easily get into a bad state.

[zachleat]

Oh, yeah—hmm. Couple of ideas here:

1. Option to opt out of morphdom (but keep the other live reloading bits)
2. Something fancier about morphdom triggering load/domcontentloaded events clientside? This is a bit riskier, I think the first option might be a better opt-in

[zachleat]

v1.0.0-canary.3 of this package will include a domdiff option (default true) that you can use to opt-out of morphdom (basically all of the existing server options but using full page refreshes instead of the dom differ). We could improve this in the future to opt-in to this on a per-route basis if folks are into that, but I’ll wait and see there.

[zachleat]

Going to close this one per the domdiff addition. If you’d think we need some finer grained control here, please let me know!

[j-f1]

Thinking further about this, I’m wondering if there’s a way to scope the changes. It would definitely increase complexity, but you could theoretically compare the .html file both before and after the rebuild, then only update the nodes that have actually changed. Not really sure it’s worth developing what amounts to a frontend framework for this though 😉