Discussion: consider expanding the Redux core

[markerikson]

Note: This idea is almost entirely hypothetical, but it's been suggested a few times and is worth discussing.

The Redux core has been tiny since the beginning. The original intent was always to keep the core small, make the API extensible, grow an ecosystem, and maybe "bless" some plugins along the way. (References: The Tao of Redux, Part 1: Implementation and Intent, You Might Need Redux (And Its Ecosystem))

This has worked great, in the sense that there is indeed a huge ecosystem of addons for just about any use case you can think of. As part of that, the core library package has stayed basically unchanged for the last three years, and the docs have been very unopinionated (usually just listing some available options, like folder structure approaches).

We've recently introduced our new redux-starter-kit package. It adds some deliberately opinionated utilities around the Redux core, like simplified store setup with the most commonly used options and some sanity checks, simplified reducers with lookup-table definitions and Immer-powered "mutative" immutable updates, and even creating entire "slices" of state at once. While it hasn't gotten widespread usage yet, the reactions I've seen have been almost universally positive.

As part of that, some people have suggested that we might want to consider actually renaming the current redux package to something like @reduxjs/core, and rename redux-starter-kit to be the new redux package. I recently ran a Twitter poll asking about this, and the results were a bit surprising. 54% of actual respondents were in favor of this idea.

I'll be honest and say that this is not very likely to happen. But, it's worth opening up a discussion about what actual additional functionality is worth adding to the core, if any.

So... thoughts? Ideas? Suggestions?

As a reference, I'll link issue #2295: Request for Discussion: Redux "boilerplate", learning curve, abstraction, and opinionatedness. That overly-long thread does give some indications as to the kinds of things people might find useful.

Tagging @modernserf and @matthew-gerstman , since I know they have opinions on this, and of course @timdorr , @gaearon , and @acdlite .

[BTMPL]

Personally I think that redux core being the size it is right now is a good thing, so wouldn't recommend moving RSK into core in any form, nor changing the "scope" of the core.

If you'd go with the scoped package name, I would see things like:

• @redux/core for current redux
• @redux/react for current react-redux (same pattern for bindings for other libraries)
• @redux/starter-kit

And then you could also consider moving redux-thunk into @redux/thunk as majority of users will use either thunks or sagas. Having the scoped package would also somehow fit into Dan's idea of "small api, recommended 3rd party libs"?

[markerikson]

Very quick side tangent: there's still haziness around the @redux scope / name on NPM. I know we now own @reduxjs. I think Dan owns the redux NPM user based on some earlier discussion, but we've had some confused-ish discussions about trying to get me and Tim added to that, and I'm not clear on the nitty-gritty details on trying to publish stuff "org"-style from multiple people when there's a "user" by that name. It hasn't been a high enough priority for me to keep pinging Dan about for further investigation.

Let's leave the scoping/renaming aspect out of this for now. This thread is gonna be bike-sheddy enough without bringing that into it :)

Also, to clarify the point of the discussion:

I'm particularly interested in what other functionality should be included in the redux package exports list.

For example, two items off the top of my head that would be reasonable to have built-in:

• redux-thunk: the most commonly used middleware, and the starting point for any meaningful non-component logic
• reduce-reducers: a small function to sequentially execute reducers, instead of "in parallel" the way combineReducers works

Both are small, simple, and unlikely to change much going forward. (Actually, looking at reduce-reducers, I'm surprised to see it's gone from like 7 lines to about 30 - looks like it accepts an initial state now.)

[BTMPL]

Ok, if this is more about "what could we add to the core, as option, and not enforced by default", I'd vote for:

• redux-thunk
• the createReducer function from RSK; it's really handy and I feel like the map notation for reducers is underappreciated - having it as an option (available, documented in the main API docs) would help ease-in people (map of actions vs. switch)
• either add configureStore or alter createStore in some way tat makes it easier to add the often used tooling (devtools) - I like the fact it accepts object notation with a bool that enables devtools

I'm not sold on the createAction helper, IMO it obfuscates the mechanizm a bit, and action creators are already simple enough.

[matthew-gerstman]

I realize everything I'm saying below has already been said, but I think it's important to summarize why we would do something like this.

Problems

Problem Redux currently solves

Redux at its core (heh) provides a sane way to manage state in (more often than not) React applications. It provides a really great dev experience (once you learn it) that makes your applications very easy to debug.

Problems with the way Redux solves them

• Learning Curve: Redux has a steep learning curve. More concerning than that (to me), I see a lot of people using it poorly. Returning thunks when they only need to dispatch a single action, using mapDispatchToProps manually, and worst issuing setTimeouts and side effects in reducers.

• Boilerplate: Redux requires a lot of boilerplate: laying out switch statements, action creators, selectors etc. This compounds the learning curve problem because once a single dev learns it wrong the other devs copy paste the bad code.

The current state

• There's a general murmur of "Redux is dead, long live whatever." Graphql libraries handle state management quite efficiently (on the api layer) and React is bringing in a very sane way to manage state with hooks.

• Redux is not shiny This is stupid but I think its true. Newer libraries are shinier, "thought leaders" don't talk about why you should use Redux because there's nothing new to talk about, and as a result Redux is starting to look a lot like underscore, jQuery, or any number of libraries that were once popular but now seem like a lot of trouble.

The next state

That brings us to the conversation we're having at the moment. Should we do something like make RSK the core library? I think a big drastic move is the kind of thing that solves the Redux is not shiny problem and is a very fair attempt at solving the learning curve and boilerplate problems constantly discussed.

With all of this in mind, these are the types of things I'd think would be interesting moves for a new version of redux. These are in no particular order, and can be considered the ramblings of a lunatic.

• Built in support for thunks (with maybe a less confusing API)
• Simple boolean config for devtools on/off ( default to on)
• A utility like createReducer()
• Warnings around creating multiple stores
• Built in createSelector/memoization utils
• First class support for typescript (as in written in typescript).
• Simpler react-redux bindings. mapStateToProps and mapDispatchToProps seem to confuse a lot of people. Can we do all this with hooks? Can we intelligently detect if a function is a thunk and if so pre provide dispatch?
• Side-effects middleware. Adding another first class middleware that says "this action was dispatched, call this other action creator"
• Make enhancers second class citizens. I think these confuse people more than help them. I'd actually consider moving this out of the core library and into a second package.
• Make withExtraArgument a second class citizen. Move this out of the thunk package and into an advancedThunk middleware.

[markerikson]

At the risk of totally running this conversation off the rails, I'll toss out one more maybe-crazy idea:

What if we were to rewrite the core lib in TypeScript?

edit

Hah, I shoulda read @matthew-gerstman 's comment all the way through first :)

[matthew-gerstman]

To be fair I buried that in there.

[matthew-gerstman]

Another idea in my head. Two hooks we can provide

withState(selector: Function) - mapStateToProps equivalent
withDispatch(actionCreator: Function) - mapDispatchToProps equivalent.

Also what if the thunk API looked like this

function actionCreator({dispatch, getState}, ...argsItNeeds)

And then when we do the binding we simply bind the first parameter.

I've seen a lot of users do dumb things like reverse these two
(dispatch, getState) => businessLogicFunc()
businessLogicFunc() => (dispatch, getState)

This would alleviate that.

[markerikson]

Let's focus on just the Redux side of things, not React Redux. That's better suited for reduxjs/react-redux#1063 .

[ematipico]

I will try to keep my idea around Redux, because I see also references to React.

Premise: for me Redux must stay agnostic as much as possible and it shouldn't contain third party libraries (unless they become built in inside the core lib). I introduced Redux inside a SPA that wasn't react and it worked like a charm. Fast, reliable and neat. Teammates loved the order introduced by redux.

Something nice that the core library should provide, are some utilities that are missing at the moment:

• withState: an high order function that, as input needs a function and it returns a function with the current state as last argument
• withDispatch: an high order function that returns a function with the dispatch as last argument

When working outside the framework, these utilities become really handy.

[mpeyper]

What if we were to rewrite the core lib in TypeScript?

Other than the benefits to redux for having typesafe development, what benefit would this provide to users that the existing type definitions do not?

Built in support for thunks (with maybe a less confusing API)

I think bringing redux-think in is a good idea. I'm not sure why people find the existing API confusing and I'm not sure how it could be improved to be less confusing, whilst still being a thunk.

Perhaps the solution is not to bring in thunks bit rather something like redux-promise?

Simple boolean config for devtools on/off ( default to on)

+1. As someone using the logOnlyInProduction option, perhaps accepting an options object as well to the devtools option could make it a bit more flexible?

Make enhancers second class citizens. I think these confuse people more than help them. I'd actually consider moving this out of the core library and into a second package.

I don't think you could (easily) move them out of the core package as a applyMiddleware is an enhancer. I guess the createStore function could just accept middleware as params at the end?

const store = createStore(reducer, initialState, thunk, sagaMiddleware, logger /*, ...*/);

Side-effects middleware. Adding another first class middleware that says "this action was dispatched, call this other action creator"

I think this is a great idea. It's probably the biggest reason I've seen people reach out to redux-saga and redux-observable and then they get all caught up in the complexities of those more powerful async/side-effect frameworks. Having a simple "listener" style middleware would be fantastic. Not sure what the best API would look like, but something like could work:

const listener = ({ getState, dispatch }, action) => {
  if (action.type == 'PING') {
    dispatch({ type: 'PONG' });
  }
};

applyMiddleware(actionListeners(listener /*, listener2, listener3,...,*/));

It's simultaneously thunk and reducer like, so groking it should not be too difficult for redux users. It could even have a withExtraArgument variant that appends a third incoming argument to the listener.

Perhaps something like this already exists or this is worth making into a seperate package anyway?

---

My ideas

• A mergeReducers utility. Essentially combineReducers, but instead of putting each reducer at on a key, it merges their output. e.g:

  const a = (state, action) => ({ c: 0 });
  const b = (state, action) => ({ d: 1 });
  
  combineReducers({ a, b });
  
  // { a: { c: 0 }, b: { d: 1 } }
  
  mergeReducers([a, b]);
  
  // { c: 0, d: 1 }

• If RSK becomes more official, perhaps the existing combineReducers (with all the warnings) can move into there and the core library can have a more cut down version?

• An addReducer function (andremoveReducer?) that allows additional root reducers to be added to the store (merging their output). The dynamic reducer/codesplitting story of redux is currently very messy, partly do to the need to replace the whole reducer rather than just appending more.

• Some way of accessing the root state within a combineReducers slice reducer. I know this has been requested and shot down, like, a billion times now, but there is a reason it is so widely requested. The response is always, "combineReducers is only one way to construct a reducer, you can always write your own" (or some variant of that), but IMO, many users don't want to write their own (there's a reason it is practically the default way to compose reducers). They want to write small, simple reducer functions and let someone else worry about the complexities of composing them together. I'm not say the API of basic reducer should change (although I can't think of any alternatives), but having some way of accessing it would be fantastic.

---

I'll think some more and see if I come up with anything else. I'm really excited to see what suggestions others have!

[BTMPL]

Should we do something like make RSK the core library?

I'd be against; the redux core is self-sufficient and some of the design choices of RSK are just obfuscating things and making things harder to understand/use (createAction).

Built in support for thunks (with maybe a less confusing API)

Not sure which part of the API people find confusing: the arguments, or the fact that you have to return a function? As for replacing it with redux-promise - I'd be against this one. Seeing as how we aim to make Redux easier to understand, I would not include another concept (Promises) only for this point. There are still a lot of devs out there that are confused about how to work with Promises.

Rewrite into TS

Yeah, that would benefit the developers, not the community. I'm for it, but might need to consider this could possibly affect contributors.

An addReducer function (andremoveReducer?) that allows additional root reducers to be added to the store (merging their output).

Is there any prior art for this? What API do you see? Something like store.addReducer('sliceName', reducer)? That would be a good idea actually; might help modularize libraries (e.g. you no longer need to include redux-form reducer in your createStore, you just import the store and register it whenever you need; we're doing something like this in our app but thanks to replaceReducers)

[mpeyper]

An addReducer function (andremoveReducer?) that allows additional root reducers to be added to the store (merging their output).

Is there any prior art for this?

I don't want to derail the conversation too much with detail as they can be worked out later once we decide what we want to include, if anything, but you asked, so...

Shameless plug: This is more of less what the core package of redux-dynostore does (except we call it attachReducer instead of addReducer).

It would also benefit proposals like reduxjs/react-redux#1150.

What API do you see?

As long as the reducers return objects (which it should be to support adding a new key anyway), there's actually no reason you need to define the sliceName and the API could just be store.addReducer(reducer). You just (shallow) merge the result from each reducer into the result of the previous one. Potentially the sliceName could be an optional second argument that would just run the reducer through combineReducers({ [sliceName]: reducer }) before adding it to the reducers array.

Either defining the sliceName or merging the results, the definition of the root reducer(s) would probably need to ensure that function return an plain object, which I imagine would make this a rather controversial change for the library. I could argue that most apps already do this thanks to combineReducers and that it's generally a good idea for readability, debugability and refactorability (and if your app is simple enough to only need a single array or a scalar value, then your probably didn't need redux in the first place).

As for replacing it with redux-promise - I'd be against this one.

TBH, me too. I'm more than comfortable with the thunk API and think you couldn't get a simpler async/side-effect model. I made an assumption from my own very limited experience that most devs are pretty comfortable with promises these days and most uses of thunks use promises internally anyway (i.e. AJAX requests). I guess I missed the mark a bit on that one.

[doxick]

redux-starter-kit

RSK is still far from feature complete and, while it is already a step up, it still has basic issues which have been discussed but are hard to find a solution for. Merging it into core makes more sense for functionality that will be used for a majority of implementations.
E.g. createStore (core) vs createStore (RSK) "feels" weird to ship them both with Core; "We know createStore is a bit clunky, so we also give you an easier version to go with it"...

Keeping redux framework/usage agnostic is pretty high up on the list imho.

Immer

Will it ship with Immer, even though the majority is not using it?
Personally, i like working with Immer, since i know the do's and don'ts of mutability/immutability.
I don't think the majority of people do, and this enables them to write wrong code with a safety net.
It will greatly reduce the amount of questions about errors related to redux, yet (almost) nobody really knows why it then doesn't work somewhere else.

redux-thunk

While it is good for a large amount of usage-cases, it's also very limited in its use and most projects i see it is not used. If it will be merged, why not provide it by default from the store ? The size-impact is minimal.

Adding helper/utility functions

Providing helper functions, like combineReducers and the proposed createReducer makes more sense, since most of them are pretty much hashed out and limited in their usage:

• combineReducers
• reduceReducers (or maybe chainReducers, to make it less descriptive)
• createReducer

They all make sense since they greatly remove boilerplate, increase readability and provide basic functionality without being opinionated.

createAction

While i use createAction (or createActions(prefix, actionMap)) in every project i do, i wouldn't add it, since every implementation doesn't cover the use case people use it for:

(type) => (payload) => ({ type, payload })
(type, identityReducer) => (...args) => ({ type, payload: identityReducer(...args) })
(type, identityReducer) => (...args) => ({ type, ...identityReducer(...args) })
(type) => (payload) => ({
  type,
  ... (payload instanceof Error) ? ({ payload }) : ({ error: payload })
})

Which one is going to be the createAction to rule them all?

Typescript

Rewriting it to typescript would indeed improve DX while having no (direct) negative impact on current usage.

Redux (core) in itself is a very simple concept to grasp and to work with. Merging it with RSK moves devs away from understanding how it actually works. Moving towards "provided" utlity libraries with the redux namespace indeed feels like the way to go to me.

[BTMPL]

While it is good for a large amount of usage-cases, it's also very limited in its use and most projects i see it is not used. If it will be merged, why not provide it by default from the store ? The size-impact is minimal.

Having it active by default would be a breaking change for the API, and mgiht break some assumptions the user already have (maybe there's a middleware thats already using functions as actions for different reasons; it would also make it harder to teach IMO).

Would also be against immer; the docs could talk about it in greater details, in section that would also talk about performance improvements toolset, like reselect.

[timdorr]

I'm of the opinion that the core should be as minimal as possible. Move out things like combineReducers, bindActionCreators, and compose into their own libraries (or pull from something like lodash in compose's case).

I really don't care if Redux has enough "shiny" features. That's not the point. It's a design pattern codified as a library folks can rally around. I would be happy if there was never another release of Redux, as it's very hard to be improved upon without essentially becoming a different library.

I think RSK should stay its own thing. I'm pretty firm on that too. It forms opinions around the library, but there are plenty of other approaches that are equally as valid for certain use cases. We don't need those opinions leaking into the core, making it harder or less clear for how other structure choices can make use of the library.