🐛 BUG: Turbolinks breaks hydration on repeat page views

[nonphoto]

What version of astro are you using?

1.0.0-beta.12

Are you using an SSR adapter? If so, which one?

None

What package manager are you using?

pnpm

What operating system are you using?

Mac

Describe the Bug

Turbolinks merges script tags in head and will not run a script more than once, so Astro islands will not hydrate when viewing a page for the second time.

This is only an issue with the Turbolinks integration at the moment. An easy fix would be to add hydration scripts to body instead of head. However, I can imagine other scenarios where it would be useful to insert and remove islands and have hydration handled automatically, so I think using a MutationObserver would be a more general solution.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-kq5z3u?file=src/pages/about.astro

Participation

• I am willing to submit a pull request for this issue.

[natemoo-re]

There are some fixes in #2899 for this, but I'll need to split them out to a separate PR.

MutationObserver is one option but a CustomEvent to trigger hydration would be more performant.

[nonphoto]

@natemoo-re CustomEvent is a good call! Is there an issue somewhere I can follow for this?

Thanks for the Turbolinks fix @tony-sull

[narration-sd]

@tony-sull Tony, was quite happy to see this of yours; unfortunately it has problems I think with the basic approach. So we may need to see if @natemoo-re has a way that works better.

What's the problem? Your patch seems to work at first, and on a dev system. But when I put the build on a droplet, I got a pretty terrific FOUC -- a strong white flash -- between any of three pages.

I had to think about this a bit, as I was also getting different network requests depending on whether I tested a local dev server, a local build preview, or out in the world on a Netlify instance.

I think it resolves to timing effects in the browser rendering engine, altering the requests it makes and re-renders depending on latency (server speed when local). This would be natural, as browsers are pretty clever about how much presentation effort they make vs. arriving code or scripts and their timing. As with the results when you fire off the scripts, which is the basis of your method in the patch.

I'm attaching a screenshot of a worst case, for the droplet case where there's even a pretty short latency add. Have a look at the network requests. There are actually doubled requests for each page -- I'm only route switching to one, and then two, with no local bounce.

Whether you get doubled, other results I've seen, or on which page depends on the server arrangements above, and some of the browser-side variations depend on what is actually on the page. Some it can be pretty entertaining to think about, but we really can't -- we have to treat the browser rendering engine as a black box, and one that can change.

Then I'm thinking we probably need to see @natemoo-re 's work, and whether that has cleaner results, no?

The FOUC itself is explained in that I'm using pages based on the Astro skeleton included when you initiate a project. One of them just uses a simpler markdown content with the given counter, and the other includes some different Vue components of mine -- I'm trying to model up whether I can replace (with much regret) an interesting website engine presently constructed on Gridsome. Both would run via Netlify.

What is in the boilerplate re-used in those pages (in global.css) is a media queried overlay of the css. The media check is whither the browser thinks it's in dark mode. I would guess that dark mode is pretty far down on the priorities of the rendering engine, (normal and dev releases of Google Chrome), and so it gets significant delay before being enacted. Since it flips color and background color, a full screen refresh is done. Since I'm on dark mode for my eyes, the initial white screen renders earlier, resulting in the flash. The doubled pull may happen because everything hasn't arrived over the wire by the time its needed for this rerender -- my thinking doesn't feel quite grounded here.

What it does seem is that a scheme to fix the render problem should have everything ready on the initial turbolinks-based load, and not add screen instructions later, either css or javascript. So, very interested in what @natemoo-re has been building up, while appreciative and of respect for the way you've done something here -- thanks! 🌱🌿 👍

p.s. In between other things must do this afternoon, had a very brief glimpse at @natemoo-re 's work on this topic. It appears in using a diff engine to make a more internalized SPA approach that might indeed avoid the problems reported, if one were to guess.

I notice that the pull request is on hold, I think because of @FredKSchott 's marking it as in-progress. This may well be wise, given the sorts of issues that can arise without code testing noticing them, as above. Would it be possible or make sense for Nate's work to be provided as an extension, so that it could be released where we can try it without upsetting the central flow of Astro's program? Of course, SPAs are pretty important to that also, at least seems so here :) Cheers, all...

[FredKSchott]

Discussed with @tony-sull and @natemoo-re and decided it makes sense to deprecate turbolinks since it isn't working properly and doesn't seem like something that we can easily fix. Nate has been working on a first-class "turbo" mode, and our time would be better spent releasing that as an experimental v1.0 feature.

TODO:

• deprecate turbolinks package (https://docs.npmjs.com/cli/v8/commands/npm-deprecate)
• Add a note to readme
• Remove from astro add prompt
• anything else?

[narration-sd]

@FredKSchott et al, sounds a wise and intriguing course -- @natemoo-re 's gem sounds great, and as @tony-sull has spoken of it to me.

The challenge I was originally looking into involves replacing, with respectful reluctance towards their circumstances, a Gridsome framework we've used.

Over distance of time, though, realized I may not have been speaking straight about how a master-detail could be arranged, as in the usual in-app docs page with topics on the left and relevant explanations on the right. I think we did it actually by eventing betwen two Vue components, and seems that ought to work fine also in Astro. To be tried.

It's interesting though to wonder if Nate's comparator could do 'frame' replacements with any ease, for a SPA effect on related screen areas like this. I think that's what TurboFrames and its successor were aimed at, and don't know how successfully it worked out, but it may be an interesting ability to consider.

Best fortune all ✨