Closed Rich-Harris closed 1 year ago
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) |
Realworld has been a valuable reference (JWT auth etc.) and I frequently refer others to it. Commenting out of appreciation 🙌
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?
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:
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
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 soAdmittedly 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:
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 scopeYeah, 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
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