More on reusability for custom components.

[sassanh]

Suppose that I'm trying to publish a react component to be used in redux applications. I want the react component to be stateless and keep its state in redux. Suppose that my component consists of an actions.js, a reducer.js and an index.jsx for example. The developer who wants to use it combine its reducer in some part of his redux store via combineReducers provided by redux (or redux-immutable). Then when an action gets dispatched the reducer perfectly changes the relevant part of state in store. So good so far. But what if the the developer wants to use it multiple times?

Suppose that the component is named Component and this is the desired component tree of the developer:

Container-1
|
|--Container-2
| |
| |--Component
| |
| |--OtherComponent-1
|
|--Component
|
|--OtherComponent-2

And suppose that Container-1 combines reducers of Container-2, Component and OtherComponent-2 and Container-2 combines reducers of Component and OhterComponent-1.

Now when an action from actions.js is dispatched, both reducers will apply it to their state (if developer doesn't do anything to prevent it.)

Currently I'm solving this by providing an elementId field in my actions related to reusable components and providing the same elementId field in initial state for relevant parts of state. For example my initial state for above configuration would be like this:

{
    "container-1": {
        "component": {
            "elementId": "topRightCornerAvatar",
            ...
        },
        "other-component": {...}
    },
    "component": {
        "elementId": "topLeftCornerAvatar",
        ...
    },
    "other-component-2": {...}
}

Then I check if the elementId provided in action matches the elementId of the state in the beginning of the reducer function. This way the action only affects desired instance of element.

It'd be great if we could have some utilities provided in redux for this purpose. For example combineReducer can take these elementId-s (or whatever else) and check it automatically when it receives an action and ignore the action if its elementId doesn't match. It can do it only if the elementId is provided.

[markerikson]

A couple quick thoughts:

• Remember that combineReducers is simply a utility for the most common use case. Redux users are expected and encouraged to write custom reducer logic for their own specific use cases.
• This seems like a fairly niche use case, and is not likely to be something that would be built into Redux itself.

[sassanh]

Well I think if we implement it in combineReducers we give the developers the ability to write reusable redux components (not necessarily react components) that can have multiple instances. Currently redux architecture has no solution (not a clean one that doesn't add lots of overhead to developer) for instantiating classes using its store as storage multiple times. The class could be anything. It's such a common use case to instantiate a class multiple times.

Just a simple example:

• Consider you want to make something like Material-UI, Zurb Foundation or Bootstrap and you want its elements to use the global redux store as their storage. Obviously users want to have multiple instances of an element in their page simultaneously (the element being a menu, a button, a slide show or whatever else). Currently the the library uses redux it should ask its users to assign an unique elementId (or something like that) to the relevant part of state for each element they instantiate.

But it's not limited to above use case. "Every" class that's not to be used as a singleton will benefit from it. And it's such a huge use case.

Besides I think it can be done with less than 20 lines of code in redux core and then we have the ability to instantiate multiple times from a class using redux store as its storage "easily" with no overhead or dirty hacks.

[naw]

@sassanh How do you propose the id be generated? Is the component creating a unique id at mount time or something?

Are you recommending redux handle things only on the reducer side, but the rest of the reusuable redux component (action creators, component, etc.) has to be handled by the component author?

[sassanh]

@naw I think it's risky to let the component author generate the id himself. It may not be unique. Besides other than being risky the id generator is another repeated code that can be integrated. So I think it's better that we generate at in combineReducers.

I think this is the "least must have" for redux to support multiple instantiations of classes using it as their storage, but it could be improved if you agree with me that multiple instantiations can be a huge use case of developers using redux in future. Currently redux is usually used for singletons but if we support multiple instantiations better and better it can be used as backend storage for applications with full oop architectures (not just those using singletons.)

So based on how much we think it's important we can add another level of support for it. This is the 2 levels of full oop support I can think of. I'd be glad if others can complete/improve it:

1. Generate an id in combineReducers and provide it in the state. The wrapper in combineReducer that dispatches actions to its child reducers should take care of the id checking and don't dispatch action to reducers with different id-s than the one specified in the action. Then add to documentation how developers can enable this id generator for their reducer (probably as an option for combineReducers or a property of the reducer function) and how they should provide this id in their actions.
2. Ease the action creation by something like modifiers that automatically assigns the id in the action. If we have any utility that automates type assignation, it should give options to automate id assignation too, that's enough.

That's all I did manually in my current project and it was enough for me to have redux as storage backend of my classes.

P.S. Of course id is supposed to be unique, something like uuid.

[naw]

@sassanh

I believe the redux ecosystem has room for innovation in the "reusuable redux component" problem space, although I don't necessarily see such innovation as belonging in redux core, especially if it's just a replacement for combineReducers which can easily live in separate package.

With that said, I do want to understand your proposal better, but I'm afraid I don't get it.

In order for any given component to be connected to redux, it has to know where in state to look. If this location depends on an ID, then the component (or some singleton wrapped instance of its action creators) must have knowledge of which ID to use. Supposing combineReducers generated an ID for a given "instance" of a component, how does the consuming component get that ID?

It would be helpful to see an example of what your arguments to a modified combineReducers would look like.

Also, a good reusuable redux component pattern should be able to handle dynamically added components, which you don't necessarily know at the time that you call combineReducers.

I can write more on this topic, but first I'd like to better understand what you're actually proposing. Not trying to throw water on your idea --- I just don't understand it.

[markerikson]

I'm not really clear on what's being proposed here. If you're really suggesting that combineReducers should be generating IDs, that's a no-no, because that means that the reducers are not pure functions any more.

On top of that, this really sounds like a very specialized use case, and not at all the sort of thing that combineReducers was intended for. In addition, the Redux team aims to keep the core of Redux as minimal as possible, and provide enough of a base to allow additional concepts to be built on top of that minimal core. You may want to read #1768 and #1813 to get an idea where Dan stands on changes to the core Redux APIs (including some examples of how a change that can be done "in just a few lines" actually has very wide-reaching implications).

There's already numerous examples of utilities that can generate more specialized reducer functions, and addons that implement some approach to reusable component state. The Reducers and Component State pages in my Redux addons catalog list most of the options that are currently out there.

[naw]

As a point of clarification, there is a difference between combineReducers itself (as a factory) being impure, and the reducer that it outputs being impure.

I agree with @markerikson this is unlikely to be a good candidate for redux core, but I really do want to understand and dialog about the idea. I suppose we could move the discussion elsewhere if that would be better.

[sassanh]

@markerikson about purity of combineReducers as @naw pointed out it's our factory function, we should keep combination (defined here https://github.com/reactjs/redux/blob/master/src/combineReducers.js#L122) pure not the combineReducers itself.
About it sounding like a very specialized use case, well it may not be a use case for a todo app or other web apps that don't need oop, but we're talking about combing redux with oop architecture. I can't call it a specialized use case. If we support oop well I'm sure there'll be lots of applications using redux and oop together and it'll provide better, cleaner ways of coding for web apps.

@naw The ids should be generated in combineReducers function (https://github.com/reactjs/redux/blob/master/src/combineReducers.js#L100) but don't mistake it with combination function (https://github.com/reactjs/redux/blob/master/src/combineReducers.js#L122).
Quoting from your comment:

In order for any given component to be connected to redux, it has to know where in state to look.

Currently combineReducers already provides it, for example when you do this:

const reducer = combineReducers({a:redcuerA, b: reducerB})

the whole state is not passed to reducerA, only store.getState().a is passed to reducerA and its results will be replaced in store.getState().a so it can't change other parts of state. That's 80% of job combineReducers is already doing. The only missing thing here is a problem with dispatching actions that is even though a reducer only applies to its relevant part of state, currently there's no way in redux to make an action only be sent to a specific reducer. So if you dispatch an action to focus a button for example, it'll be dispatched to all reducers in reducers tree generated by combineReducers. Fortunately we can manage to apply this action only on button reducers with the help of type field in the action (for example setting type to "BUTTON_FOCUS") but in order to make it only apply on an specific part of state that's bound to our desired button, we need to prevent other reducers in reducers tree to reduce this action. To achieve this we need to assign an id to the action and to the reducer and make the combination function (https://github.com/reactjs/redux/blob/master/src/combineReducers.js#L122) to only apply the action on reducer if these ids match.

This is how it goes (just a sample implementation):

combineReducers({
  a: reducerA,
  b: {
    reducer: reducerB,
    reusable: true,
  },
  b2: {
    reducer: reducerB,
    reusable: true,
  }
})

now combineReducers generates an unique id for b and another one for b2 storing it in its context when and it checks here https://github.com/reactjs/redux/blob/master/src/combineReducers.js#L140 if there's an id assigned to reducer, if so it next checks if this id matches the action.id and will apply action on reducer only if these ids match. That's all this way we have the remaining 20% done.

Look at one of my reducer functions in my current project, this is the reducer of my Menu component:

export default (state = new Map(), action) => {
    if (action.elementId === state.get('elementId')) {
        switch(action.type) {
            case actions.SET_ACTIVE_PATH:
                state = state.set('activePath', action.activePath);
                break;
        }
    }
    return state;
};

I have that if statement in all of my reducer functions, because I'm using redux as storage backend of an oo application. Now I can have 6 menus simultaneously, all I have to do is:

const topBarReducer = combineReducers({
  leftMenu: menuReducer,
  rightMenu: menuReducer,
})
const finalReducer = combineReducers({
  loginDialog: dialogReducer,
  registrationDialog: dialogReducer,
  confirmDialog: dialogReducer,
  stickyMenu: menuReducer,
  topBar: topBarReducer,
  leftSideMenu: menuReducer,
  contextMenu: menuReducer,
})

and my initial state would be something like this:

{
  loginDialog: {elementId: 'LOGIN_DIALOG', ...},
  registrationDialog: {elementId: 'REGISTRATION_DIALOG', ....},
  confirmDialog: {elementId: 'CONFIRM_DIALOG', ...},
  stickyMenu: {elementId: 'STICKY_MENU', ...},
  topBar: {
    leftMenu: {elementId: 'LEFT_MENU', ...},
    rightMenu: {elementId: 'RIGHT_MENU', ...},
  },
  leftSideMenu: {elementId: 'LEFT_SIDE_MENU', ...},
  contextMenu: {elementId: 'CONTEXT_MENU', ...},
}

I hope I could make it clear. Now I'm all ears to hear your ideas.

[markerikson]

There's no reason to put something like that in combineReducers. If you want your slice reducers to only respond to specific actions, you can just write your own little higher-order reducer that does that. In fact, here's a quick little generic filtering higher-order reducer to give you an idea:

function createFilteredReducer(originalReducer, predicate) {
    return (state, action) => {
        if(predicate(action) || !state) {
            return originalReducer(state, action);
        }

        return state;    
    }
}

function reusableReducer(state, action) {.....}

const item1Reducer = createFilteredReducer(
    reusableReducer,
    action => action.someField === "id1"
);

const item2Reducer = createFilteredReducer(
   reusableReducer,
   action => action.someField === "id2"
);

I understand what you're saying about "targeting" actions to a specific "copy" of some reducer logic, but combineReducers is not the place to put that.

[naw]

@sassanh Thanks for your detailed example. Yes, your desire to reuse reducer logic for multiple instances of the same component is definitely commendable. I believe a higher-order reducer (or a reducer factory, as some people might call it) as @markerikson wrote is a good pattern for solving this problem. A more specific case of that would look like this:

filterById(originalReducer, elementId) {
  return (state, action) => {
    if (elementId === action.id) {
      return originalReducer(state, action);
    }
    return state;
  }
}

Then, you setup your reducer like this

const topBarReducer = combineReducers({
  leftMenu: filterById(menuReducer, 'LEFT_MENU'),
  rightMenu: filterById(menuReducer, 'RIGHT_MENU')
})
const finalReducer = combineReducers({
  loginDialog: filterById(dialogReducer, 'LOGIN_DIALOG'),
  registrationDialog: filterById(dialogReducer, 'REGISTRATION_DIALOG'),
  // ... rest skipped for brevity
})

Now, if you want to go one step further and have combineReducers actually call filterById for you and inject an elementId based on the position in the state tree so that you don't have to spell it out explicitly, then that's certainly a viable convention for your app . Personally I'm doubtful that's a good convention for all redux apps, but that's just my opinion. Bear in mind redux doesn't even force you to use a hash with keys as your state object -- your object could literally be any JavaScript object (although it's recommend it be serializable)

I'm definitely in agreement that you should reuse your reducer logic, and I'm definitely in agreement that passing an identifier in the action is a good way to do that. I'm with @markerikson that a factory is a good pattern for this.

Ultimately, combineReducers (or your replacement) is just a factory that builds a reducer from a given abstraction. If you think you've landed on a particular abstraction that works well, could I suggest that you release your custom combineReducers function in a package and see if it's useful to anyone else? --- you don't need buy-in from redux core to achieve this, since no changes to redux code are necessary --- on the contrary, redux is completely plugable in this regard since anyone can choose any abstraction they want and write a factory to build a root reducer to give to createStore.

As a final point:

Your menu and dialog components need to know which id they correspond to so that they can put the correct id into the actions that they dispatch. So in your example, your components must have the id, perhaps passed into them as a prop like <Dialog id="CONFIRM_DIALOG"/>. I hope it's clear that anything you do in combineReducers is only the reducer side of things ---- you still have to have a way to get the id into the components themselves (which isn't shown in your example). Are you hardcoding it?

[sassanh]

@markerikson @naw Thanks for your detailed comments and opening the issue in details. Personally I think the current combineReducers is "partially" oop friendly, if it was the case that redux core should stay minimal and features should be added by external extensions then I think combineReducers shouldn't apply state changes only to a part of state. If it was the case combineReducers itself shouldn't exist in redux code at all, or at most it should just combine reducers taking them as array (not hash map) and just apply them in order (or even to keep core more minimal, don't even guarantee the order) to whole state not just part of it. The fact that it's applying the reducer only on an specific part of state makes it half way compatible with oop and I don't like incomplete things personally so I'd either complete it or remove it altogether and people would make different packages with different combineReducers for community and plug it to redux. But I'm sure there were good reasons to have combineReducers this way in core, I'll be glad to hear about these reasons.

Other than that I totally understand that redux wants to be minimal and I can see this minimalism in other parts more or less.

It's unfortunate for me that frontned community doesn't like oop as a first class architecture (or at least optional first class architecture) coming from a 15 years C++ and Python programming background I never felt comfortable with javascript and always found it loose till I read about redux and es6 classes 3 months ago. The discipline redux enforces to webapp development is really what it needed in my opinion but I wish it enforced more discipline with forcing use of immutable and I wish it supported oop better by applying above suggestion for example. For someone coming from C++ and python this use case is the main use case for a program with more than 100 lines of code as writing the whole program with singletons is not a good pattern there, ~%99 of the time you implement a class not to instantiate it only once, you implement it instantiate it multiple times. ~%99.99 of usages of storage backends in those languages (such as Sql, Nosql etc or Redis for an in memory example as it's the case with redux) use an id field for storing each instance. Currently redux is like a storage engine that supports multiple classes/tables internally but if you want to have more than one object/row in your table you need to plug something else to its core if you wanna avoid rewriting same code again and again. I try to understand that you put supporting classes/tables in core but you think supporting multiple instances/rows shouldn't be first class option here. I guess you don't see it as classes/tables and instances/rows. I'll be glad to know the philosophy behind having this combineReducers in core while it could be plugged later and to know how you see this.

I hope this thread helps someone trying to achieve this functionality in his app. I really appreciate your thoughts and ideas.

@naw about providing id to elements, I should've include this in my above example:

export default TopBar = props => <span>
  <Menu {...props.leftMenu} />
  <Menu {...props.rightMenu} />
</span>;

export default Application = props =><span>
  <Dialog {...this.props.loginDialog} />
  <Dialog {...this.props.registrationDialog />
  <Dialog {...this.props.confirmDialog />
  <Menu {...this.props.stickyMenu} />
  <TopBar {...this.props.topBar} />
  <Menu {...this.props.leftSideMenu} />
  <Menu {...this.props.contextMenu} />
</span>;

So elements indeed have access to their id to use it in their action dispatches. I provide their relevant part of state as their props.

Again I'm thankful for sharing your ideas on this with me.

[sompylasar]

@sassanh see reduxjs/react-redux#278

[sassanh]

@sompylasar thanks for the link but I think it should be fixed in redux (either in its core or as an external package providing this feature for redux) and not in react-redux as it's a problem with redux handling multiple instances of same class/component. I guess we have enough of packages with names like "x-y-z-w-q". "react-redux-reusable-components" would be my nightmare, lets keep it "redux-reusable-components" if not "redux". It's not only react that needs to reuse its components.