Zedux has come a long way since its inception as Redux middleware in 2017. v1 officially released in April 2023. Lots of fixes and discussions later, we find ourselves ready to start ramping up for Zedux v2 🎉

The core focus of v2 will be performance. Zedux is already very fast (2-3x faster than Jotai, its main competitor), but we've done lots of profiling and determined that we can increase Zedux's performance by 3-5x.

V2 is also a "stepping stone" version for v3. It will deprecate old APIs and introduce the new APIs that v3 will fully switch to. V2 will have quite a few breaking changes, but hopefully not too many that will affect users. Removing old APIs and really breaking stuff will be v3's job.

The bulk of this work is already done! PR #114 lays the foundation for what the new APIs have to look like to get the performance and build size improvements we want. There is a lot of room for changes though. Community feedback is welcome!

The Gist

Here's what we want to accomplish with v2 from a high level:

Speed Up the Graph

There are two phases to this:

Phase 1

Make Nodes Autonomous. Change Zedux's internal graph algorithm to make nodes handle their own operations. #114 already does this, changing atom instances and selector caches (now called "selector instances") to be valid graph nodes and scheduler jobs. This PR alone speeds up Zedux by ~2.4x.

PR #114 finishes this phase.

Phase 2

Make nodes skip the scheduler whenever possible when propagating state updates. This will allow us to bypass the O(n log n) (super fast) insertion sort algorithm that schedules jobs.

Harmonize APIs

Across Zedux's APIs, some concepts are similar but use different names. Some functions take similar arguments but in slightly different shapes. Some functions could take the same arguments but take wildly different ones now.

These differences are unnecessary. Make them more uniform. For example:

• selector "caches" vs atom "instances".
• select(mySelector, arg1, arg2) vs get(myAtom, [param1, param2])
  • on that note, we use "args" for selectors but "params" for atoms. Why?
• ecosystem.dehydrate(powerfulFilterOptions) vs ecosystem.findAll(stringOrAtomTemplate).

Remove Cruft

Zedux React prod build is 38kb minified. Not bad - significantly smaller than RTK, React Query, RxJS, and lots of other tools that the React world has no problem with. However, we have a lot of barely used APIs that we can offload to plugins if anyone really does need them. We also have lots of code that doesn't minify well - especially classes with properties that are also classes. We can get Zedux well below 38kb minified (~11kb gzipped I believe) and should do so.

Begin the Move to Signals!

Zedux is already technically a signals implementation. However, it really wasn't designed with the same concepts in mind as most signals libraries. It's more patterned after Recoil and Jotai as an "atomic" library. However, Zedux went so far above and beyond either Recoil or Jotai that it arrived in Signals land on accident. That's a good thing!

After some exploration, I've determined that we should be able to create an official signal primitive for Zedux that has all the capabilities of Zedux's powerful store model and that naturally fixes all its problems.

The current plan is for signals to replace stores as the primary state management primitive in Zedux v3 with v2 being a stepping stone in that direction.

The store model is still unique and cool in its own right and will still be usable. But it will likely be moved to a separate package and require its own legacyAtom factory in order to be used alongside native atoms in v3.

Roadmap

See #118 for all planned deprecations, removals, and additions in v2.