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 === 42But 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:
asyncutility function (pr #42, issue #38)eitherutility function (pr #41, issue #35)farcachedutility 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 persists 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