I absolutely love the new direction of SvelteKit

[AlbertMarashi]

Don't have much time to type this, but I'm really happy with all the recent changes SvelteKit team has done.

The new load api, filesystem routing and other changes are great. People will come around despite how annoying some of the changes may seem.

After using it for some time, it's great, but the documentation was kind of difficult to understand and limited.

The new way of managing types and the automatic type creation with SvelteKit is great.

[rmunn]

Between this and #6005, the upvotes might turn into an informal poll.

[oxisto]

Which BTW I never intended to :) I just wanted to relieve some of my emotional pain, so did others apparently by the various responses :)

[AlbertMarashi]

Docs definitely were a bit confusing, found it difficult as hell to migrate and also confused about how everything worked, but I eventually figured it all out

I understand this is all WIP so i'm not complaining

[danawoodman]

Should be able to just do this:

// +page.ts
import type { PageLoad } from './$types'

export const load: PageLoad = async (event) => {
  ...
}

No need to add the parameter typing; it's inferred.

[samuelstroschein]

The most "TS" way in my opinion:

import type { PageLoadEvent } from './$types';

export function load(event: PageLoadEvent) {
	return {
		example: 'hello'
	};
}

• Make sure that the dev server is running. Otherwise, the types are not generated.

[danawoodman]

Why is this the most "TS" way? Arrow or named functions are both just ES6

This doesn't type the return value unless I'm mistaken.

[samuelstroschein]

Most "TS", or rather JS, way because it's a function. Explaining const load = async (event) => { to beginners is challenging.

This doesn't type the return value unless I'm mistaken.

That is true but because it's not necessary and was annoying. The return type is generated by SvelteKit based on the function. Aka no matter what the return type is, it will change the moment the return statement is changed.

[danawoodman]

I also prefer function to define named functions but there is nothing wrong with someone using/preferring arrow functions instead.

[ZetiMente]

Umm, the Routing page still isn't updated...

[eddiemcconkie]

Routes are not the same as pages. A route can lead to a page or an endpoint depending on the route file inside the directory, so the description is accurate

[ZetiMente]

The description is accurate to you because you are filing in context that a beginner wouldn't have.

For starters, src/routes/about could be a file or a folder. Something like src/routes/about/ would be much more clear since people might have the impression that they can still do about.svelte. (You have to remember, all the Youtube videos, blogs and educational material is still on the old routing system)

Secondly, a file inside the directory actually isn't a route, it's a component because everything is private by default unless it has a + at the front of it. Therefore only src/routes/about/+ would be true.

Third, only pages and endpoints of the exact names of +page.svelte, +page.js or +page.server.js are actually routes. So just any file in the directory wouldn't work. So it's not accurate or at least clear enough to anyone not familiar with SK.

Finally, There is no clarity at all that the route only exist if it has + in front of the name of the file. That should be in big cap letters. ONLY FILES OF THESE NAMES WILL WORK. A FILE MUST HAVE A + IN FRONT OF IT TO WORK.

The documentation before jumped into the differences of a page and endpoints. Now with a more confusing routing system, it isn't clear at all that the + makes a route public and that the name of +page.svelte/+page.js/+page.server.js is required. The docs give the impression that the +page.svelte could be anything like +help.about or +about.svelte.

Like if you were reading that for the first time, you would think they were using +page.svelte as an example. Not as that it actually has to be exact +page.svelte. You may even do about.svelte because you probably wouldn't have grasped that + makes it public from only "Each route directory contains one or more route files, which can be identified by their + prefix."

If the idea now is that people see the +, get confused and come to RTFM. Shouldn't the docs be extremely explicit on what is happening?

[braebo]

@ZetiMente Everything is explained right below your screenshot.

[ZetiMente]

How is that everything explained? That sentence is very vague and It doesn't make clear at all that the + is required. Nor does it make it clear that the page name has to be +page.svelte. Someone could think that page is a placeholder for any name.

[oxisto]

What's incorrect about it in your opinion?

It could be missunderstand that the mere existence of the directory already creates the route, which is incorrect. If one creates an empty src/routes/about folder, no route is created. Only by putting at least. one route file in there, the route is actually created.