v2 and long term staying power

[marbemac]

Hi @bowheart - I'm evaluating state managers for a new project, and Zedux looks promising! If you have a moment, just a few questions:

1. Do you have a sense re how painful the v1 -> v2 migration will be?
2. Looks like some nice progress was being made on v2 September (all the issues and planning) through mid October (the two alphas). The v2 roadmap issue looks great, but also a lot of work. I don't mean this in a negative way at all, but as the key man here, how are you feeling about the project? Is this something you're excited to maintain long term?
3. Related to 2 - the whole single maintainer thing.. the last state lib we used, overmindjs, was abandoned after the maintainer decided to move on (power to him!), so I'd be remiss when evaluating if I didn't at least ask about your thoughts on the long term viability of this project.

I know 2 and 3 are kind of debbie downer questions and I don't want them to overshadow my excitement for the project - I appreciate the work you've put into Zedux and the great docs!

[bowheart]

Hey @marbemac thanks for asking.

Do you have a sense re how painful the v1 -> v2 migration will be?

This is the main thing slowing up the v2 progress. We have lots of breaking changes planned for v2 but a big codebase that's committed to using v1 APIs that we're not planning on migrating. So I've been putting a lot of work into making sure all Zedux APIs can handle custom atoms, fully typed. I'll still maintain the old APIs (though without plans for ever adding new features) under a new @zedux/stores package as if they were an addon. I'm planning on the migration being generally as simple as:

- import { api, atom, injectStore } from '@zedux/react'
+ import { api, atom, injectStore } from '@zedux/stores'

I'll update the v2 issue with more details.

The v2 roadmap issue looks great, but also a lot of work

It is quite a bit of work. I would say it's about half done though. All the hardest parts are done, including the new signals implementation. That said, I may consider delaying some features until v3. Not that we need that, but if there's demand for getting v2 out faster, I'm open to considering it.

how are you feeling about the project? Is this something you're excited to maintain long term?

Hah, I love Zedux. I genuinely use it for everything and can't go back to anything else. I have no plans to ever stop maintaining it.

But more importantly, the code is actually owned by the company I work for. They pay me to maintain it and will still maintain it whether I'm here or not. Which segues into:

the last state lib we used, overmindjs, was abandoned after the maintainer decided to move on (power to him!), so I'd be remiss when evaluating if I didn't at least ask about your thoughts on the long term viability of this project.

(I didn't know overmind was abandoned. That was actually a good lib) Zedux isn't going anywhere. It would be almost like Meta abandoning React (not Recoil, they did abandon that lol). We spent lots of time analyzing Recoil, Jotai, and React Query before we committed to making Zedux due to no other tool being fast and powerful enough for our data-intensive apps. We've built lots of stuff on it now with plans for lots more.

the whole single maintainer thing

I'm actually not the only maintainer! There are about 10 of us technically. I'm just the one that started it and haven't needed help yet with the code. At least 3 of them have spent lots of time giving feedback and debugging. Some of the other maintainers actually know more about practical Zedux usage than I do. I should get them to answer questions sometimes.

In short, I would say Zedux's long-term staying power rivals everything in its category except maybe Redux and React Query.

[marbemac]

Thanks for the thoughtful response, I really appreciate it!

This is the main thing slowing up the v2 progress. We have lots of breaking changes planned for v2 but a big codebase that's committed to using v1 APIs that we're not planning on migrating. So I've been putting a lot of work..

Speaking with absolutely no knowledge of the scope of the changes... but is investing in a solid codemod an option? Vs trying to wrangle a bunch of complex typings etc for backward compat (and then maintain forever moving forward).

All the hardest parts are done, including the new signals implementation.

Neat! Is the implementation inspired by anything in the ecosystem (e.g. legend state, etc)?

but if there's demand for getting v2 out faster, I'm open to considering it.

Can't speak for others, but not on my end - I'm not familiar enough with Zedux yet to even understand what most of the v2 roadmap means 😅.

I didn't know overmind was abandoned

Yeah Christian just got burned out and had to step away, which I totally understand and can respect.

Sounds like the company backing Zedux wants to remain anonymous, but can I ask approximately how large and how old it is?

---

Thanks again, your response has made me more excited to give Zedux a try - I'm digging in today.

[marbemac]

Btw Christian is working on something new in the state management space - it much smaller in scope than Zedux, but seems to have some interesting concepts, some of which remind me of bits of Zedux. Their "stores" look like a simplified version of Zedux "api". And they have their own signals implementation. Sharing in case you haven't seen it yet and there are any ideas in there for ya'll to take inspiration from as you work on v2 / v3 -> https://impact-react.dev/learn.

[bowheart]

is investing in a solid codemod an option?

A codemod is maybe possible. But it would be hard enough, I can't see it being worth it (for our codebase anyway, always open to hear other viewpoints). The paradigms of stores and signals are so different.

I'm not planning on thinking about that right now, but maybe if we ever do decide to retire stores. There's nothing broken with stores. They work and the composable model is pretty cool, we mostly want to move to signals because stores clash with the atomic paradigm.

Is the implementation inspired by anything in the ecosystem (e.g. legend state, etc)?

I would say S.js and by extension Solid are the main signals implementations I'm familiar with. I believe the decision to name the methods set and get did come from Legend State.

But no, in general Zedux's signals will be pretty different from anything else - we needed signals to also be powerful event emitters, have opt-in immer-style proxies that translate mutations into transaction objects e.g. for use with ag-grid's transaction model, and be reverse-mappable.

We're not planning on introducing any APIs that do anything "non-React-y" like signals libs often do to give components fine-grained reactivity. Though it's possible to make an addon for that.

Sounds like the company backing Zedux wants to remain anonymous, but can I ask approximately how large and how old it is?

They've only vaguely instructed us not to go about associating the company with stuff we publish. It really isn't a huge secret. The company's about 10 years old and has a few hundred employees, less than half of which are devs.

I have now dug through all the Impact docs. It looks pretty cool. It feels like it's trying to be Legend State. I think I liked overmind better, but maybe the docs or project are still incomplete. The store model feels atomic (which I think you sensed too), but I don't see how stores consume other stores. And I can see the side effects model breaking down quickly in a complex app.

Cool, feel free to AMA.

[marbemac]

❤️ thank you - started digging in yesterday, attempting today to implement one of the more complicated components (virtualized data table that loads rows/columns on demand as the user scrolls vertically/horizontally). Really intrigued to try and use the atom ttl functionality to attempt swr style behavior on a per table cell basis. It's also forcing me to wrap my head around how async work is best handled with Zedux.

we needed signals to also be powerful event emitters, have opt-in immer-style proxies that translate mutations into transaction objects e.g. for use with ag-grid's transaction model, and be reverse-mappable.

This sounds.. really great. You mentioned the v2 alpha already has the signals implementation - is the alpha usable but just not feature complete?

I have now dug through all the Impact docs. It looks pretty cool. It feels like it's trying to be Legend State. I think I liked overmind better, but maybe the docs or project are still incomplete.

Yeah it seems quite minimal atm - might be their intention though, for those use cases that only need something simple.

[bowheart]

The alpha is usable and surprisingly stable. But the last released version from over a month ago doesn't have the signals implementation. Sorry, it was maybe premature to say the new signals implementation was done. I only just finished the code for it last week. I'm still sorting through some types for other injectors/hooks that accept signals as well as new tests for the implementation. But I'm getting close to raising a PR for #115.