archive-gh-me/zustand
1
0
Fork 0
mirror of https://github.com/pmndrs/zustand.git synced 2025-12-08 19:45:52 +00:00
Code Issues Projects Releases Wiki Activity

Persisting store doc href hash fixes and tweaks (#1398)

Browse Source 
* chore(docs): Fix casing in Persist middleware docs

* docs: Remove unhelpful 'see below' and make other more helpful

* docs: Remove link incompatible between GH & Docs site.
This commit is contained in:
Will McBride 2022-11-03 06:58:59 -06:00 committed by GitHub
parent c2248fd56a
commit d3596a6a73
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
docs/integrations/persisting-store-data.md
View File

@ -6,7 +6,7 @@ nav: 17
The persist middleware enables you to store your Zustand state in a storage (e.g. `localStorage`, `AsyncStorage`, `IndexedDB`, etc...) thus persisting it's data.
Note that this middleware does support both synchronous storages (e.g. `localStorage`) and asynchronous storages (e.g. `AsyncStorage`), but using an asynchronous storage does come with a cost.
See [Hydration and asynchronous storages](#Hydration-and-asynchronous-storages) for more details.
See [Hydration and asynchronous storages](#hydration-and-asynchronous-storages) for more details.
Quick example:
@ -28,8 +28,6 @@ export const useFishStore = create(
)
```
See [Options](#Options) for more details.
## Options
### `name`
@ -206,8 +204,7 @@ export const useBoundStore = create(
If you want to introduce a breaking change in your storage (e.g. renaming a field), you can specify a new version number.
By default, if the version in the storage does not match the version in the code, the stored value won't be used.
See the `migrate` option below for more details about handling breaking changes.
You can use the `migrate` option to handle breaking changes in order to persist previously stored data.
### `migrate`
@ -412,7 +409,7 @@ Why does it matter?
Asynchronous hydration can cause some unexpected behaviors.
For instance, if you use Zustand in a React app, the store will _not_ be hydrated at the initial render. In cases where you app depends on the persisted value at page load, you might want to wait until the store has been hydrated before showing anything (e.g. your app might think the user is not logged in because it's the default, while in reality the store has not been hydrated yet).
If your app does depends on the persisted state at page load, see [How can I check if my store has been hydrated?](#how-can-I-check-if-my-store-has-been-hydrated) in the Q/A.
If your app does depends on the persisted state at page load, see **_How can I check if my store has been hydrated?_** in the Q/A section.
## Q/A