You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -45,35 +46,64 @@ type PersistedOptions<Type, StorageOptions> = {
45
46
- initial values of signals or stores are not persisted, so they can be safely changed
46
47
- values persisted in asynchronous storage APIs will not overwrite already changed signals or stores
47
48
- setting a persisted signal to undefined or null will remove the item from the storage
48
-
- to use `makePersisted` with other state management APIs, you need some adapter that will project your API to either the output of `createSignal` or `createStore`
49
+
- to use `makePersisted` with other state management APIs, you need some adapter that will project your API to either
50
+
the output of `createSignal` or `createStore`
49
51
50
52
### Using `makePersisted` with resources
51
53
52
-
Instead of wrapping the resource itself, it is far simpler to use the `storage` option of the resource to provide a persisted signal or [deep signal](../resource/#createdeepsignal):
54
+
Instead of wrapping the resource itself, it is far simpler to use the `storage` option of the resource to provide a
55
+
persisted signal or [deep signal](../resource/#createdeepsignal):
If you are using an asynchronous storage to persist the state of a resource, it might receive an update due to being initialized from the storage before or after the fetcher resolved. If the initialization resolves after the fetcher, its result is discarded not to overwrite more current data.
61
+
If you are using an asynchronous storage to persist the state of a resource, it might receive an update due to being
62
+
initialized from the storage before or after the fetcher resolved. If the initialization resolves after the fetcher, its
63
+
result is discarded not to overwrite more current data.
59
64
60
65
### Different storage APIs
61
66
62
-
In the browser, we already have `localStorage`, which persists values for the same hostname indefinitely, and `sessionStorage`, which does the same for the duration of the browser session, but loses persistence after closing the browser.
67
+
#### LocalStorage, SessionStorage
63
68
64
-
As another storage, `cookieStorage` from this package can be used, which is a `localStorage`-like API to set cookies. It will work in the browser and also allows reading cookies on solid-start. Using it in the server without solid-start will not cause errors (unless you are using stackblitz), but instead emit a warning message. You can also supply your own implementations of `cookieStorage._read(key)` and `cookieStorage._write(key, value, options)` if neither of those fit your need.
69
+
In the browser, we already have `localStorage`, which persists values for the same hostname indefinitely,
70
+
and `sessionStorage`, which does the same for the duration of the browser session, but loses persistence after closing
71
+
the browser.
65
72
66
-
If you are not using solid-start or are using stackblitz and want to use cookieStorage on the server, you can supply optional getRequest (either something like useRequest from solid-start or a function that returns the current request) and setCookie options.
73
+
#### CookieStorage
67
74
68
-
There is also [`localForage`](https://localforage.github.io/localForage/), which uses `IndexedDB`, `WebSQL` or `localStorage` to provide an asynchronous Storage API that can ideally store much more than the few Megabytes that are available in most browsers.
75
+
As another storage, `cookieStorage` from this package can be used, which is a `localStorage`-like API to set cookies. It
76
+
will work in the browser and on solid-start, by parsing the `Cookie` and `Set-Cookie` header and altering
77
+
the `Set-Cookie` header. Using it in the server without solid-start will not cause errors (unless
78
+
you are using stackblitz), but instead emit a warning message. You can also supply your own implementations
79
+
of `cookieStorage._read(key, options)` and `cookieStorage._write(key, value, options)` if neither of those fit your
80
+
need.
81
+
82
+
If you are not using solid-start or are using stackblitz and want to use cookieStorage on the server, you can supply
83
+
optional `getRequest` (either something like useRequest from solid-start or a function that returns the current request)
84
+
and `setCookie` options.
85
+
86
+
When you are using vite and solid-start you want to always provide the `useRequest` function from solid start to
87
+
the `getRequest` option, because of a technical limitation of vite.
88
+
89
+
> Please mind that `cookieStorage`**doesn't care** about the path and domain when reading cookies. This might cause issues when using
90
+
> multiple cookies with the same key, but different path or domain.
91
+
92
+
#### IndexedDB, WebSQL
93
+
94
+
There is also [`localForage`](https://localforage.github.io/localForage/), which uses `IndexedDB`, `WebSQL`
95
+
or `localStorage` to provide an asynchronous Storage API that can ideally store much more than the few Megabytes that
96
+
are available in most browsers.
69
97
70
98
---
71
99
72
100
### Deprecated primitives:
73
101
74
-
The previous implementation proved to be confusing and cumbersome for most people who just wanted to persist their signals and stores, so they are now deprecated.
102
+
The previous implementation proved to be confusing and cumbersome for most people who just wanted to persist their
103
+
signals and stores, so they are now deprecated.
75
104
76
-
`createStorage` is meant to wrap any `localStorage`-like API to be as accessible as a [Solid Store](https://www.solidjs.com/docs/latest/api#createstore). The main differences are
105
+
`createStorage` is meant to wrap any `localStorage`-like API to be as accessible as
106
+
a [Solid Store](https://www.solidjs.com/docs/latest/api#createstore). The main differences are
77
107
78
108
- that this store is persisted in whatever API is used,
79
109
- that you can only use the topmost layer of the object and
@@ -83,8 +113,11 @@ The previous implementation proved to be confusing and cumbersome for most peopl
The props object support the following parameters:
94
127
95
128
`api`
96
-
: An array of or a single `localStorage`-like storage API; default will be `localStorage` if it exists; an empty array or no API will not throw an error, but only ever get `null` and not actually persist anything
129
+
: An array of or a single `localStorage`-like storage API; default will be `localStorage` if it exists; an empty array
130
+
or no API will not throw an error, but only ever get `null` and not actually persist anything
97
131
98
132
`prefix`
99
133
: A string that will be prefixed every key inside the API on set and get operations
100
134
101
135
`serializer / deserializer`
102
-
: A set of function to filter the input and output; the `serializer` takes an arbitrary object and returns a string, e.g. `JSON.stringify`, whereas the `deserializer` takes a string and returns the requested object again.
136
+
: A set of function to filter the input and output; the `serializer` takes an arbitrary object and returns a string,
137
+
e.g. `JSON.stringify`, whereas the `deserializer` takes a string and returns the requested object again.
103
138
104
139
`options`
105
-
: For APIs that support options as third argument in the `getItem` and `setItem` method (see helper type `StorageWithOptions<O>`), you can add options they will receive on every operation.
140
+
: For APIs that support options as third argument in the `getItem` and `setItem` method (see helper
141
+
type `StorageWithOptions<O>`), you can add options they will receive on every operation.
106
142
107
143
---
108
144
@@ -118,7 +154,9 @@ createCookieStorage();
118
154
119
155
#### Asynchronous storage APIs
120
156
121
-
In case you have APIs that persist data on the server or via `ServiceWorker` in a [`CookieStore`](https://wicg.github.io/cookie-store/#CookieStore), you can wrap them into an asynchronous storage (`AsyncStorage` or `AsyncStorageWithOptions` API) and use them with `createAsyncStorage`:
157
+
In case you have APIs that persist data on the server or via `ServiceWorker` in
158
+
a [`CookieStore`](https://wicg.github.io/cookie-store/#CookieStore), you can wrap them into an asynchronous
159
+
storage (`AsyncStorage` or `AsyncStorageWithOptions` API) and use them with `createAsyncStorage`:
It works exactly like a synchronous storage, with the exception that you have to `await` every single return value. Once the `CookieStore` API becomes more prevalent, we will integrate support out of the box.
202
+
It works exactly like a synchronous storage, with the exception that you have to `await` every single return value. Once
203
+
the `CookieStore` API becomes more prevalent, we will integrate support out of the box.
160
204
161
205
If you cannot use `document.cookie`, you can overwrite the entry point using the following tuple:
0 commit comments