update

[Rich-Harris]

Alternative to #134. This is more or less a rewrite — it uses all the new idioms we've been adding over the last few months, and it's been an absolute joy

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
realworld	✅ Ready (Inspect)	Visit Preview	Nov 4, 2022 at 3:18PM (UTC)

[yadoga]

Realworld has been a valuable reference (JWT auth etc.) and I frequently refer others to it. Commenting out of appreciation 🙌

[Rich-Harris]

One is that it's really hard to keep information in stores to be able to update layout elements without refetching the whole page.

In the vast majority of cases I think you're better off having a single source of truth, i.e. the server. But if you do need to do that, you can just return a store from a load function, no?

[Rich-Harris]

Another thing was around login/logout. E.g. if you logout with this PR right now it first fetches /settings/_data.json and then fetches /login/_data.json. It seems unnecessary to fetch both. We should just be able to delete the cookie and then navigate to the new page without having to first refresh the current page

The details of what happens depends on whether it's a native or enhanced submission:

• native — we run all the load functions again, including the one in src/routes/settings/+page.server.js, at which point the redirect is thrown and SvelteKit returns a 302 response (should probably be a 307 but whatever). The browser reloads the page to /login
• enhanced — we run all the load functions again, hit the redirect, and /settings/__data.json contains instructions to redirect. SvelteKit navigates client-side to /login, requesting data from the server as it does so

Admittedly there's some room for micro-optimisation here — if we redirected at the end of the logout action we wouldn't need to run the load functions again. In practice that wouldn't make any difference, since both applicable load functions are synchronous and don't do any real work.

There's obviously nothing we can do to improve the native case.

In the enhanced case, we could recognise that a redirect had been thrown, and load data for the target page eagerly. In other words instead of /settings/__data.json looking like this...

{
  "type": "redirect",
  "location": "/login"
}

...it could look like this:

{
  "type": "redirect",
  "location": "/login",
  "nodes": [
    { "type": "data", "data": { "user": null } },
    null
  ]
}

That would be a neat optimisation, but there are two caveats:

1. it would add some bytes complexity to the SvelteKit client, though perhaps not an unbearable amount
2. there's no guarantee that the user wants to apply the redirect — they could be returning a custom function in their enhance callback. If they didn't redirect, we'd have loaded that data (and increased the payload) unnecessarily. So we'd probably want to only do this when use:enhance is being used but no custom function was used. Still a win, but more limited in scope

[Rich-Harris]

Yeah, the CSS could definitely be optimised. We're basically following the instructions from https://realworld-docs.netlify.app/docs/specs/frontend-specs/templates — not sure if it would be 'cheating' to optimise it