-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
[breaking] ssr/hydrate/router/prerender.default
are now configurable in +page(.server).js
and +layout(.server).js
#6197
Conversation
🦋 Changeset detectedLatest commit: d111a21 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
I created #6207 as the enhanced version of this. I'd say that PR is a worthwhile addition and I doubt that the performance overhead of an additional lazy load is noticeable. |
Replies to the conversation in #6207: I have used ...is a block of HTML extracted from a statically rendered SvelteKit app and placed onto the homepage. Disabling the router for the entire embed means that links will always take you to a fresh page, instead of trying to navigate within the homepage, which makes authoring the banner much easier (particularly when it uses components that are common to the whole app).
Why does that need to be a // src/lib/config.js
import { env } from '$env/dynamic/public';
export const ssr = !env.PUBLIC_DISABLE_SSR; // +page.js
export { ssr } from '$lib/config.js'; The argument against allowing layouts to set |
Do we want to allow configuring page options in |
is quite painful because it needs to be added to every individual page in your application and you'd need a |
Co-authored-by: Rich Harris <[email protected]>
Co-authored-by: Rich Harris <[email protected]>
Co-authored-by: Rich Harris <[email protected]>
The Re configuring them in -> all options should be configurable in |
only because of this PR! I'm saying that I'm not totally convinced that's a good idea, as it leads to ambiguity. At the very least we need to talk about the semantics because I don't think 'child beats parent' makes sense for |
I'm definitely okay with that — Google agree it's a bad idea |
I definitely want this to be possible to set in layouts as well. The main use case I see for this is to disable SSR for sections of your app (like the admin section), not for single pages. So what would be better semantics then? "As soon as it's explicitly disabled it cannot be enabled again, because if you disable it in a layout it means you express that the layout already could have client-only code"? I don't know, this feels more complicated to explain and you lose out on some options when you "know what you are doing". "Last one wins" has my vote because of this. |
'Last one wins' is definitely the option that's easiest to apply consistently across page options, so as long as we're not worried about a layout declaring If we do implement layout-level options then we could presumably eliminate |
Agree that we should do it as part of this PR then. If we do remove those options, do people have all possibilities still to enable/disable it? In other words, do they have access to globals/variables they cannot access in their root layout? |
Apart from controlling
I'm not too worried about this — I'd expect almost all apps to need one eventually, so I'd file it under 'meh' personally |
This reverts commit 4dcee25.
We'll need to update the migration guide here after we implement #6436 |
Setting was deprecated. See error: Error: config.kit.prerender.default has been removed. You can set it inside the top level +layout.js instead. See the PR for more information: sveltejs/kit#6197
The default option in svelte configuration is deprecated and will be removed eventually. Error: config.kit.prerender.default has been removed. You can set it inside the top level +layout.js instead. See the PR for more information: sveltejs/kit#6197
As seen here sveltejs/kit#6197 the prerender option has been removed and compilation on never sveltekit versions would fail. Signed-off-by: Marvin Drees <[email protected]>
As seen here sveltejs/kit#6197 the prerender option has been removed and compilation on never sveltekit versions would fail. Signed-off-by: Marvin Drees <[email protected]>
As seen here sveltejs/kit#6197 the prerender option has been removed and compilation on never sveltekit versions would fail. Signed-off-by: Marvin Drees <[email protected]>
This is due to a breaking change in SvelteKit. See PR sveltejs/kit#6197
How to migrate
browser.hydrate / browser.router / prerender.default
hydrate
androuter
have been replaced withcsr
. See #6446 for more info.Remove these options from your
svelte.config.js
and export them from your root+layout.js
or+layout.server.js
instead:(For now, you will need a
+layout.svelte
alongside your+layout[.server].js
— this will be fixed soon.)You can also set these options at lower layouts or inside pages if you want.
For other changes around
prerender
see this PR: #6392handle: resolve(event, { ssr: ... })
The
ssr
option was removed from theresolve
function that is passed into thehandle
hook. Set it at the appropriate+layout.js
or+layout.server.js
or+page.js
or+page.server.js
. The following example shows how to turn off SSR for all admin pages:export function handle({ event, resolve }) { return resolve(event, { - ssr: !event.url.pathname.startsWith('/admin') });
PR description
Closes #6356
Can't believe how little code the actual change is 😄
During implementing this, I realized a shortcoming of the current implementation: If
+page.js
accesses a browser global, for example..then this will fail on the server with an error, even if you did set
ssr
inhandle
. To change this behavior we would need to lazy-loadshared
just like we do withcomponent
already - should we make this change? If yes, should I incorporate it into this PR?Please 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. All changesets should bepatch
until SvelteKit 1.0