this happens with getClient and setClient because it is a svelte context which is only available at component initialization (construction) and cannot be in an event handler.

Talking of context, that's much closer to the approach I take with Svelte and use a writable store.

The more I think about this, the more I think that using the context API (for all the stores — page, preloading and session) is the most regret-proof approach, using the proposal above

Just realised this doesn't actually work. If store is just something exported by the app, there's no way to prevent leakage. Instead, it needs to be tied to rendering, which means we need to use the context API. Sapper needs to provide a top level component that sets the store as context for the rest of the app. You would therefore only be able to access it during initialisation, which means you couldn't do it inside a setTimeout and get someone else's session by accident:

Another difference is that context in Svelte does not insert anything into the visual component tree. There is no <Context.Provider> element like in React

I too have been confused by behavior like this. Perhaps a clearly defined way to isolate atomic units with synchronous reactivity would help those of us still working through the idiosyncrasies of reactivity.

It lives in a context="module" script — see the tutorial — because it's not part of the component instance itself; instead, it runs before the component is created, allowing you to avoid flashes while data is fetched.

setClient(writable(apolloClient)); let client getClient().subscribe((_client) => client = _client);

I got this working by using _layout.svelte as the point to initialise and set the Client we can then use getClient in each route that uses this layout.

setContext / getContext can only be used once at component init, so how do you share your API result through context? Related: how would you share those API results if the call was made outside of a Svelte component, where setContext would be even more out of the question (and the API call would arguably be better located, for separation of concerns matters)? Well, put a store in your context.

setContext must be called synchronously during component initialization. That is, from the root of the <script> tag

If calling query() results in calls to Svelte's context API, then it needs to be called synchronously during component initialization.

Stores are global state. While context is local state.

Notice it's not related to components. Another crucial difference is that it's accessible from outside of components. And good way to determine where goes where is to ask yourself, can this particular state and functionality still makes sense outside of the displayed component?

In fact, you might use the two together. Since context is not reactive, values that change over time should be represented as stores: