Zedux v2 is on the horizon! Here's what we're planning on adding, deprecating, and removing plus some stuff we're still figuring out.
Planned Deprecations
[ ] AtomInstance#getState - replaced with GraphNode#get (which AtomInstance inherits).
[ ] AtomInstance#setState - replaced with AtomInstance#set (a thin wrapper around SignalInstance#set).
[ ] AtomInstance#setStateDeep - replaced with AtomInstance#mutate(a thin wrapper around SignalInstance#mutate).
[ ] The getInstance atom getter - replaced with getNode.
[ ] The select atom getter - replaced with get.
[ ] useAtomSelector - replaced with useAtomValue.
[ ] injectAtomSelector - replaced with injectAtomValue or the get atom getter.
[ ] AtomInstance#setStateDeep. This has problems with undefined in TS (see #95). The Store class will retain its setStateDeep method but changed to make undefined values a no op. Both AtomInstance and SignalInstance will instead have mutate methods that finally introduce immer-style proxies natively to Zedux and fix the undefined problem naturally since they won't deal with any RecursivePartial types.
[ ] injectStore - replaced with injectSignal (this deprecation will almost definitely not be part of v2 initial release, but a minor version after).
[ ] The Store class and all helpers associated with it - createStore, getMetaData, removeAllMeta, removeMeta, all store-specific zeduxTypes (see #115), actionFactory, createReducer, and all type helpers for stores, actions, reducers, and subscribers.
[ ] All Atom*Type type utils - replaced with *Of (e.g. AtomStateType<myAtom> -> StateOf<myAtom>).
[ ] The action property on evaluation reasons.
Planned Removals
[x] The Selectors class (see #114).
[x] The Graph class (see #114).
[x] The EvaluationStack class (see #114).
[x] The AtomInstanceBase class (see #114).
[x] The SelectorCache class (see #114) - replaced with SelectorInstance.
[x] AtomInstance#addDependent and Selectors#addDependent are replaced with GraphNode#on (see #114).
[ ] The IdGenerator class - replaced with methods on Ecosystem.
[ ] The ZeduxPlugin class and its actions - plugins are being completely reworked (see below).
[ ] internalStore and getEcosystem - Zedux will no longer store ecosystems in its module-level state. This keeps it pure(r) and prevents GC surprises - if an ecosystem with no callbacks registered with the JS runtime goes completely out of scope, it and all its atoms should be able to be cleaned up.
[ ] The sourceType property on evaluation reasons.
[ ] Ecosystem#registerPlugin - replaced with Ecosystem#on.
[ ] Ecosystem#unregisterPlugin - replaced with calling the cleanup function returned from Ecosystem#on.
[ ] injectInvalidate. This is already deprecated, replaced by injectSelf().invalidate. V2 removes it.
[ ] manualHydration atom config option - Zedux will instead auto-detect any usages of the hydrate option in injectSignal.
[ ] The AtomSelectorOrConfig type - replaced with SelectorTemplate.
[ ] The AtomTemplateBase class - renamed to NodeTemplate. ._createInstance renamed to .new and .getInstanceId renamed to .hash.
[ ] The flags atom config option - renamed to tags. This will affect the options passed to Ecosystem#dehydrate (and now Ecosystem#findAll) - excludeFlags renamed to excludeTags and includeFlags renamed to includeTags.
[ ] The store property returned from getInternals - no direct replacement. Ecosystems will no longer be stored internally in Zedux module-level state. The @@global ecosystem will be returned from createEcosystem({ id: '@@global' })
[ ] getEcosystem - removed with no replacement. For multi-window setups that leverage getInternals/setInternals, share your ecosystem reference across windows yourself rather than using getEcosystem('my-id') after calling setInternals in the child window. This should be about the same amount of code with less magic.
[ ] wipe (the top-level exported function) - removed with no replacement. There's no internal store to clear.
[x] The hierarchy config from stores (see #94)
[ ] The synchronous option of injectEffect. All effects will now run as soon as the atom's state factory returns. This solves the problem that synchronous was trying to solve - where manual subscriptions aren't registered before the atom can be used - and also solves the problems with synchronous itself - where its atom getter calls register graph edges.
[ ] Ecosystem#_incrementRefCount, Ecosystem#_decrementRefCount, Ecosystem#_refCount, and the destroyOnUnmount ecosystem config option. EcosystemProvider will destroy on unmount instead. And custom ecosystems should handle ecosystem destruction manually (or just not, that's fine for most apps).
[ ] Ecosystem#wipe. This is just being hidden. It's always been recommended to use Ecosystem#reset or Ecosystem#destroy instead. Now we won't have to recommend it.
[ ] Ecosystem#atomDefaults. This is unnecessary bloat. Users can create atom factories themselves for defining standardized atom types. That gives full flexibility, is already documented, and has no real disadvantages to this ecosystem config option.
Planned Features
[ ] The new Signal primitive (see #115)
[ ] New plugin system (see #119)
[ ] api.set to set all properties of an AtomAPI at once.
[ ] Remove the string key requirement of atom. Keys will be auto-generated if not provided (but it's strongly recommended to pass one or use a build tool plugin to generate them for you).
[ ] Events (see #115). In addition to the signal built-in events, atoms will have .on('invalidate', cb). If we remove lifecycles from signals, atoms will also have .on('cycle', cb). Ecosystems will also have "plugin events" (see #119)
[ ] optimize option for Ecosystem#batch that will disable evaluation reason tracking for all updates resulting from any calls in the .batch callback.
[ ] Automatic dependency tracking for injectEffect, injectPromise, injectCallback, and injectMemo - omit the deps array and Zedux will make the callback a reactive context similar to signals libs.
[ ] Improved parameters to Ecosystem#findAll. Besides those already in #114, a .findAll(callback) overload for full control. That overload will apply to Ecosystem#dehydrate as well.
Stuff We're Still Figuring Out
[ ] Will phase 2 of the graph perf improvements be part of Zedux v2 or pushed back to v3?
[x] ~Is the lifecycle status property of graph nodes used enough to merit it getting a status getter on top of the obfuscated single-letter lifecycleStatus property added by #114? We've never used it TMK for any purpose, but it's featured prominently in the docs. Maybe it just shouldn't be?~ We will add a status getter because we're further obfuscating lifecycleStatus by making its value a number. The status getter will translate the number to a user-friendly string.
[ ] Should we cut a v2 of the docs and leave v1 alone? Or should we update the existing doc pages.
[ ] Can the new signal primitive be made so it can use the TC39 proposal internally when (if) it's finalized?
[ ] The new type (introduced in #114) for arguments passed to ecosystem.dehydrate and ecosystem.findAll doesn't have a way to specify that only a certain type of node should be returned - atoms or selectors (or signals soon) or a custom node type. What would this argument look like?
[ ] Instead of the new ecosystem.live atom getters, should we make the ecosystem's own atom getters reactive by default? We would then add getOnce and getNodeOnce methods which would have the current behavior of get and getNode respectively. This would get rid of the concept of atom getters and make the ecosystem all you need to know. It would also be able to have parity with signals - signal.get and signal.getOnce. It would also replace injectAtomGetters with injectEcosystem for better parity with Zedux's hooks.
[ ] The timeline! When will Zedux v2 be available?
Zedux v2 is on the horizon! Here's what we're planning on adding, deprecating, and removing plus some stuff we're still figuring out.
Planned Deprecations
AtomInstance#getState- replaced withGraphNode#get(whichAtomInstanceinherits).AtomInstance#setState- replaced withAtomInstance#set(a thin wrapper aroundSignalInstance#set).AtomInstance#setStateDeep- replaced withAtomInstance#mutate(a thin wrapper aroundSignalInstance#mutate).getInstanceatom getter - replaced withgetNode.selectatom getter - replaced withget.useAtomSelector- replaced withuseAtomValue.injectAtomSelector- replaced withinjectAtomValueor thegetatom getter.AtomInstance#setStateDeep. This has problems withundefinedin TS (see #95). TheStoreclass will retain itssetStateDeepmethod but changed to make undefined values a no op. BothAtomInstanceandSignalInstancewill instead havemutatemethods that finally introduce immer-style proxies natively to Zedux and fix theundefinedproblem naturally since they won't deal with anyRecursivePartialtypes.injectStore- replaced withinjectSignal(this deprecation will almost definitely not be part of v2 initial release, but a minor version after).Storeclass and all helpers associated with it -createStore,getMetaData,removeAllMeta,removeMeta, all store-specificzeduxTypes(see #115),actionFactory,createReducer, and all type helpers for stores, actions, reducers, and subscribers.Atom*Typetype utils - replaced with*Of(e.g.AtomStateType<myAtom>->StateOf<myAtom>).actionproperty on evaluation reasons.Planned Removals
Selectorsclass (see #114).Graphclass (see #114).EvaluationStackclass (see #114).AtomInstanceBaseclass (see #114).SelectorCacheclass (see #114) - replaced withSelectorInstance.AtomInstance#addDependentandSelectors#addDependentare replaced withGraphNode#on(see #114).IdGeneratorclass - replaced with methods onEcosystem.ZeduxPluginclass and its actions - plugins are being completely reworked (see below).internalStoreandgetEcosystem- Zedux will no longer store ecosystems in its module-level state. This keeps it pure(r) and prevents GC surprises - if an ecosystem with no callbacks registered with the JS runtime goes completely out of scope, it and all its atoms should be able to be cleaned up.sourceTypeproperty on evaluation reasons.Ecosystem#registerPlugin- replaced withEcosystem#on.Ecosystem#unregisterPlugin- replaced with calling the cleanup function returned fromEcosystem#on.injectInvalidate. This is already deprecated, replaced byinjectSelf().invalidate. V2 removes it.manualHydrationatom config option - Zedux will instead auto-detect any usages of thehydrateoption ininjectSignal.AtomSelectorOrConfigtype - replaced withSelectorTemplate.AtomTemplateBaseclass - renamed toNodeTemplate.._createInstancerenamed to.newand.getInstanceIdrenamed to.hash.flagsatom config option - renamed totags. This will affect the options passed toEcosystem#dehydrate(and nowEcosystem#findAll) -excludeFlagsrenamed toexcludeTagsandincludeFlagsrenamed toincludeTags.storeproperty returned fromgetInternals- no direct replacement. Ecosystems will no longer be stored internally in Zedux module-level state. The@@globalecosystem will be returned fromcreateEcosystem({ id: '@@global' })getEcosystem- removed with no replacement. For multi-window setups that leveragegetInternals/setInternals, share your ecosystem reference across windows yourself rather than usinggetEcosystem('my-id')after callingsetInternalsin the child window. This should be about the same amount of code with less magic.wipe(the top-level exported function) - removed with no replacement. There's no internal store to clear.synchronousoption ofinjectEffect. All effects will now run as soon as the atom's state factory returns. This solves the problem thatsynchronouswas trying to solve - where manual subscriptions aren't registered before the atom can be used - and also solves the problems withsynchronousitself - where its atom getter calls register graph edges.Ecosystem#_incrementRefCount,Ecosystem#_decrementRefCount,Ecosystem#_refCount, and thedestroyOnUnmountecosystem config option.EcosystemProviderwill destroy on unmount instead. And custom ecosystems should handle ecosystem destruction manually (or just not, that's fine for most apps).Ecosystem#wipe. This is just being hidden. It's always been recommended to useEcosystem#resetorEcosystem#destroyinstead. Now we won't have to recommend it.Ecosystem#atomDefaults. This is unnecessary bloat. Users can create atom factories themselves for defining standardized atom types. That gives full flexibility, is already documented, and has no real disadvantages to this ecosystem config option.Planned Features
api.setto set all properties of an AtomAPI at once.atom. Keys will be auto-generated if not provided (but it's strongly recommended to pass one or use a build tool plugin to generate them for you)..on('invalidate', cb). If we remove lifecycles from signals, atoms will also have.on('cycle', cb). Ecosystems will also have "plugin events" (see #119)optimizeoption forEcosystem#batchthat will disable evaluation reason tracking for all updates resulting from any calls in the.batchcallback.injectEffect,injectPromise,injectCallback, andinjectMemo- omit the deps array and Zedux will make the callback a reactive context similar to signals libs.Ecosystem#findAll. Besides those already in #114, a.findAll(callback)overload for full control. That overload will apply toEcosystem#dehydrateas well.Stuff We're Still Figuring Out
statusproperty of graph nodes used enough to merit it getting astatusgetter on top of the obfuscated single-letterlifecycleStatus property added by #114? We've never used it TMK for any purpose, but it's featured prominently in the docs. Maybe it just shouldn't be?~ We will add astatusgetter because we're further obfuscatinglifecycleStatus by making its value a number. Thestatusgetter will translate the number to a user-friendly string.v2of the docs and leave v1 alone? Or should we update the existing doc pages.ecosystem.dehydrateandecosystem.findAlldoesn't have a way to specify that only a certain type of node should be returned - atoms or selectors (or signals soon) or a custom node type. What would this argument look like?ecosystem.liveatom getters, should we make the ecosystem's own atom getters reactive by default? We would then addgetOnceandgetNodeOncemethods which would have the current behavior ofgetandgetNoderespectively. This would get rid of the concept of atom getters and make the ecosystem all you need to know. It would also be able to have parity with signals -signal.getandsignal.getOnce. It would also replaceinjectAtomGetterswithinjectEcosystemfor better parity with Zedux's hooks.