Releases: yumauri/effector-storage
v7.1.0
🐛 Fixed issue with infinite loop on parallel execution (PR #174)
This fix changes behavior a bit, but it is very unlikely, that this will affect your application — it changes a moment, when several stores, persisted with the same key, are getting synchronized. Previously it happend immediately after any store changes its value. Now it will happen after actual storage change.
v7.0.0
☄️ Support for Effector v23
This release allows usage of effector-storage
with effector
v23, but is not yet introducing advanced types support.
Full-featured support of effector
v23 will come later.
⬆️ Adjusted update
function signature and behaviour
🐛 Fixed types declarations for package (publint)
BREAKING:
❗ Removed deprecated adapters for React Native AsyncStorage and EncryptedStorage adapters (use @effector-storage/react-native-async-storage and @effector-storage/react-native-encrypted-storage instead)
💥 Minimal supported effector
version bumped to 22.4.0
💥 Drop support for Nodejs 16
Note for SSR and scope
users
Prior to version 23 effector took current value of a store in the scope on a first read. Due to this behavior it was possible to completely ignore scopes with effector-storage
as long as you do not need asynchronous updates from the storage.
// effector 22 compatible code
const $store = createStore(0)
persist({ store: $store }) // restores 42
const scope = fork()
const x = scope.getState($store) // x === 42
But in version 23 this behavior was changed due to not obviousness and as leading to some issues (see issue #535 and PR #909). So now state of a store in the scope will always be initial on a first read.
// in effector 23
const $store = createStore(0)
persist({ store: $store }) // restores 42
const scope = fork()
const x = scope.getState($store) // x === 0 !!!
Now, in order to use effector-storage
with scopes in effector 23, you should always use pickup
event! It aligns with recommendation to use explicit start of an application. It will also correctly handle asynchronous updates from the storage, binding those updates to correct scope.
If you have many persist
calls across your entire application, you could take advantage of createPersist
factory:
// import this `persist` everywhere instead
export const persist = createPersist({
pickup: appStarted
})
v6.1.1
🐛 Fix TypeScript types in exports map (https://publint.dev/effector-storage)
v6.1.0
v6.0.1
v6.0.0
🤝 Contracts support (pr #52)
➕ Adapters now are exported separately from persist
(pr #36, pr #37)
⬆️ New timeout
option for storage adapters to throttle updates (pr #51, issue #4)
⬆️ New timeout
option for query adapter to batch updates (pr #50, issue #23)
🐛 Add sync = 'force'
mode for storage adapters (pr #49, issue #32)
➕ New experimental log
adapter (pr #44, ~ issue #35)
➕ New adapter context feature (pr #46, ~ issue #33)
➕ Adapter factories support (pr #47, ~ issue #38)
➕ Few adapter utilities:
async
utility function (pr #42, issue #38)either
utility function (pr #41, issue #35)farcached
utility function (pr #48)
BREAKING:
❗️ /local and /session adapters now use default value from store (pr #39, issue #34)
❗️ Separate terms "supported" and "available" for adapters (pr #41)
💥 Drop support for Effector 21 and Nodejs 14 (pr #45)
✍️ Read full post about new release —
https://dev.to/effector/effector-storage-v6-34md
v5.0.1
v5.0.0
v4.5.0
➕ Added new React Native AsyncStorage adapter (enhancement #30), thanks to @rushelex
➕ Added new React Native EncryptedStorage adapter (enhancement #30), thanks to @rushelex
🐛 Fix duplicating code in build, if you use different persist
functions in your project
v4.4.0
➕ Added new createPersist
factory (enhancement #28), allowing to specify some adapter options, for example, keyPrefix
🐛 Fix #26, now /local and /session persist
s will not conflict on server side
🐛 Fix #25, forbidden localStorage
/sessionStorage
will not throw error
ℹ️ sync
option flag is not deprecated anymore
.thru
method in effector version 22, functional helpers (/fp) become obsolete, so, they are deprecated as well