How to use High-Order-Reducer, react/redux?

Good day! Try to rewrite reducer using High-Order-Reducer, not yet quite understand how it is to optimize, not to make things worse.
For example there is reduser (which may be at times more)
const createAsyncReducer (state, action) => {
 switch (action.type) {
 case "USER_REQUEST":
 return {
...state
 isFetching: true
}
 case "USER_SUCCESS":
 return {
...state
 isFetching: false,
 data: action.payload,
 error: void 0,
}
 case "USER_FAILURE":
 return {
...state
 isFetching: false,
 error: the action.payload
}
 case "USER_SOME_ACTION":
 return {
...state
 isFetching: false,
 error: the action.payload.some
}
 default: return state;
}
}


and found a record via High-Order. The question of how it could be improved?

createAsyncReducer const = (constants) => (state, action) => {
 switch (action.type) {
 case constants[0]:
 return {
...state
 isFetching: true
}
 case constants[1]:
 return {
...state
 isFetching: false,
 data: action.payload,
 error: void 0,
}
 case constants[2]:
 return {
...state
 isFetching: false,
 error: the action.payload
}
 default: return state;
}
}
const todosReducer = createAsyncReducer([
"TODOS_REQUEST",
"TODOS_SUCCESS",
"TODOS_FAILURE"
]);

const withAddTodo = reducer => (state, action) => {
 const nextState = reducer(state, action);
 switch (action.type) {
 case "ADD_TODO":
 return {
...nextState,
 data: [...nextState.data, action.payload]
};
default:
 return nextState;
}
};

const customReducer = withAddTodo(todosReducer);

Code will only increased...
Please tell us who has some experience with this and best practices for optimizing it.
Thank you!
June 8th 19 at 17:15
1 answer
June 8th 19 at 17:17
The best optimization work with the redux is to use my library redux-light :). And no more reduceron.
Cool, but now we have to deal with this. - Daryl.Sau commented on June 8th 19 at 17:20
I'd do this awkward bike never showed, and you have people to advise and
a library call. Sorry, did not mean to offend, but this mockery of redux I have not seen. - Lenny.Botsfo commented on June 8th 19 at 17:23
and I posovetuete?) - Daryl.Sau commented on June 8th 19 at 17:26
the training session should run. If the return will not find the answer will help with this. It's all very easy really. - Lenny.Botsfo commented on June 8th 19 at 17:29
and constructive criticism will be, or just bow wow?
This is a mockery works in two projects in production. - Jillian.Conn commented on June 8th 19 at 17:32
not found) - Daryl.Sau commented on June 8th 19 at 17:35
it in production in two projects? Do not tell. You wrote this in mid-December. At the same time, this hat doesn't even work.
This is a simple case breaks down the contents of your key:
const store = createStore({ counter: 0 });
const getState = store.getState;
const setState = store.setState;

const increment = () => {
setState({
 type: 'counter',
 counter: getState().counter + 1,
});
};

increment();

This also breaks:
const store = createStore({ counter2: { value: 0 } });
const getState = store.getState;
const setState = store.setState;

const increment2 = () => {
 const { value } = getState().counter2;

setState({
 type: 'counter2',
 counter2: {
 value: value + 1, 
},
});
};

increment2();

But something more complicated? Sorry, I doubt it was used in production. You must be lying.

Even if you fix it, you probably do not understand what redux and how it works. That gives you and guarantees its use. And why and how reduceri you with a light hand refused.
You with his hurdy-gurdy even store will not be able to update human.
You just break the whole concept redux, not wondering, why am I doing this?
Why use the hat, if the action function gets as many implementation details that when editing or zoom have to rewrite all references to store.
About ReduxDevTools you probably have not heard about the side effects and the middleware too. That is probably not a serious code written.
Try to write CRUD on the hurdy-gurdy and specifically missed the boat.
You probably don't know what redux is, and why so many people are struggling with minimum boilerplate to make use of concise and as flexible as possible, just picked up and "solved" the problem in 80 lines of code for the evening, broke the whole concept to the e@#yum.

Try yourself to answer the questions:
1.Why then do redux? You break all his concept, it doesn't work as it should. Or are you just not able to write something more and use some ready solutions? Wrong use, I must say.
2. What types of actions? To penalise to stand as you suggest in the README.md? What are the benefits violacea from their use? You probably never even thought about it.
3. How to get the current status? If redusere it is the chain and every reducer receives only that part which is operated, then there can be a good to get bashed in a complex application.

The word Redux - bears parts of words reducer and fluxthat reflect the ideology of this library. The architectural solution which provides your bike is neither the first nor the second. Why is your bike called reudx-light XS. Probably because redux in dependencies, and its storage to write, you are powerless and you improperly use someone else's.

the second example withAddTodo you have a great. About your code, then despite what you want to achieve and what parameters to input. - Lenny.Botsfo commented on June 8th 19 at 17:38
I need to minimize code duplication. Here I gave the example of the medium, my reduser a lot more like this

const createAsyncReducer (state, action) => {
 switch (action.type) {
 case "USER_REQUEST":
 return {
...state
 edit: {
...state.edit
 isFetching: true,
}
}
 case "USER_SUCCESS":
 return {
...state
 edit: {
...state.edit
 isFetching: false,
 data: action.payload,
 error: void 0,
}
}
 case "USER_FAILURE":
 return {
...state
 edit: {
...state.edit
 isFetching: false,
 error: the action.payload
}
}
 case "USER_SOME_ACTION":
 return {
...state
 edit: {
...state.edit
 isFetching: false,
 error: the action.payload.some
}
}
 case "USER_REQUEST2":
 return {
...state
 delete: {
...state.delete
 isFetching: true,
}
}
 case "USER_SUCCESS2":
 return {
...state
 delete: {
...state.delete
 isFetching: false,
 data: action.payload,
 error: void 0,
}
}
 case "USER_FAILURE2":
 return {
...state
 delete: {
...state.delete
 isFetching: false,
 error: the action.payload
}
}
 case "USER_SOME_ACTION2":
 return {
...state
 delete: {
...state.delete
 isFetching: false,
 error: the action.payload.some
}
}
 default: return state;
}
}


If I have many such objects (edit, delete, create, load)
delete: {
...state.delete
 isFetching: false,
 error: the action.payload.some
 }


How can they be separate and optimize, reduce code? - Daryl.Sau commented on June 8th 19 at 17:41
, in order:

it is in production in two projects? Do not tell. You wrote this in mid-December.

In mid-December, I decided to write this in odelny module and put it on github / add to npm.

At the same time, this hat doesn't even work.

For this to work, secondly your example add

import createStore from 'redux-light';

I have everything working. If you use require, it is necessary to write so:

var createStore = require('redux-light').default;

Possible in the future to add a module babel-plugin-add-module-exports...

<skip the babble>

1.Why then do redux?

To keep state and automatically update React components as it changes. (for this use react-redux).

2. What types of actions?

Because the library is based on the original redux, they are already there. I could remove the need to add type (and I actually did in the first draft), but each state change there must be a reason that it was much easier debajit, I realized that it is better to leave it. But I have a branch where redux is completely rewritten, and there you can disable. (still under development + react-redux-light)

3. How to get the current status?

Here it is:

let state = store.getState()

Based on your questions and other thoughts can make the conclusion that you do not know what redux is, and what he settles on. After all, you couldn't even cite one real drawback of this library, but they are there (as in the original redux of course). - Jillian.Conn commented on June 8th 19 at 17:44
I imports are not added for simplicity of examples.
5a7307b19f2b0958148102.png
As you can see is, that your hurdy-gurdy and it does not work. Sorry. Not only used function resetState.
I'm developing it stage-0. Your tips on how to run your buggy bike is not the place.

1. You probably do not even understand due to what components are being updated and what is HOC. And because, apparently, their superficial knowledge about the implementation architecture which provides redux, do not even realize that they demolish it.

To update components, you need at least react-redux, which dependencies there. You probably even do not understand the question.

Why are these bikes? Use though window._store interface for mutablenode updates and HOC for component updates, and won't make a difference, but for some reason, you scoff at redux.
And most importantly do not have a clear idea of what you are doing. You probably really want to have the title of your DIY prefix redux.

2. Do you understand? You apparently do not understand. Especially about what they are doing and why. Lord, you are still on the implementation redux mock. Stop.

3. Seriously getState()? And give at the mercy of the developers. pasta ways the entire state object and make the application difficult changeable and badly scaled? As you cases the use of the same key in different parts of the application and for different purposes, redux completely excludes it. And you broke it. Mistakes in paths:
getState().some.path.somePath2.somePath3;
Probably should catch the via stand?
How are you going to scale store?
To rewrite the way throughout the application?
Or pull in your function selectors.
Modularity? Now nothing guarantees that I won't break your keys the old functionality.

Here all the flaws not listed as a violation of the very concept of flux obscures everything else. Above I already wrote about side effects and middleware, scaling, devTools and so on. Most importantly, the state now does not change the dispatch(although under your wrapper it to them), and by the developer, and it destroys everything.

Publish the link on his hurdy-gurdy on reddit and there you will be crucified, and rightly so. - Lenny.Botsfo commented on June 8th 19 at 17:47
, , Thanks for the help, helped!!!! - Daryl.Sau commented on June 8th 19 at 17:50
you for your task it is necessary not HOR to implement a CRUD boilerplate. - Lenny.Botsfo commented on June 8th 19 at 17:53
I need a HOR
Unite in one reducer and make export in stor?
const todosReducer = createAsyncReducer([
"TODOS_REQUEST",
"TODOS_SUCCESS",
"TODOS_FAILURE"
]);
const todosReducer2 = createAsyncReducer([
"TODOS_REQUEST2",
"TODOS_SUCCESS2",
"TODOS_FAILURE2"
]);

const withAddTodo = reducer => (state, action) => {
 const nextState = reducer(state, action);
 switch (action.type) {
 case "ADD_TODO":
 return {
...nextState,
 data: [...nextState.data, action.payload]
};
default:
 return nextState;
}
};

const customReducer = withAddTodo(todosReducer);
// need to customReducer record todosReducer2
- Daryl.Sau commented on June 8th 19 at 17:56
I look at your code and the tears)) and it is necessary such nonsense to do)) About your pointless criticism even speak not want to.

redux it bad that for the sake of simple things need to be subverted. With redux-light would have only to write one helper method and use something like this:

// users.js

async function getUser(id) {
 await helper.load({
 type: 'GET_USER',
 func: () => api.getUser(id)
 rootProp: 'users'
});
}

async function editUser(id, value) {
 await helper.load({
 type: 'EDIT_USER',
 func: () => api.editUser(id, value),
 rootProp: 'users'
});
}


// helpers.js

function async load({ type, func, rootProp, loadingProp = 'isFetching', resultProp='data', errorProp='error' }) {
 if (getState()[rootProp][loadingProp]) return;

setState({
 type: type + '_STARTED',
 [rootProp]: { [loadingProp]: true }
});

 let data;
 try {
 data = await func();
}
 catch (error) {
setState({
 type: type + '_ERROR',
 [rootProp]: {
 [loadingProp]: false,
 [errorProp]: error
}
});
return;
}

setState({
 type: type + '_SUCCESS',
 [rootProp]: {
 [loadingProp]: false,
 [resultProp]: data
}
});
}
- Jillian.Conn commented on June 8th 19 at 17:59
starts, focus has shifted from his hurdy-gurdy is not working in my code.
Yes, I inadvertently did not notice what the author wants and what is contained in todosReducer and todosReducer2, and fundamentally misunderstood the essence of the problem. My mistake, carelessness. Wrote complete crap.

Gone from answering questions that can't give clear answers, consider the leaked conversation.

Your helper is actually under the semblance redux CRUD boilerplate. Which also violates the concept of FLUX.

Besides, during the upgrade, one user works General loadingProp and errorProp, which is wrong. As that key of an entity can have only in the root store.
I would recommend to avoid such solutions and using a full CRUD boilerplate to work with that would be much more convenient than with your hurdy-gurdy.

Let's see how the interface looks normal CRUD generator:
const {
reducer,
saga,
actions
selectors,
api
actionTypes,
} = generateCrudBoilerplate(
'products',
{
 getList: () => `/api/products`,
 getOne: id => `/api/product/${id}`,
 add: payload => `/api/product/`,
 remove: id => `/api/product/${id}`,
 edit: (id, payload) => `/api/product/${id)`,
}
);


Let's see how looks your hurdy-gurdy. Draw your own conclusions. - Lenny.Botsfo commented on June 8th 19 at 18:02
this is just an example which I have thrown in a minute, to make it clear how everything is easier and you can simplify. Shared or not shared loadingProp readily adaptable to need. Moreover, it is seen that the interface and the implementation is simple and flexible.

In the above code, only one absolutely inflexible interface (without implementation) in the most severe vacuum, with a bunch of do not understand why someone needs regenerierung objects.

Actually argue not anymore, their position revealed code showed all yet.

PS. Ah Yes, the very eyes out phrase about the fact that the flux is disturbed, so he is not disturbed. - Jillian.Conn commented on June 8th 19 at 18:05
,
My mistake, carelessness. Wrote complete crap.

As normal to write it??
Come on it HOR - Daryl.Sau commented on June 8th 19 at 18:08
is the interface of the app which is now working. reducer connected to entitiesReducer, saga in rootSaga, selectors are functions of the selectors to select the desired items from a state object, actions - everything is clear, actionTypes and the api optional key which are mostly not used. Implementation can not throw, as it was not written by me, but there is nothing difficult.

There is nothing to argue about. Your decision has the right to life, but not in the "ecosystem" redux as it breaks all of his ideology, namely its implementation of the principle of Flux, and deprived at once of almost the entire instrumentation of a huge ecosystem grew up around redux.
This is a big step back where the modern front end came to the architecture of Flux and its different variations.

About the fact that your solution is not disturbed Flux tell someone else. You either do not understand the ideology, or pretend to. - Lenny.Botsfo commented on June 8th 19 at 18:11
somehow so, if I understand correctly:
import { combineReducers } from 'redux';

const createAsyncReducer = entityName => (state, action) => {
 const { type, payload } = action;

 switch (type) {
 case entityName + '_REQUEST':
 return {
...state
 isFetching: true,
};

 case entityName + '_SUCCESS':
 return {
...state
 isFetching: false,
 data: payload,
 error: null
};

 case entityName + '_FAILURE':
 return {
...state
 isFetching: false,
 error: payload,
};

 default: return state;
}
}

const todoReducer = withTodo(createAsyncReducer('TODO'));
const todoReducer2 = createAsyncReducer('TODO2');

export const customReducer = combineReducers({
todoReducer,
todoReducer2,
});


But here it is necessary to add initialState.
So you don't get the actionTypes.
It is possible to simplify not worth it. Either generate them. - Lenny.Botsfo commented on June 8th 19 at 18:14
Okay, but in this case, you can work with selectors? All slomalos
export const getIsLoadedSelector = ({ reducer }) => reducer.delete.isLoaded;


And you can whether in such a case combineReducers to use multiple times, then there is in the main redusere? - Daryl.Sau commented on June 8th 19 at 18:17
you the task describe clearly that in the end to want, and then talk about HOR, but in the end the desired boilerplate, as HOR you only withTodo.
You would have overthrown your code, not abstract.
Now selectors such as:
export const getIsLoadedSelector = ({ apps }) =>
customReducer.todoReducer.delete.isLoaded;
export const getIsLoadedSelector2 = ({ apps }) =>
 customReducer.todoReducer2.delete.isLoaded;

For selectors use the reselect. This library is implemented memorysize and when the status changes on the same will not be superfluous calls.
combineReducers can be used indefinitely.

Throw your current code and clearly describe the objective, it is clear that you better advise. - Lenny.Botsfo commented on June 8th 19 at 18:20

Find more questions by tags JavaScriptReduxReact