**Context**
In order for the SvelteKit app to work in production and to ensure that navigating between the React and SvelteKit app "just works" a couple of things need to happen:
- the server needs to know for which routes to serve the SvelteKit app
- when navigating to a new page, the React app needs to know whether that page should be served by the SvelteKit app or not. If it should, it performs a page refresh, which will cause the server to send the SvelteKit app.
- the same applies to the SvelteKit app, but vice versa, except that it performs a page refresh automatically for every route that it doesn't support (the SvelteKit app is a subset of the React app).
Until now this logic was controlled by the `web-next` and `web-next-rollout` feature flags.
When `web-next` is set the server will serve the SvelteKit app for all routes supported by the app.
When `web-next-rollout` is set the server will server the SvelteKit app only for a certain subset of pages.
These two sets of pages are currently maintained separately in different places on server, the React app and the SvelteKit app. Multiple steps need to be taken to make a SvelteKit page available in production and that is not easy to maintain.
**New approach**
With this new approach, making a SvelteKit page available in production is much simpler.
To make it available as "opt-in" (`web-next` feature flag):
1. Add new page as usual.
2. Run `sg generate`.
To roll it out by default on e.g. S2 (`web-next-rollout` feature flag).
1. Add `// @sg EnableRollout` to the corresponding `+page.ts` file.
2. Run `sg generate`.
**How it works**
Ultimately what the server, the React app and SvelteKit app have to do is determine whether the SvelteKit supports a given path name.
Because SvelteKit uses file based routing we can determine at build time which SvelteKit routes exist. We can also take the route IDs and convert them to regular expression, [much like SvelteKit does itself](ed8970ef74/packages/kit/src/utils/routing.js).
By adding a "meta data comment" of the form `// @sg <tag>` we can mark a page to be e.g. enabled by default via the `web-next-rollout` feature flag.
Having this list of regular expression, the server can decide whether or not to serve the SvelteKit app by running the pathname of the current request against the list.
The same list can be passed to the React and SvelteKit clients via `window.context`, and the clients can perform exactly the same tests when the user navigates to a new route. More specifically, in this current iteration the clients each get their own copy of the complete list and the server only sends the indices of the enable routes.
Overall this makes it
- much easier to manage the availability and rollout state of SvelteKit pages
- reduces the complexity of checking whether or not SvelteKit is enabled or not on the server, React app and SvelteKit app
**Repository root handling**
What makes the whole situation more difficult is the fact that the repository root is essentially a catch all route. That means for a client to decide whether or not a target path is a page or a repository it has to know about all the existing pages. That's why the server sends a list of known routes (extracted from gorilla mux) to the clients.
cb596f4d7f