📜 ⬆️ ⬇️

Redux - revision logic reducer'a and actions


The other day, picking on the set of files redux'a, where, according to logic, the files are made in reducers, actions, constants of the types of actions. All this turned out to be quite a not an easy task keeping all these types of files in my head and follow the logic. And ... eureka, the idea of ​​simplifying the writing of redux logic. Maybe creating your bike, but who didn't try to write your bikes? But the main thing is not writing, but written support when . Let me try to show you a bit of my vision of my redux logic.


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 the docks by redux .


action has a type like:


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

I think there is no need to show constants.


Bool


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



Entry into logic


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


reducer


peeped into google


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

That is, the shaft on it is a gear, this gear sends the other gear a rotation which in turn to its shaft. We remove the shaft and gear is removed together with it. Not discontinuous so to speak module.


If you hold the allegory further then the shaft is an action and the gear is logic. From this it follows that the gearbox acts as such a link in ensuring the transmission of torque, that is, data in the application. It must support the perfect working environment of the mechanisms.


action


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


And so it went. My bike


reducer:


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

yes this is my entire reducer. Maybe there will be a small gap patterns, how? we took the logic out of reducer'a ..? Yes. I tell you, we got the logic out of the reducer'a !!!


Let's look at the action:


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

For the sake of this, we have taken out the logic responsible for the transfer of data to the site. 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 in which from where the legs grow and if you need to quickly find and fix or supplement.


Worth noting We removed constants. Yes, and switch too. This has reduced the complexity of O (1) execution in the reducer.


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



Source: https://habr.com/ru/post/440940/