zedux
zedux copied to clipboard
Zedux v2 Roadmap
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
(whichAtomInstance
inherits). - [ ]
AtomInstance#setState
- replaced withAtomInstance#set
(a thin wrapper aroundSignalInstance#set
). - [ ]
AtomInstance#setStateDeep
- replaced withAtomInstance#mutate
(a thin wrapper aroundSignalInstance#mutate
). - [ ] The
getInstance
atom getter - replaced withgetNode
. - [ ] The
select
atom getter - replaced withget
. - [ ]
useAtomSelector
- replaced withuseAtomValue
. - [ ]
injectAtomSelector
- replaced withinjectAtomValue
or theget
atom getter. - [ ]
AtomInstance#setStateDeep
. This has problems withundefined
in TS (see #95). TheStore
class will retain itssetStateDeep
method but changed to make undefined values a no op. BothAtomInstance
andSignalInstance
will instead havemutate
methods that finally introduce immer-style proxies natively to Zedux and fix theundefined
problem naturally since they won't deal with anyRecursivePartial
types. - [ ]
injectStore
- replaced withinjectSignal
(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-specificzeduxTypes
(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 withSelectorInstance
. - [x]
AtomInstance#addDependent
andSelectors#addDependent
are replaced withGraphNode#on
(see #114). - [ ] The
IdGenerator
class - replaced with methods onEcosystem
. - [ ] The
ZeduxPlugin
class and its actions - plugins are being completely reworked (see below). - [ ]
internalStore
andgetEcosystem
- 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 withEcosystem#on
. - [ ]
Ecosystem#unregisterPlugin
- replaced with calling the cleanup function returned fromEcosystem#on
. - [ ]
injectInvalidate
. This is already deprecated, replaced byinjectSelf().invalidate
. V2 removes it. - [ ]
manualHydration
atom config option - Zedux will instead auto-detect any usages of thehydrate
option ininjectSignal
. - [ ] The
AtomSelectorOrConfig
type - replaced withSelectorTemplate
. - [ ] The
AtomTemplateBase
class - renamed toNodeTemplate
.._createInstance
renamed to.new
and.getInstanceId
renamed to.hash
. - [ ] The
flags
atom config option - renamed totags
. This will affect the options passed toEcosystem#dehydrate
(and nowEcosystem#findAll
) -excludeFlags
renamed toexcludeTags
andincludeFlags
renamed toincludeTags
. - [ ] The
store
property returned fromgetInternals
- no direct replacement. Ecosystems will no longer be stored internally in Zedux module-level state. The@@global
ecosystem 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 callingsetInternals
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. - [ ] The hierarchy config from stores (see #94)
- [ ] The
synchronous
option ofinjectEffect
. All effects will now run as soon as the atom's state factory returns. This solves the problem thatsynchronous
was trying to solve - where manual subscriptions aren't registered before the atom can be used - and also solves the problems withsynchronous
itself - where its atom getter calls register graph edges. - [ ]
Ecosystem#_incrementRefCount
,Ecosystem#_decrementRefCount
,Ecosystem#_refCount
, and thedestroyOnUnmount
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 useEcosystem#reset
orEcosystem#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 forEcosystem#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
, andinjectMemo
- 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 toEcosystem#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 astatus
getter on top of the obfuscated single-letterl
ifecycleStatus 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 astatus
getter because we're further obfuscatingl
ifecycleStatus by making its value a number. Thestatus
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
andecosystem.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 addgetOnce
andgetNodeOnce
methods which would have the current behavior ofget
andgetNode
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
andsignal.getOnce
. It would also replaceinjectAtomGetters
withinjectEcosystem
for better parity with Zedux's hooks. - [ ] The timeline! When will Zedux v2 be available?