16 Matching Annotations
  1. Mar 2021
  2. Dec 2020
    1. 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

      Looks like this is the approach that they went with

    1. 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:
  3. Nov 2020
  4. Oct 2020
  5. Sep 2020
    1. 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.
    1. 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.
    2. setContext must be called synchronously during component initialization. That is, from the root of the <script> tag
    1. Stores are global state. While context is local state.
    2. 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?