Setup each page - init hook, `export const blocking`, etc.

[stalkerg]

Describe the problem

For i18n or similar subsystems, we should make initialization before any language things are needed, and for such initialization, we usually use a session (user language) and information from the HTTP request.
Before the new routing system was introduced, we were using the root __layout.svelte to do it, it's working well for SSR and CSR time.
I should mention that what i18n should be inited on the server side and init on the client side as well (or state should be send as is).

After migration to new routing, we lose one "transitional" place to init such thing because +layout.js can be called after +page.js, and you must do await parent() in each page to avoid such race condition.

For server-side only init, we have a good place it's handle in hooks.js with event.locals it's an excellent way to init server only things like DB connection, but for things what should be a transition from SSR to CSR we have no place.

I also have a similar issue for i18n implementation project what I use cibernox/svelte-intl-precompile#55

Describe the proposed solution

Maybe it's possible to do it more straightforwardly, but at least we need a global hook for what will be called on SSR and on CSR, after +layout.server.js but before +layout.js and +page.js.

Alternatives considered

No response

Importance

would make my life easier

Additional Information

No response

[dummdidumm]

If I understand you correctly, it could work today for you, too, but you'd have to do await parent() in each layout/page, which is cumbersome. I had this concern, too. My idea was to introduce export const blocks = <boolean> to +layout.js (and possibly to layout.server.js) so you have to write it in one place only for situations like this.

[stalkerg]

@dummdidumm right, but honestly, I suppose +layout.js it's not a good place, and for me, it just should be before +layout.js and +page.js (doesn't care who first) it's not directly tied with the layout. Also, because we can have a named layout, I don't want to duplicate this logic of how I should do it now.

[elliott-with-the-longest-name-on-github]

@dummdidumm right, but honestly, I suppose +layout.js it's not a good place, and for me, it just should be before +layout.js and +page.js (doesn't care who first) it's not directly tied with the layout. Also, because we can have a named layout, I don't want to duplicate this logic of how I should do it now.

This would be solved by the new Layouts proposal as well, since the root layout would always exist.

[stalkerg]

@tcc-sejohnson I see, in that case, it can work, but from a semantic point of view, it's not good. It's not a layout anymore if you understand what I mean.

[elliott-with-the-longest-name-on-github]

@tcc-sejohnson I see, in that case, it can work, but from a semantic point of view, it's not good. It's not a layout anymore if you understand what I mean.

We've had this discussion before and pretty much just decided "Layout doesn't mean literally just laying things out on the page. You can lay data out for your app as well." No one's been able to come up with a better term, so I'd just adjust your understanding of the word.

(If you look at the dictionary definition, "the way in which the parts of something are arranged or laid out", it actually does apply to data as well. You're "arranging your app", not just "arranging the visual layout of a page".)

[stalkerg]

You're "arranging your app", not just "arranging the visual layout of a page".)

It's very confusing in the frontend context but I got it. One more comment if you permit: initialization of i18n is not data.
Anyway, where can I check this proposal or PR?

[elliott-with-the-longest-name-on-github]

@stalkerg

#6124

[stalkerg]

@tcc-sejohnson I do not fully understand how a new proposal can solve this issue because. Root layout exists even now (+layout.js) in my case, but it's run after +page.js when I need access to i18n features.

[cibernox]

I'm going to drop here some background on prior art on how other frameworks, in this case Ember.js, approached this problem of having code that needs to run before the continues the boot process and that code may or may not be blocking.

In Ember such code was put in /initializers and /instance-initializers. The functions there ran before the app booted and were typically used to setup critical initial configuration (i18n is an obvious example of setup that should run as early as possible because it will affect how everything else is rendered. Configuring user credentials if there's some kind of API wrapper singleton could be another one).
If those functions returned a promise, the app boot's process would block until that promise resolves. If no promise is resolved the boot process continues without delay.

The shade of meaning between initializers and instance-initializers was that initializers ran once in the entire lifetime of the app, even in SSR, while instance-initializers ran once in the browser but once per request in SSR.

Initializers also had names and accepted before/after: otherInitializersName in case there were many and the execution order was important, much like rollup plugins.

I just mention this because IMO Ember got this reasonably right. Sveltekit may decide to come up with a different abstraction, but it's good to know how others approached similar problems in the past.

[benmccann]

export const blocking would work - though it'd also mean that you need an extra route group in most cases. E.g. a layout that just does the i18n setup discussed here in a blocking fashion, then a layout that loads the user in a parallel fashion and displays the layout UI. I'm not sure how annoying this would be in practice, but probably at least some