export function get(req, res) { if (req.headers.authorization) { res.writeHead(200); res.end(JSON.stringify({ message: req.headers.authorization })); } else { res.writeHead(200); res.end(JSON.stringify({ message: 'unauthorized' })); } }

Allows you to use sapper with an API service residing in another server. This is especially useful if your API server is written in another language

We implemented isomorphic fetching (i.e. fetching with the browser's implementation on the client and node-fetch on the server)

fetch: (url: string, opts?: any)

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.

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

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.

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.

Preload is the Sapper equivalent to getInitialProps in Next.js or asyncData in Nuxt.js.

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:

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.

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.

It's designed for Single Page Applications (SPA). If you need Server Side Rendering then consider using Sapper.

Next.js is a React framework from Vercel (formerly ZEIT), and is the inspiration for Sapper. There are a few notable differences, however:

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.

export let client; setContext("client", client);

This was the easiest way forward until this lib integrates with the Sapper primitives.