34 Matching Annotations
  1. Mar 2021
    1. What I like is that currentUser isn't a value, it's a store, and therefore you have full control over how you deal with it.
    2. Talking of context, that's much closer to the approach I take with Svelte and use a writable store.
  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. session can be used to pass data from the server related to the current request. It is a writable store, meaning you can update it with new data. If, for example, you populate the session with the current user on the server, you can update the store when the user logs in. Your components will refresh to reflect the new state
    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
    1. It's really helpful that Svelte stores are easy to use in plain JS. We can change a state store over completely to Svelte and make the Angular components subscribe to that store as well without needing to maintain and sync 2 copies of the state.
    1. This subscription function must be immediately and synchronously called with the store's current value upon calling .subscribe. All of a store's active subscription functions must later be synchronously called whenever the store's value changes.
    2. Assignments to $-prefixed variables require that the variable be a writable store, and will result in a call to the store's .set method.
  4. Oct 2020
    1. Generally, you should read the value of a store by subscribing to it and using the value as it changes over time. Occasionally, you may need to retrieve the value of a store to which you're not subscribed. get allows you to do so.
    1. const store = readable(machine.initialState, set => { service.subscribe(state => { if (state.changed) set(state) }) service.start() return () => { service.stop() } })
    2. The readable store takes a function as a second argument which has its own internal set method, allowing us to wrap any api, like Xstate or Redux that has its own built in sub­scrip­tion model but with a slightly different api.
    3. Indeed, this simple contract is very close to that of an ob­serv­able, such as those provided by Rxjs. set is basically equiv­a­lent to next in the ob­serv­able world.
    4. The $ contract for auto-sub­scrib­ing is lovely in its sim­plic­ity and flex­i­bil­ity. You can adapt your own preferred state-man­age­ment pattern or library, with or without Svelte stores as helpers. Svelte does not fuss about how you want to manage your state.
    5. Arguably what is in­ter­est­ing about Svelte’s approach to state man­age­ment is not the store itself but the auto-sub­scrip­tion that is possible because of the Svelte compiler. By simply appending a $ to a variable inside of a component, e.g. $myVariable, the compiler will know to expect an object with a subscribe method on it and generate the boil­er­plate of sub­scrib­ing and un­sub­scrib­ing for you.
  5. Sep 2020
    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.
    1. This is pretty good, but I don’t love that $contactStore.length bit. If we wanted to change the shape of the store from an array to a key-value store or something, we’d have to remember to update this component too. Instead, we can define a new derived store: contactCountStore. It’ll always track the count, which lets this component have less knowledge about the structure of the store. That refactor looks like this:
    1. You're not limited to using $count inside the markup, either — you can use it anywhere in the <script> as well, such as in event handlers or reactive declarations.

      Don't forget to make the statement reactive. Referencing $count is not enough to get it to be re-run on update!!


      $: console.log(`the count is ${$count}`);
    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?
    1. For interoperability with RxJS Observables, the .subscribe method is also allowed to return an object with an .unsubscribe method, rather than return the unsubscription function directly.