Skip to content

Zedux v2 Roadmap #118

Open
Open
@bowheart

Description

@bowheart

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). (Completed by feat!: make signal.get reactive and add signal.getOnce #151)
  • AtomInstance#setState - replaced with AtomInstance#set (a thin wrapper around SignalInstance#set). (Completed by feat!: improve findAll, ions, and clean up types, properties, and deprecations #212)
  • AtomInstance#setStateDeep - replaced with AtomInstance#mutate(a thin wrapper around SignalInstance#mutate). (UPDATE: Not deprecating. Store atoms can't use .mutate. Switch to signals-based atoms for that). This has problems with undefined in TS (see TypeScript: Store values should probably all infer as optional #95). The Store class will retain its setStateDeep method but changed to make undefined values a no op (UPDATE: not changing this. Prefer the new mutate APIs). Both AtomInstance and Signal 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.
  • The getInstance atom getter - replaced with getNode.
  • The select atom getter - replaced with get. (Completed by feat!: replace atom getters with ecosystem function properties #169)
  • useAtomSelector - replaced with useAtomValue. (Completed by feat!: replace atom getters with ecosystem function properties #169)
  • injectAtomSelector - replaced with injectAtomValue or the get atom getter. (Completed by feat!: replace atom getters with ecosystem function properties #169)
  • injectStore - replaced with injectSignal (this deprecation will almost definitely not be part of v2 initial release, but a minor version after). UPDATE: Not deprecating. It is still supported in the new @zedux/stores package. Though it is considered legacy and it's recommended to migrate to the new signals-based atoms and injectSignal.
  • The Store class and all helpers associated with it - createStore, getMetaData, removeAllMeta, removeMeta, all store-specific zeduxTypes (see New Signal Primitive #115), actionFactory, createReducer, and all type helpers for stores, actions, reducers, and subscribers. UPDATE: Not deprecating. These are still supported in the new @zedux/stores package. Though they are considered legacy and it's recommended to migrate to the new signals-based atoms.
  • All Atom*Type type utils - replaced with *Of (e.g. AtomStateType<myAtom> -> StateOf<myAtom>). UPDATE: Not deprecating. These are still supported in the new @zedux/stores package. Though they are considered legacy and it's recommended to update to the new signals-based atoms and *Of types.
  • The action property on evaluation reasons.

Planned Removals

Planned Features

Stuff We're Still Figuring Out

  • Will phase 2 of the graph perf improvements be part of Zedux v2 or pushed back to v3? UPDATE: I've micro optimized Zedux's existing scheduler algorithm a lot for v2. I'm still planning on doing phase 2, but definitely not for v2.
  • 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 feat!: make instances valid graph nodes and jobs #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. We will leave the v1 docs alone and partition the docs site by version
  • Can the new signal primitive be made so it can use the TC39 proposal internally when (if) it's finalized? Not worth worrying about now. Zedux needs more control over events and update tracing than the proposal is proposing. Our signals are too powerful. But even so, we might be able to utilize the signal primitive for something, but that's a long way off.
  • The new type (introduced in feat!: make instances valid graph nodes and jobs #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? (Completed by feat(atoms)!: support @atom node type filter in findAll and dehydrate #204)
  • 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. This is officially the plan 🎉 . (Completed by feat!: replace atom getters with ecosystem function properties #169)
  • The timeline! When will Zedux v2 be available? UPDATE: No fixed date yet, but I'm aiming to be stable and battle-tested by March 20, 2025, though perhaps not fully documented yet.

Metadata

Metadata

Assignees

No one assigned

    Labels

    planningRoadmaps and discussions about the future

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions