packages/solid/src/client/core.ts (next, 344ed05), in the createContext JSDoc, lines 64–66:
If you want truly app-wide state, don't use Context — a module-scope signal/store is a global. Context is for scoping state to a subtree; that's why a Provider is required.
Taken on its own this is fine for a client-only app, but with ssr: true a module is evaluated once per server process, so a module-scope signal or store is shared by every request. A store derived from a server function at module scope leaks one user's data into another's render, and the module-scope signal has no owner to dispose it.
The 2.0 docs take the opposite stance for exactly that reason (Components and JSX → Context: "Prefer this over a module-scope signal or store. Module-scope state has no owner, and on the server one module instance is shared across requests"; the State management guide has a worked example of the failure). The reference page for createContext is generated from this JSDoc, so the two currently contradict each other on the same site.
Suggested wording:
Context is for state that belongs to a subtree, which includes app-wide state in an app that renders on the server: a value created inside a component is created once per request, and the Provider owns and disposes it. Module scope is shared by every request in the same process, so reserve it for constants.
Related, smaller JSDoc items found by type-checking the docs' generated examples:
packages/web/server-functions/src/server.ts line 3239, handleServerFunctionRequest @example: import { handleServerFunctionRequest } from "@solidjs/web/server-functions". That subpath is the client entry; the function is exported from @solidjs/web/server-functions/server.createContext / useContext @example blocks render <TodoList /> where TodoList is a // ... stub with no return value, so the example fails tsc as written. A return null; (or return <ul />;) in the stub fixes it.useContext has @description https://docs.solidjs.com/reference/component-apis/use-context, a 1.x URL.
packages/solid/src/client/core.ts(next, 344ed05), in thecreateContextJSDoc, lines 64–66:Taken on its own this is fine for a client-only app, but with
ssr: truea module is evaluated once per server process, so a module-scope signal or store is shared by every request. A store derived from a server function at module scope leaks one user's data into another's render, and the module-scope signal has no owner to dispose it.The 2.0 docs take the opposite stance for exactly that reason (Components and JSX → Context: "Prefer this over a module-scope signal or store. Module-scope state has no owner, and on the server one module instance is shared across requests"; the State management guide has a worked example of the failure). The reference page for
createContextis generated from this JSDoc, so the two currently contradict each other on the same site.Suggested wording:
Related, smaller JSDoc items found by type-checking the docs' generated examples:
packages/web/server-functions/src/server.tsline 3239,handleServerFunctionRequest@example:import { handleServerFunctionRequest } from "@solidjs/web/server-functions". That subpath is the client entry; the function is exported from@solidjs/web/server-functions/server.createContext/useContext@exampleblocks render<TodoList />whereTodoListis a// ...stub with no return value, so the example failstscas written. Areturn null;(orreturn <ul />;) in the stub fixes it.useContexthas@description https://docs.solidjs.com/reference/component-apis/use-context, a 1.x URL.