High order reducer solution

[jarvisaoieong]

This is live demo: http://jarvisaoieong.github.io/redux-architecture-challenge/ This is my original repo: https://github.com/jarvisaoieong/redux-architecture-challenge

The most valuable part of my solution is in mainReducer

Imagine, the requirement changed. Now we only want to count the NEW_GIF action happened in randomGifPair and randomGifPairOfPair, except in randomGif and randomGifList.

With high order reducer function, it is very easy to implement. We just need to call reducer enhancer to our target reducer. That's all.

const mainReducer = combineReducers({
  counter,
  button,
  randomGif,
  randomGifPair: newGifCountHor('action.type', randomGifPair),
  randomGifPairOfPair: newGifCountHor('action.action.type', randomGifPairOfPair),
  randomGifList,
});

IMO, modern frontend architecture is based on FP.

What we need to do is Inventing on Principle

My principle:

1. immutable data
2. pure function
3. high order function

Apply these basis functional programming technique, we don't need any extra concept.

[tomsdev]

Thanks for submitting your solution @jarvisaoieong!

I quite like it but in my opinion 'action.action.type' makes the root/parent reducer know too much about the inner implementation of randomGifPairOfPair (e.g. the exact nesting level of the inner randomGif components).

I can imagine multiple ways of solving that:

• compare the inner action types recursively until it finds a match or not.
• compose actions without nesting (maybe just a string with dots as separators, or an array of string) so it's easier to match an action type.
• expose a public helper function unwraptRandomGifActions(action) in RandomGifPairOfPair that would return the 'action.action' value (maybe also use some kind of action "signature" to know if this action really comes from RandomGifPairOfPair).

What do you think?

[tomkis]

@jarvisaoieong I really like your approach and it's very similar to what I did with redux-elm

Just one nitpick but the code does not meet this requirement:

It should also be easy to move the position of components. For example imagine the button is top left of your app, and the business now wants it inside a popup, bottom right: this move of component in the tree should rather be easy to make (ie without having to modify all parent components, for example).

Since you need to explicitly define action nesting