Rename `context` to `stuff`

[benmccann]

There are a couple different places we use the word context

• load has a context parameter
• getContext sets request.context

Adding this here to track and have a discussion at some point since a couple maintainers have mentioned this as being something we might want to considers

Also, it looks like perhaps we should fix this TODO in the process:

kit/packages/kit/src/runtime/server/page/respond.js

Line 178 in 08ebcb5

// TODO come up with better names for stuff

[furudean]

Yes please! I frequently see confusion on whygetContext() is not what is expected in a load() function. It probably doesn't help that the documentation on the matter is a bit sparse.

[rmunn]

Should one be called serverContext and one be called clientContext? Except that load runs on the server and the client, so that's no good. How about endpointContext vs loadContext? Or just leave it called context when it's the thing returned by getContext, but call it loadContext in the load functions? I'm not strongly in favor of any of these, I'm just throwing out ideas here.

[Rich-Harris]

I'm less concerned about the difference between context in load and getContext than I am about the overlap between context in load and request.context. If we could rename the latter, I think this would be less of an issue.

My previous suggestion was request.metadata/getMetadata(...) but people didn't love it.

getRequestInfo(...) -> request.info?

getRequestState(...)/getState(...) -> request.state?

[benmccann]

getState(...) -> request.state sounds good to me

[Leftium]

The overloaded use of context definitely made SvelteKit more confusing and difficult for me to learn. Documenting what I see to be sources/inspiration for this conflict:

• getContext() -> request.context resembles serverless lambda functions. (See Netlify or AWS API documentation.)
• load({ context }) resembles React's context API for sharing data between components.

---

I propose changing load({ context }) to load({ info }):

• Keep getContext() -> request.context because of deep parallels with the context in serverless lambda functions. (AWS/Netlify/etc...)
• Many React context API tutorials often refer to managing "global component state". (React may have avoided using state because it already has a special meaning.)
• However "state" seems to imply changes will be persisted/propagated back. Especially for those coming from React. So I prefer "info."
• load({ componentContext }) is more descriptive, but results in a long variable name. It's really hard to find a term that describes one-way data-passing like "context"!

---

While we're discussing confusing naming, I think the "get" in getContext() and getSession() are named from the wrong perspective/direction:

• Before I grokked how these hooks work together, I thought getContext() would be a method for getting information automatically generated by the server/SvelteKit runtime for the app/developer.
• However, it's the place where apps/developers set information to be consumed later.
• Even the documentation says "[getContext] generates..." So generateContext() would make more sense.
• How about createContext() or setContext()?

[Leftium]

I just remembered the vanilla Svelte context API exists and already defines a getContext(). (Used in conjunction with setContext() for sharing data with child components.)

• So that's a strong argument for changing getContext()/request.context.
• Is there any reason SvelteKit doesn't simply use the existing Svelte context API? It's a little more verbose, but I think it's conceptually easier to understand.

I tried mapping out the different flow of information for the two different contexts:

[Conduitry]

When context is getting passed down from async load to async load, none of the components exist yet, and so we can't use Svelte's concept of context.

[Leftium]

I figured out how to replace request.context with a more meaningful name:

1. getContext()->request.context becomes addSession()->request.session (Add property request.session instead of request.context.)
2. getSession() is renamed to websafeSession(session), and keeps protecting sensitive info from load({session}).

Bonus: easier to see the connection between request.session and load({session}).

Optional enhancements:

• The default implementation of websafeSession(session) automatically passes request.session.WEBSAFE_* properties to load({session}) (Like the convention for VITE_ environment variables).
• getContext() becomes adjustRequest(Request) => Request making it possible to do other things besides just adding a session property.

[DhyeyMoliya]

One more idea :

1. Hook getContext() renamed to getServerContext()
2. Hook getSession() renamed to getClientSession()
3. Server-side (Hooks, Endpoints) context renamed to serverContext
4. Client session stays session
5. Client context in load stays context

[Rich-Harris]

The core team just had a long conversation about this and we like request.locals instead of request.context. Rather than having a getLocals(request) function we can do request.locals = {} before we pass it into handle:

function handle({ request, render }) {
  request.locals.user = get_user(request);
  return render(request);
}

function getSession(request) {
  return {
    user: sanitize_user(request.locals.user)
  };
}

We also spent entirely too long trying to come up with an alternative to layout context, but couldn't come to agreement. Some ideas that were floated, in no particular order of terribleness:

• inherit
• inherits
• inherited
• pipe
• chain
• context (keep as is)
• locals (again)
• tunnel
• metadata
• env
• scene
• domain
• foo
• $layout

[Rich-Harris]

• payload
• bag
• obj
• _