Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zedux v2 Roadmap #118

Open
51 of 53 tasks
bowheart opened this issue Sep 10, 2024 · 1 comment
Open
51 of 53 tasks

Zedux v2 Roadmap #118

bowheart opened this issue Sep 10, 2024 · 1 comment
Labels
planning Roadmaps and discussions about the future
Milestone

Comments

@bowheart
Copy link
Collaborator

bowheart commented Sep 10, 2024

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.
@bowheart bowheart added this to the Zedux v2 milestone Sep 10, 2024
@bowheart bowheart added the planning Roadmaps and discussions about the future label Sep 11, 2024
@bowheart bowheart mentioned this issue Feb 11, 2025
@bowheart
Copy link
Collaborator Author

The first release candidate has been published! https://github.com/Omnistac/zedux/releases/tag/v2.0.0-rc.0

Zedux v2 is now considered usable and stable, at least as far as all public, non-obfuscated APIs go. There may still be some "technically breaking" changes for internal APIs, but nothing normal users should need to know about.

There may be more features and bug fixes before v2.0.0 lands. That is the purpose of release candidates after all. And, of course, there's lots to document.

The v2 migration guide can be considered a quick start for Zedux v2 for now.

TL;DR: If you don't mind the currently-sparse documentation, feel free to use v2!

pnpm i @zedux/react@next

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
planning Roadmaps and discussions about the future
Projects
None yet
Development

No branches or pull requests

1 participant