Evaluate other Redux abstraction layers for inspiration

[markerikson]

There's a bunch of Redux abstraction layers out there. Most of them take Redux in directions I'm not comfortable endorsing officially, but some of them might have some useful ideas we can swipe.

Note that we did something similar back in #17 when we analyzed libs like redux-actions and autodux to help come up with APIs like createSlice, so that sort of analysis would be the kind of thing I'm looking for here.

redux-bundler

Henrik Joreteg made a neat little lib called https://github.com/HenrikJoreteg/redux-bundler . It wraps the Redux store to allow defining reusable "bundles", and adds a bunch of various shortcuts. There might be some interesting concepts or bits of behavior we might be able to take inspiration from.

My biggest concern with it is that it relies very heavily on implicit naming and behavior, and it takes the Redux API in some directions I don't particularly want to endorse.

@alexkrolick suggests that something like the createAsyncResourceBundle might be useful - see https://reduxbundler.com/api-reference/included-bundles#createasyncresourcebundle-optionsobject and https://github.com/HenrikJoreteg/redux-bundler/blob/master/src/extras/create-async-resource-bundle.js .

Kea

https://kea.js.org/ is an abstraction layer that has chunks of reusable "logic", which can contain reducers, actions, and sagas. Those can be mounted and unmounted dynamically at runtime.

Easy-Peasy

https://easy-peasy.now.sh/ focuses on "zero config" and has things like computed properties.

Rematch

https://rematchjs.org/ has "no config", built-in side effects, and a plugins API.

VueX

VueX isn't Redux, of course, but it's inspired by Redux. The thing I find most interesting is the "modules" ability ( https://vuex.vuejs.org/guide/modules.html ), which allows plugging in additional chunks of code at runtime.

[nathggns]

Computed properties or properties with dependent varied sounds cool. I guess in theory you should just use a selector, but in some cases you do want to manually set the value. I've found myself using "setter functions" that work quite well with Immer, but that requires discipline and makes it hard to visualise / understand the links between various properties.

[markerikson]

Good comment at https://www.reddit.com/r/reactjs/comments/m0hk63/do_you_use_vanilla_react/gqbst2w/ :

I've used RTK in the past but have chosen to go with Easy Peasy for a variety of reasons. Though I'm definitely going to re-evaluate when RTK Query comes out.

Before that though, I'll list out reasons I think are unfair comparisons:

• "Redux is wordy". RTK and Easy Peasy are roughly equivalent in "length". Neither are particularly wordy especially in comparison to traditional Redux
• "Redux TS support is bad". They both have excellent Typescript support, although I prefer the Easy Peasy approach to TS. They're both very robust

The actual reasons I ended up going with Easy Peasy:

• Injections and action mocking make it much easier to test
• The manner in which you define actions and thunks allows you to completely ignore reduces. Which keeps the state definitions clean
• Injections allow you to cleanly separate the state management and network requests in a way that makes those interactions very service-like
• It is incredibly simple to create computed properties and action/thunk listeners.
• It's still Redux under the hood so I can use the whole ecosystem of tooling, middleware, etc
• Makes state persistence dead easy (you can persist per model and vary what kind of persistence level)

---

I'm not trying to downplay the value of RTK, it is very good. One key downside of Easy Peasy is that the manner in which actions/thunks/etc are defined will be harder to migrate if there are any issues or other libraries I want to integrate that require deep integration into either the state or network layer (limited to Axios-like libraries).

RTK manages to make Redux really easy and straightforward to use without requiring as much control over your state management as Easy Peasy. I think RTK Query (and whether I can leverage it in Easy Peasy) will change the calculus, though I'm unsure how exactly.

Important Note

The RTK Entity Adaptors allow you to optimally managed to handle a normalized state structure (which I always use).

But Easy Peasy usually allows you to completely bypass the need for that kind of sophistication to normalized state management. Though there are a few key features that are missing.

[LuisOsta]

@markerikson Are there any specific areas around current RTK that you think would be worthwhile to look at how other abstraction layers handle it?

Disclaimer:
I am the person who made that comment above.

[markerikson]

Not really sure, and that's kinda the point of the issue :) I'm interested in knowing what other libs do that RTK doesn't, and maybe some implementation analysis on how they do those different things so that we can determine if it's a thing that we might want to try and if it's feasible to do.

[markerikson]

Bytedance seems to have an entire JS ecosystem at https://github.com/web-infra-dev/modern.js and https://modernjs.dev/en/index.html, including:

Reduck: A redux-based state management library.
https://github.com/web-infra-dev/reduck

Some very interesting features and logic wrapping around the Redux core, including an entire plugin system, and "models" with computed properties:

• https://github.com/web-infra-dev/reduck/blob/main/packages/store/src/store/createStore.ts
• https://github.com/web-infra-dev/reduck/blob/main/packages/store/src/store/context.ts
• https://github.com/web-infra-dev/reduck/blob/main/packages/store/src/types/model.ts
• https://github.com/web-infra-dev/reduck/blob/main/packages/store/src/model/mountModel.ts
• https://github.com/web-infra-dev/reduck/blob/main/packages/store/src/__test__/computed.test.ts