-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
set public env in <script>
, implementing preloading on safari
#9018
Conversation
Gah, it's less simple than I thought. We actually can't evaluate stuff eagerly because We could instantiate Dammit why can't browsers just implement |
I have made a discovery! In Safari, Which means all we need to do to effectively polyfill <script>
const { relList } = document.createElement('link');
if (!relList?.supports('modulepreload')) {
for (const link of document.querySelectorAll('link[rel="modulepreload"]')) {
const preload = document.createElement('link');
preload.href = link.href;
preload.rel = 'preload';
preload.as = 'script';
preload.crossOrigin = 'anonymous';
document.head.appendChild(preload);
}
}
</script> (In Firefox, this will cause the files to be requested twice, because reasons. But tough shit Firefox! This is what you get for not implementing In reality we probably wouldn't <script>
const { relList } = document.createElement('link');
if (!relList?.supports('modulepreload')) {
for (const src of ${s(modules)}) {
const link = document.createElement('link');
link.rel = 'preload';
link.as = 'script';
link.href = src;
link.crossOrigin = 'anonymous';
document.head.appendChild(link);
}
}
</script> With this approach, we don't need to eagerly evaluate anything. |
9b71ed9 implements the idea above. It results in a nice speedup on Safari: Before(The stragglers in the lower right are lazily imported by design and can be safely ignored.) AfterAs mentioned, it does cause double requests in Firefox, but the needs of the many outweigh the needs of the few. I think this is ready to merge into #8957. |
it's a good point. i added some comments to hopefully make things clearer (and |
Mhm shit I just realized that adding the new adapter API means we need a major version bump of adapter static (to bump the kit peer dep), but I think it isn't backwards compatible such that the current adapter static version can continue to work without it. What now? |
$env/dynamic/public
generation<script>
, implementing preloading on safari
* separate app code from framework code * fix, simplify * changeset * DRY * try this? * Revert "try this?" This reverts commit a08b5d8. * simplify * debug logs * Revert "debug logs" This reverts commit ec618f5. * bump timeout * set public env in `<script>`, implementing preloading on safari (#9018) * load public env lazily * not sure why this fixes it but hey * fix tests * fix test * eager imports * use a hacky polyfill instead of eagerly importing * hash things up a bit * use header/element combo * remove hack * add an explanatory comment * remove TODO * implement generatePublicEnv * fix test * add a clarifying comment * fix tests * Update packages/adapter-static/test/test.js * ugh let this be the last one * always inline public env * fix * remove unused re-export * lint * lint * tidy up * add missing .env file * tidy up * get rid of set_version * set assets from window * load app eagerly * huh * fix test * fix * tidy up * changesets --------- Co-authored-by: Simon Holthausen <[email protected]>
env
from server renders if$env/dynamic/public
isn't used #8946This changes how
$env/dynamic/public
is populated in such a way that we can eagerly import the modules required for the current route.In the case where
paths.assets
is not specified, we can generate_app/env.js
dynamically (except in theadapter-static
case — will need ageneratePublicEnv()
method for that). By rejiggering the Rollup output such that all modules inside_app/immutable
are at the same depth, we can use a combination of Rollup'sexternal
andoutput.paths
config to turn any references to$env/dynamic/public
into relative imports.Where
paths.assets
is specified, we don't have this luxury. In those cases we need to populate$env/dynamic/public
the same way we currently do, by setting it from a<script>
on the page. In order to ensure it's ready before any eagerly imported modules evaluate, we must assign it to a global variable at the top of the<head>
.generatePublicEnv()
methodPlease don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. Changesets that add features should beminor
and those that fix bugs should bepatch
. Please prefix changeset messages withfeat:
,fix:
, orchore:
.