cheatsheets devlog projects search

sveltekit-migration.md

Sveltekit Migration to 1.0

2022-12-11 2

This will be my notes on what has changed since the last time I used sveltekit.

https://github.com/sveltejs/kit/discussions/5748

This seems to be the thread that completes and announces the changes so I imagine there is much history and talk before this.

The biggest change has been the shift from .svelte files to +page.svelte and company. It’s an interesting change and I think I can understand why. The old way, anything inside routes was available to through an application. This meant that most things couldn’t be co-located so you would need to make sure the routable areas were truly pages you wanted exposed.

The new way of using page.svelte allows you put various utility files with your svelte files and not have them exposed.

I am a big fan of the +page.server.js and +page.js. It is explicitly clear what is running on the server and what is running in a shared context. This being the same logic for layouts and hooks is also great and easy to pick up.

Another major change is the end of shadow endpoints. They still sort of exist but not the way as they did before. Earlier you could have something.svelte and something.js and the something.js would be automatically run and loaded into the svelte file.

This logic still exists but now you don’t write get/post/patch routes in the endpoint file but its part of the page.server.js file and is an object that you put in it.

For example a page to update data will have a form containing values. +page.server.js will contain a load function that will do the database query and get the data and it will simply return this data. This data is exposed in the svelte file and can be used. The form on the page is populated and you can then add a button to submit it.

The submit button will trigger a function in the same +page.server.js but in an object called actions. It is very similar to the old way but different enough that it wasn’t a straight copy paste of code that I already had.

They have also gotten rid of the json.js api logic which I used only lightly. This always felt hacky but I haven’t had a chance to see what replaced it.

The script context module business is fully done away with which is great. Now that the load function is in its own +page.server.js file, this gets rid of the load function that you would normally have in a svelte file. This has been a welcome change and has definitely made life better.

I use vim so the +page.svelte and so on are a pain in the ass. The prefix stuff is interesting. They chose it because it implies you are adding a public interface which I can get on board with. The prefix removes the need for all the special rules for all the types of files sveltekit considers special.