docs: state management #8547
docs: state management #8547
Conversation
- docs about state management - more helpful error message when trying to run a SvelteKit store on the server closes #8524
|
|
|
||
| - if you need to access the user state only inside `load` functions, use `locals` in server `load` functions | ||
| - if you need to persist the user state across reloads, but only need to access it inside `load` functions, use `cookies` in server `load` functions | ||
| - if you need to access and update the state inside components, use Svelte's [context feature](https://svelte.dev/docs#run-time-svelte-setcontext). That way, the state is scoped to components, which means they are not shared across different requests on the server. The drawback is that you can only set and subscribe to the store at component initialization. SvelteKit's stores from `$app/stores` for example are setup like this (which is why you may have encountered a related error message) |
There was a problem hiding this comment.
Could it be useful to have an example of this here ?
I am not sure myself what is meant with this, but are you referring to returning data from load, placing it in a store and then use setContext in the page to make it available ?
There was a problem hiding this comment.
yes this would be the way - and I agree this probably needs a code example
|
Agree that we should clarify why you can't subscribe to app stores outside component initialization (though the improved error messages are the real win here), but I do think we should be careful about how far into the weeds we go. For example the 'types of state' section feels a bit intimidating ("I need to understand all these different kinds of things? I just wanted to load some data") and yet is arguably incomplete (it doesn't mention stores, or how API/backend relates to page data). There's a cost to adding documentation — it makes it harder for a newcomer to RTFM — and so we need to be sure that we're solving a real problem. #8524 is painfully vague about our docs' shortcomings, to the point that I'm not sure any PR could claim to close it. |
|
I agree the docs in this PR are too broad. It seems like the thing that people trip over a lot is how to use stores with SSR. I think we could cover that much more concisely. Perhaps we could document the pattern Rich recommended in #7105 (comment) in the load docs or something |
|
I'm good with removing the broader section, it was intended as a start to a more full-fledged docs page - imagine about twice the content there is now in the end. But I don't have a good vision of how it all could look like. We already have a short section on stores and SSR in the load docs, which noone reads because noone thinks that it's hidden in there. I think a general "State Management" page makes sense since it's a widely used term so people are far more likely to click on that to see how things are done "the SvelteKit way". #8614 is a prime example that we need a dedicated section for this. |
|
Perhaps the docs should simple focus on the "API" instead. |
|
I update the doc to remove that "types of state" prelude and added a section on form interaction instead. It has reminiscents of a trouble shooting or "do it this way instead" which I think is a good addition. |
|
I was debating this myself, there's duplication to the form actions section, but if you browse the docs just from looking at the titles, you may end up here searching for the best way to do this. It's a little like the error docs which also contain references to various other places in the docs. |
Co-authored-by: Ben McCann <[email protected]>
Co-authored-by: Harry Allen <[email protected]>
| ## Managing forms | ||
|
|
||
| When coming from a pure Svelte or JavaScript background, you might be used to handling all form interactions through JavaScript. This works well when JavaScript is available but results in unresponsive UI when it isn't (which may be [more often than you think](https://kryogenix.org/code/browser/everyonehasjs.html)). If this is a concern to you, leverage SvelteKit's [form actions](form-actions) instead. |
There was a problem hiding this comment.
Does this belong here? It's well covered by the form section, and I don't think of mutations as part of state management
| ## Managing forms | |
| When coming from a pure Svelte or JavaScript background, you might be used to handling all form interactions through JavaScript. This works well when JavaScript is available but results in unresponsive UI when it isn't (which may be [more often than you think](https://kryogenix.org/code/browser/everyonehasjs.html)). If this is a concern to you, leverage SvelteKit's [form actions](form-actions) instead. |
There was a problem hiding this comment.
Mutating state is an integral part of managing state to me. If all state was just readonly, managing it would be a lot easier 😄
* updates * fix broken link * fix file annotations * tweak * Update documentation/docs/20-core-concepts/50-state-management.md * Update documentation/docs/20-core-concepts/50-state-management.md Co-authored-by: Rich Harris <[email protected]> * Update documentation/docs/20-core-concepts/50-state-management.md --------- Co-authored-by: Simon H <[email protected]>
closes #8524
closes #8302
related to #8614
The docs are WIP, I'd like to add more stuff to it.
Loading Datain there?Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.