Redux - revising reducer logic and actions

One of these days I was tinkering with a lot of redux'a files, where, logically, the files are moved to reducers, actions, type constants of actions. All this turned out to be a rather difficult task, keeping all these types of files in your head and tracing the logic. And ... eureka, the idea came up of simplifying the writing of redux logic. Maybe creating your own bike, but who didn’t try to write their own bikes? But the main thing is not writing, but writing support when . Let me try to show you my vision of my redux logic a little.

Start

And so we have reduce:

// импортируем константы
import { TODO } from './actions/const';
.....
// может быть ооочень много импортов 
....
// и наконец наш reducer
function todoApp(state = initialState, action) {
  switch (action.type) {
    case TODO.SET_VISIBILITY_FILTER:
      return Object.assign({}, state, {
        visibilityFilter: action.filter
      })
    case TODO.ADD_TODO:
      return Object.assign({}, state, {
        todos: [
          ...state.todos,
          {
            text: action.text,
            completed: false
          }
        ]
      })
    case TODO.TOGGLE_TODO:
      return Object.assign({}, state, {
        todos: state.todos.map((todo, index) => {
          if (index === action.index) {
            return Object.assign({}, todo, {
              completed: !todo.completed
            })
          }
          return todo
        })
    })
   ...
  тут тоже может быть ооч много букв и вырастает до... ну в общем только поиск тебе поможет в этом лапшевидном файле
   ...
    default:
      return state
  }
}

taken from of docks on redux .

action is of the type:

// импортируем константы
import { TODO } from './const';
export const addTodo = (value) => ({
  type:  TODO.ADD_TODO,
  payload: value
})

constants I think there is no need to show.

BOOL

I will try to describe the frenzy that I experience when reading the code, especially when debugging or expanding the functionality.

• search - all the time you have to click Ctrl + FgloballyCtrl + Shift + F
• not visible immediately from where the legs are growing. It flows from the paragraph above.
• No, this is just a little, so I still have the whole project pierced by constants. No, I am not against constants, but why? Especially if they are used together with nesting as in the example, and if they are concatenated from several, then this is generally a hell of navigation.
• logic is blurred. In one place of action in another, the processing of these actions in the third (optional) constant is needed only by those two.
• I need to keep a lot of files open when developing or debugging. It flows from the paragraph above.
  Well, etc.

Logic entry

Perhaps it will seem strange and shocking at first, but still it seems to me that this is the place to be. I will try to convey my template.

reducer

spied on google

Gearbox - a mechanism that changes torque and power. This is one or more gears interacting with each other and reducing the number of engine revolutions to an acceptable speed of rotation of the executing node.

That is, the shaft on it has a gear, this gear transmits rotation to another gear, which in turn transfers to its shaft. We remove the shaft and the gear is removed with it. Not a discontinuous module, so to speak.

If you carry out the allegory further, the shaft is the action and the gear is the logic. It follows from here that the gearbox acts as such a link in the transmission of torque, i.e. data in the application. It should support the ideal working environment of mechanisms.

action

As mentioned above, this is the action itself, and the logic of what energy to transmit (in our case, data).

And so let's go. My bicycle

reducer:

export function todoApp(state = initialState, action) {
    if (typeof action.func === 'function') {
        return action.func(state);
    }
}

yes this is all my reducer. Right now maybe there will be a small gap in the patterns, how? we took the logic out of reducer'a ..? Yes. I tell you, we took the logic out of reducer'a !!!

Let's take a look at action:

export function addTodo = (value) => ({
    type:  'ADD_TODO' ,
    payload: value,
    func: (state) =>({...state, value})
  })
}

That's for the sake of this, we brought out the logic responsible for transmitting data to the store. Reducer remained to ensure the operation of the entire mechanism. And he should do it well without being distracted by things that do not concern him. And we can only observe the order of where the legs grow and if necessary, then quickly find and fix or supplement.

It’s worth noting. We removed the constants. Yes and switch too. Which allowed to reduce the complexity of O (1) execution in reducer'e.

This is just an example sketch that you can expand and remove combineReducers. To expand, supplement, change to your needs is so great, to take a tool and make it ideal for your tasks.

And most importantly I want to say.

Be smart. beee