SvelteKit is moving at the speed of sound to reach v1.0.0 and hence the team is juggling between pressure from the community to publish features proposed in the RFC while early adopters rant about how the team is not giving them enough time to soak in the new changes.
However, these changes are aimed at making the framework more expressive and simple and that's what we all want and love about Svelte
[Tip] Please follow the Discussions and read the CHANGELOG.md to stay updated on the breaking changes
What's Changed
- (group) layout replaces named-layout #6124
-
#6124 in particular makes it very easy to avoid hacking named-layouts to break out of the inherited layout that was released in
svelte-kit, 1.0.0-next.306#4388. See CHANGELOG.md
-
#6124 in particular makes it very easy to avoid hacking named-layouts to break out of the inherited layout that was released in
The Problem with Named Layouts
Named Layout allowed you to specify exactly which layout your +page.svelte and +layout.svelte files should inherit by appending @name where @name is the part of the layout file name between the +layout- and .svelte extension.
Example: a +page.svelte or +layout.svelte file that wishes to inherit from a layout with the name +layout-settings, would have to be renamed as +page@settings.svelte or +layout@settings.svelte respectively
Using folder structure:
src/routes/
├ courses/
│ ├ +page.svelte
│ └ +page.ts
├ lecturers/
│ ├ +page.svelte
│ └ +page.ts
├ schedules/
│ ├ +page.svelte
│ └ +page.ts
├ settings/
│ ├ +page@settings.svelte
│ └ +page.ts
├ login/
│ ├ +page@auth.svelte
│ └ +page.ts
├ register/
│ ├ +page@auth.svelte
│ └ +page.ts
├ [deeplink=action]/
│ ├ +page.svelte
│ ├ +page.ts
│ └ +layout@root.svelte
├ +layout.svelte
├ +layout-auth.svelte
├ +layout-settings@default.svelte
└ +layout-root.svelte
Will give us the following routes:
/
/courses
/lecturers
/schedules
/settings
/login
/register
/reset-password?email=parables95@gmail.com - deeplink
/verify-email?email=parables95@gmail.com - deeplink
/success?onboarding=done$redirectTo=home - deeplink
Looking at the folder structure above:
- the
/courses,/lecturersand/schedulesroutes will inherit from the layout fromsrc/routes/+layout.svelte - the
/settingsroute will inherit from both the default parent layoutsrc/routes/+layout.svelteand thesrc/routes/+layout-settings.sveltelayout - likewise, the
/loginand/registerroutes will break out from the default parent layoutsrc/routes/+layout.svelteand will rather inherit from thesrc/routes/+layout-auth.sveltelayout - the deeplink routes will inherit from the immediate layout file
src/routes/[deeplink=action]/+layout@root.sveltewhich in turn will also inherit from the named layoutsrc/routes/layout-root.sveltesince it explicitly specifies the@rootin the layout name
This layout hacking method will it makes it easy to infer the routes using the folder structure makes it a bit harder to understand where routes belongs to.
For example I would want to group /courses, /lecturers and /schedules under dashboard but if I create a new directory src/routes/dashboard and the routes into the dashboard directory, my routes becomes /dashboard/courses, /dashboard/lecturers and /dashboard/schedules and that's is not what I want. I want to keep them on the index level and not nest them in the /dashboard level.
(group) layouts to the rescue
To address the problems posed by named-layouts, (group) layouts allows you to group your routes in a a special directory which is named in parenthesis (dashboard) to indicate that this directory is only meant for group layouts and hence it doesn't appear in the route's URL
Our new folder structure now becomes
src/routes/
├ (dashboard)/
│ ├ courses/
│ │ ├ +page.svelte
│ │ └ +page.ts
│ ├ lecturers/
│ │ ├ +page.svelte
│ │ └ +page.ts
│ ├ schedules/
│ │ ├ +page.svelte
│ │ └ +page.ts
│ ├ settings/
│ │ ├ +page.svelte
│ │ ├ +page.ts
│ │ └ +layout.svelte
│ ├ +page.svelte
│ ├ +page.ts
│ └ +layout.svelte
├ (auth)
│ ├ login/
│ │ ├ +page.svelte
│ │ └ +page.ts
│ ├ register/
│ │ ├ +page.svelte
│ │ └ +page.ts
│ └ +layout.svelte
├ (deeplink)
│ ├ [deeplink=action]/
│ │ ├ +page.svelte
│ │ └ +page.ts
└ +layout.svelte
Our directory now looks cleaner, and it is more easy to reason out where the layout belongs. Knowing that any folder in parenthesis () wont, appear in the URL, one can easily read out the the route structure, by ignoring any (group) named folder in the hierarchy.
the
/courses,/lecturers,/schedulesand the/settingsroutes will all inherit from the layout fromsrc/routes/(dashboard)/+layout.svelteas well as thesrc/routes/+layout.svelte/loginand/registerwill also inherit fromsrc/routes/(auth)/+layout.svelteas well as thesrc/routes/+layout.svelteWhile
src/routes/(dashboard)/+page.sveltewill be the index/homepage.Remember, (dashboard) is ignored in the route hierarchy making
src/routes/(dashboard)/+page.svelteat the same level assrc/routesso please keep that in mind before you throw another+page.svelteat the same level or else SvelteKit will crash and throw back at you a nice error message
Error: and (dashbaord) occupy the same route
Pages and layouts inside groups — as in any other directory — will inherit layouts above them, unless they break out of the layout hierarchy.
A page can break out of a layout by specifying the name of the folder that contains the layout file you want to inherit.
For example to beak the
/settingsroute from inheriting from thesrc/routes/(dashboard)/+layout.svelteto rather inherit a parent layout above it like the root layout insrc/routes/+layout.svelte, you can renamesrc/routes/(dashboard)/settings/+page.sveltetosrc/routes/(dashboard)/settings/+page@.sveltewhere@represents the root layout in the hierarchy.Also, if there are parent layouts in the hierarchy above that you want a page to break out of its current inheritance and inherit from parent layout, specify
@(parent-group)or@parent-folderTo break out of the layout uses a similar convention as the page. Simply use
@followed by the name of a folder above in the hierarchy where the layout you want to inherit is like@(parent-group)or@parent-folder.A
+layout@.sveltecomponent would reset the hierarchy for all its child routes.
Migrate your SvelteKit app to use (group) layouts
- Delete the
node_modulesfolder and the.sveltekitand thepackage-lock.jsonor the-lockfile for any package manager you are using
rm -rf node_modules .sveltekit
rm package-lock.json # change it as per your package manager `pnpm` or `yarn`
- And reinstall the packages again using your preferred package manager
npm install
This is necessary in order to ensure that you have the latest versions of the dependencies.
-
npm-check-updates
ncumay not be helpful here so play it safe and reinstall all your dependencies
That is the cost you've to pay for rolling on the bleeding-edge
Conclusion
SvelteKit is amazing and Rich-Harris and the team are making great improvements to make it more awesome.
We really appreciate them for everything they are doing to make out lives easier and simple as developers.
Seen a typo, noticed something wrong in the article, still confused, share your thoughts in the comment section below or find me on Svelte's Discord channel @parables_boltnoel
That's all for this post. If this post has helped you, spread the love and help others by sharing it.
See you in the next update
Top comments (1)
thanks!