Reading the interesting article from Dan Abramov:
https://overreacted.io/writing-resilient-components/
I stopped at memoization. I did not know this technic before, but simply because nobody care so much about names before functional programming. And so I discovered how large is the cover of react hooks, useMemo() that does
https://github.com/alexreardon/memoize-one
In a cleaner way with the hook, in my opionion
It recall me the lodash.throttle() function, but relation I setted for this is obscure, I think it is because of optimization nature of both the concepts: do not refesh too often (_.throttle), do not recalculate if source not changed (memoize)
But I further goes insight on react hooks, and I found redux-react-hook
https://github.com/facebookincubator/redux-react-hook
it looks simplier.
But from the point of view of testing, hooks can not be mocked, or it could but providing a reduced store.
While when using HOC one can just test the inner component (LOC?) providing just properties, here the hook refers to a library.
To separate these and relay only on properties, the properties should be functions: useDispatch() and useMappedState() should become
this.props.useDispatch and this.props.useMappedState
That would make code less appealing, but really not so bad, changing the example of project README.md
export function DeleteButton({index,useDispatch, useMappedState}) {
….
}
just the function-component declaration is changed, and still code is testable injecting the right functions
Anyway, given the concept behind redux, using two provider calling reducers should not be a problem, I mean, the switch can be progressive