Preloading #48

zth · 2022-06-24T21:15:03Z

This continues on the preloading path, and does the following:

Ensure all dynamically imported assets are included in our res manifest.
Ensure route renderer JS script tags are emitted ASAP to the stream. We'll know the client will need them as soon as we've matched the initial routes to the URL, so we can emit them right away.
In dev, dedupe assets between preloading on the client/server.
Bring back script tag based preloading client side.

Things left to fix/that aren't working:

Preloading via script tags in dev in the client bundle doesn't work with Vite's invalidation (appending ?t=<timestamp>), and I don't know how/if we can fix that. It's a small thing though since it's dev only, so we can revisit later.

Closes #17
Closes #46

…et get the same (relative) url

zth · 2022-06-27T05:58:30Z

router/RelayRouter.res

+    switch preloadAsset {
+    | None => ()
+    | Some(preloadAsset) =>
+      initialMatches->Belt.Array.forEach(({route}) => {
+        preloadAsset(#JsModule(route.name ++ "_route_renderer", route.chunk))
+      })
+    }


This ensures that loading of route renderers are initiated and emitted to the client as soon as possible server side.

This moves from the marker function to a very specific object property name. This follows what was done in: - zth/rescript-relay#369 - #47 - #48 This reimplements the changes of those last two R3 PRs on top of the work done to turn server.mjs into ReScript code. A few changes are made with respect to the original PRs. *Vite Plugin* - I did not alter the user’s config. The rollup option not working with the `SSR` option is not caused by our plugin, so it shouldn’t be fixed in our plugin. It’s a user configuration error. Altering the config without the user knowing may confuse them. - Removed `production` check in `transform` this allows using the Vite generated `ssr-manifest.json` - Removed the `Rescript` check in `transform`, our regex should be fast enough that this doesn’t matter and it ensures our plugin works in codebases or pipelines that strip this header. - Removed tracking of `didReplace` since `magic-string` does this for us. *EntryServer.res* - Omitted asset emitting change for RelayRouter since the function has a different shape than RelaySSRUtils.AssetRegisterer. This was because `eagerPreloadFn` was not available in the function the router got. Ideally when we bring this back we only require the consuming developer to create a single preload handler on top of our transformation stream. *package.json* - It looks like the introduction of SSR in production mode has also exposed the bug in Relay’s faulty exports (or ReScript/Vite’s handling of them) here. - Upgrade `history` to 5.3.0 which is required for ESM support.

This reverts commit b5c312f, reversing changes made to c8c0f27. This removes changes to the plugin and does not yet add the route preLoading code. It leaves in place those things that were later used for work done in PRs #49 and #50.

This moves from the marker function to a very specific object property name. This follows what was done in: - zth/rescript-relay#369 - #47 - #48 This reimplements the changes of those last two R3 PRs on top of the work done to turn server.mjs into ReScript code. A few changes are made with respect to the original PRs. *Vite Plugin* - I did not alter the user’s config. The rollup option not working with the `SSR` option is not caused by our plugin, so it shouldn’t be fixed in our plugin. It’s a user configuration error. Altering the config without the user knowing may confuse them. - Removed `production` check in `transform` this allows using the Vite generated `ssr-manifest.json` - Removed the `Rescript` check in `transform`, our regex should be fast enough that this doesn’t matter and it ensures our plugin works in codebases or pipelines that strip this header. - Removed tracking of `didReplace` since `magic-string` does this for us. *EntryServer.res* - Omitted asset emitting change for RelayRouter since the function has a different shape than RelaySSRUtils.AssetRegisterer. This was because `eagerPreloadFn` was not available in the function the router got. Ideally when we bring this back we only require the consuming developer to create a single preload handler on top of our transformation stream. *package.json* - It looks like the introduction of SSR in production mode has also exposed the bug in Relay’s faulty exports (or ReScript/Vite’s handling of them) here. - Upgrade `history` to 5.3.0 which is required for ESM support.

zth added 5 commits June 24, 2022 20:34

simplify + capture all dynamic imports

2dc708c

re-enable code preloading via proper tags

1de74d8

leverage new preloading to preload via asset preloader

6cea074

emit route renderers script tags early in stream

0a5b008

dedupe preloaded asset urls by ensuring all instances of the same ass…

51d24fa

…et get the same (relative) url

zth commented Jun 27, 2022

View reviewed changes

zth requested a review from Kingdutch June 27, 2022 06:02

zth merged commit b5c312f into main Jun 27, 2022

zth deleted the preloading branch June 27, 2022 06:03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Preloading #48

Preloading #48

zth commented Jun 24, 2022 •

edited

zth Jun 27, 2022

Preloading #48

Preloading #48

Conversation

zth commented Jun 24, 2022 • edited

zth Jun 27, 2022

Choose a reason for hiding this comment

zth commented Jun 24, 2022 •

edited