21 Matching Annotations
  1. Dec 2020
    1. The only solution that I can see is to ensure that each user gets their own set of stores for each server-rendered page. We can achieve this with the context API, and expose the stores like so: <script> import { stores } from '@sapper/app'; const { page, preloading, session } = stores(); </script> Calling stores() outside component initialisation would be an error.

      Good solution.

    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
    2. Preload functions are typically used to load data that the page depends on, hence its name. This avoids the user seeing the page update as it loads, as is typically the case with client-side loading.
    3. Page components can define a preload function that runs before the component is created. The values it returns are passed as props to the page.
    4. Preload is the Sapper equivalent to getInitialProps in Next.js or asyncData in Nuxt.js.
    1. With this change, we can re-run preload when the session store changes, e.g. as a result of something like this in a nav bar:
    2. I have a feeling that this functionality is scuppered by #415 - since my browser caches the page for 10 minutes, meaning that the page is never hit and thus the preload is never run, regardless of whether session has been changed or not.
    1. Say I have a separate API server that provides content for a Sapper route. I could just query that API in my route's preload function, but if the content changes rarely, I don't want to incur that cost for every page load and would much rather cache responses from the API on the Sapper side.
  2. Nov 2020
      • Functional blockchain library in Typescript
      • Svelte & Sapper for all things UI.
      • Blockchain sync with IndexedDB and reactivity hook.
      • Created some mini-apps to refine and test the core functionality.
      • User Authentication flow.
      • MVP: Kanban app.
  3. Oct 2020
  4. Sep 2020
    1. Next.js is a React framework from Vercel (formerly ZEIT), and is the inspiration for Sapper. There are a few notable differences, however:
    2. page components can have an optional preload function that will load some data that the page depends on. This is similar to getInitialProps in Next.js or asyncData in Nuxt.js.
    1. export let client; setContext("client", client);

      Wouldn't this set context to undefined initially? And reassigning a new value to client wouldn't update the value stored in the context, would it? It would only update the let client variable.

      Where does this let client actually get set to the client from async function preload? I guess I need to understand Sapper more to know how this works, but it doesn't seem like it could.

      Update: I think I found the answer (it runs before):

      https://hyp.is/3aHeJgNFEeunkCsh8FVbDQ/sapper.svelte.dev/docs/

      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.

    2. This was the easiest way forward until this lib integrates with the Sapper primitives.
  5. Jul 2020