Develop Reference

Updating child array in reducer using React Context

I am doing some filtering using React Context and I am having some difficulty in updating a child's array value when a filter is selected.
I want to be able to filter by a minimum price, which is selected in a dropdown by the user, I then dispatch an action to store that in the reducers state, however, when I try and update an inner array (homes: []) that lives inside the developments array (which is populated with data on load), I seem to wipe out the existing data which was outside the inner array?
In a nutshell, I need to be able to maintain the existing developments array, and filter out by price within the homes array, I have provided a copy of my example code before, please let me know if I have explained this well enough!
export const initialState = {
priceRange: {
min: null
},
developments: []
};
// Once populated on load, the developments array (in the initialState object)
// will have a structure like this,
// I want to be able to filter the developments by price which is found below
developments: [
name: 'Foo',
location: 'Bar',
distance: 'xxx miles',
homes: [
{
name: 'Foo',
price: 100000
},
{
name: 'Bar',
price: 200000
}
]
]
case 'MIN_PRICE':
return {
...state,
priceRange: {
...state.priceRange,
min: action.payload
},
developments: [
...state.developments.map(development => {
// Something here is causing it to break I believe?
development.homes.filter(house => house.price < action.payload);
})
]
};
<Select onChange={event=>
dropdownContext.dispatch({ type: 'MIN_PRICE' payload: event.value }) } />

You have to separate homes from the other properties, then you can apply the filter and rebuild a development object:
return = {
...state,
priceRange: {
...state.priceRange,
min: action.payload
},
developments: state.developments.map(({homes, ...other}) => {
return {
...other,
homes: homes.filter(house => house.price < action.payload)
}
})
}

Reducer - add new element

I have this store:
const initialActors = {
list: 'Actor\'s lists',
actors: [
{
name: 'Angelina Jole',
involved: true
},
{
name: 'Bratt Pitt',
involved: false
},
]
}
I have a reducer to add a new actor to my store:
const actors = (state = initialActors, action) => {
switch(action.type){
case 'ADD_NEW':
return {
...state.list,
actors: [
...state.actors,
action.name,
action.involved
]
}
default:
return state
}
}
I have a action creator too but it doesn't important. I dispatch that and display my state:
store.dispatch(addNew({name: "Hello", involved: true}) ); // I have this action creator
console.log(store.getState()
console.log displays very difficult object with letters like: {0: "A", 1: "c"}. What is wrong?
#Edit
I tryed change ...state.list to state list like this:
const actors = (state = initialActors, action) => {
switch(action.type){
case 'ADD_NEW':
return {
state.list,
actors: [
...state.actors,
action.name,
action.involved
]
}
default:
return state
}
}
but I have this error:
Parsing error: Unexpected token, expected ","
Similiar situation I have if I tryed modify actors array:
case 'ADD_NEW':
return {
...state.list,
actors: [
...state.actors,
{
action.name,
action.involved
}
]
}
Error message is this same but point at action object (action.name).

In your reducer, you are mistakenly spreading state.list. Since it is a string, you are getting all the letters. You should spread the state there. Because, you want to keep your state, other than actors array. This is why you spread the whole state and keep the list (with others if there would be).
Also, you are adding your item wrong, it should be an object.
const actors = (state = initialActors, action) => {
const { name, involved } = action;
switch (action.type) {
case "ADD_NEW":
return {
...state,
actors: [
...state.actors,
{
name,
involved
}
]
};
default:
return state;
}
};

state.list is a string, and you are trying to spread it
let a = 'name'
let c = {...a}
console.log(c)
run the above code snippet so you will be able to understand it
and for adding new object you need to update the reducer as follows
...state,
actors: [
...state.actors,
{
name: action.name,
involved: action.involved
}
]
so the above code will spread all the existing properties in the state and then you spread all the current actors and add a new object as shown above
Update
Since you are passing as
store.dispatch(addNew({name: "Hello", involved: true}) );
here the payload is an object so you can directly use that one
so in action it will be object which has two props one is
type
the payload you have send it
...state,
actors: [
...state.actors,
action.payload
]
Sample Working codesandbox

Just a small mistake what you did, you need to add as an object with 2 properties like [...state.actors, { action.name, action.involved }] instead of what you did.
From Spread syntax's documentation:
Spread syntax allows an iterable such as an array expression or string to be expanded in places where zero or more arguments (for function calls) or elements (for array literals) are expected, or an object expression to be expanded in places where zero or more key-value pairs (for object literals) are expected.
Like this:
const actors = (state = initialActors, action) => {
switch(action.type){
case 'ADD_NEW':
return {
...state,
actors: [
...state.actors,
{
name: action.name,
involved: action.involved
}
]
}
default:
return state
}
}
Consider the following:
var array = [
{
name: 'someone',
involved: false,
}
];
console.log([...array, { name: 'hello', involved: true }]);
I hope this helps!

Access the state in an action in redux

Many links and tutorials advice to group the logic in action creators in order to simplify the reducer logic.
Imagine a simple (normalized) state:
const initialState = {
parent: {
allIds: [0],
byId: {
0: {
parentProperty: `I'm the parent`,
children: [1, 2]
}
}
},
children: {
allIds: [1, 2],
byId: {
1: {
childrenProperty: `I'm the children`
},
2: {
childrenProperty: `I'm the children`
}
}
}
}
I would now delete the parent. Since only the parent refers to the children, I would also delete the children too.
I imagine a action creator like this:
function deleteParents(parentId) {
return {type: 'DELETE_PARENT', payload: {parentId}};
}
and
function deleteChild(childId) {
return {type: 'DELETE_CHILD', payload: {childId}};
}
For now, to manage this case I do something like this (with redux-thunk)
function deleteParentAndChildren(parentId) {
return (dispatch, getState) {
const childrenIds = myChildrenSelector(getState(), parentId);
const deleteChildrenActions = childrenIds.map(deleteChild);
const deleteParentAndChildrenAction = batchActions([
deleteParents(parentId),
...deleteChildrenActions
], 'DELETE_PARENT_AND_CHILDREN');
dispatch(deleteParentAndChildrenAction);
}
}
In that way, I compose little action into big one, and the reducer logic is very simple because it only consist to delete a key in an object.
Conversely, I don't like to use redux-thunk (used to async actions) just to get the state (and this is considered as anti pattern).
How do you guys manage this type of problems ?
Does a tool like redux-sage may help ?

The problematic you seem to have seems fairly common and if your application is a bit sophisticated I would suggest using redux-orm which is a bit hard to understand and then integrate but once set up it just abstract you all the hard relationship work between your entities.

I opine differently here. The way I would do it is, I would delete child while deleting parent but not y dispatching child_delete action. When you create new state while deleting parent in reducer, at that time, you can access the children referred by that parent, and remove those as well from state.
Also, if you still want to dispatch actions separately, you can pass childids from component to action. From that action, you can dispatch two different actions, deleting parent and chilren ids.
----------- EDIT -------
// The initial application state
const initialState = {
parent: {
allIds: [0],
byId: {
0: {
parentProperty: `I'm the parent`,
children: [1, 2]
}
}
},
children: {
allIds: [1, 2],
byId: {
1: {
childrenProperty: `I'm the children`
},
2: {
childrenProperty: `I'm the children`
}
}
}
}
export default function batchManagement(state = initialState, action) {
switch (action.type) {
case 'DELETE_PARENT': //assuming action.deleteParents = [0]
//Here you have access to state, so you can change parents and children as well, and create a totally new state
case 'DELETE_CHILDREN':
//Return a new object for state
default:
return state;
}
}

Redux normalizr + dealing with reduced responses

Normalizr is great at creating structured JSON repositories of entities.
We have many cases displaying lists of data e.g. posts that have been normalised. Where posts are listed the API response is limited to a few key fields.
We also have cases where we display one of these posts although we now need to fetch the FULL JSON entity from the API with all the fields.
How is it best to deal with this?
A a seperate reducer, thunk/saga, selectors and actions?
B simply insert the extended version of thepost fetched from the API into the reducer. Reusing the selectors etc from before?

Think of the app's state as a database. I suggest you to use this state shape:
{
entities: {
// List of normalized posts without any nesting. No matter whether they have all fields or not.
posts: {
'1': {
id: '1',
title: 'Post 1',
},
'2': {
id: '2',
title: 'Post 2',
}
},
},
// Ids of posts, which need to displayed.
posts: ['1', '2'],
// Id of full post.
post: '2',
}
First of all, we are creating our normalizr schemas:
// schemas.js
import { Schema, arrayOf } from 'normalizr';
const POST = new Schema('post');
const POST_ARRAY = arrayOf(POST);
After success response, we are normalizing response data and dispatching the action:
// actions.js/sagas.js
function handlePostsResponse(body) {
dispatch({
type: 'FETCH_POSTS',
payload: normalize(body.result, POST_ARRAY),
});
}
function handleFullPostResponse(body) {
dispatch({
type: 'FETCH_FULL_POST',
payload: normalize(body.result, POST),
});
}
In reducers, we need to create entities reducer, which will be listening all actions and if it has entities key in payload, would add this entities to the app state:
// reducers.js
import merge from 'lodash/merge';
function entities(state = {}, action) {
const payload = action.payload;
if (payload && payload.entities) {
return merge({}, state, payload.entities);
}
return state;
}
Also we need to create corresponding reducers to handle FETCH_BOARDS and FETCH_FULL_BOARD actions:
// Posts reducer will be storing only posts ids.
function posts(state = [], action) {
switch (action.type) {
case 'FETCH_POSTS':
// Post id is stored in `result` variable of normalizr output.
return [...state, action.payload.result];
default:
return state;
}
}
// Post reducer will be storing current post id.
// Further, you can replace `state` variable by object and store `isFetching` and other variables.
function post(state = null, action) {
switch (action.type) {
case 'FETCH_FULL_POST':
return action.payload.id;
default:
return state;
}
}

I agree with both of your two choices and would have come to the same conclusion. But let's have a closer look at them to see an advantage form one over the other:
(B) You can merge the post entities (preview and full representation) as one entity in your reducer, but you would keep track of the result arrays (preview and full representation), which you would get from the normalizr normalized data after the API requests. Then you can easily distinguish afterwards, if you already have the full representation of the post. Your sub-state might look like the following:
const postState = {
// merged results from PREVIEW api
previews: [1, 2, 3],
// merged results from FULL api
full: [2],
// all merged entities
entities: {
1: {
title: 'foo1'
},
2: {
title: 'foo2',
body: 'bar',
},
3: {
title: 'foo3'
}
}
};
(A) You would have two reducers + actions, one for each representation, to distinguish the entities. Depending on the PREVIEW or FULL posts API request, you would serve one of your reducers via one explicit action. Your sub-states might look like these:
const previewPostState = {
// merged results from PREVIEW api
result: [1, 2, 3],
// all preview entities
entities: {
1: {
title: 'foo1'
},
2: {
title: 'foo2',
},
3: {
title: 'foo3'
}
}
};
const fullPostState = {
// merged results from FULL api
result: [2],
// all full entities
entities: {
2: {
title: 'foo2',
body: 'bar'
}
}
};
From a very high level perspective you can already see that you would have to save duplicated information. The post entity with id: 2 would be saved two times with its title property: one time for previewPostState and one time for fullPostState. Once you want to change the title property in your global state, you would have to do it at two places. One would violate the single source of truth in Redux. That's the reason I would go with choice (B): You have one place for your post entities, but can distinguish clearly their representations by your result arrays.

Redux see other state from Reducer

Imagine a UI with two React components:
<FilterContainer />
<UserListContainer />
We pull down an array of users from the server:
[
{
name: 'John',
enjoys: ['Sailing', 'Running']
},
{
name: 'Bob',
enjoys: ['Running', 'Eating']
},
{
name: 'Frank',
enjoys: ['Sailing', 'Eating']
}
]
The UI looks a little like this:
Filter: Sailing Running Eating
UserList:
John
Frank
You can click on either a filter or a user. To get to this stage, we've clicked on 'Sailing' and then on 'Frank' (maybe we see a nice photo of Frank in the middle of the screen).
My Redux state, built using combineReducers, looks like this:
{
ui: {
filter: {enjoys: 'Sailing'},
userList: {selected: 'John'}
}
data: [user array]
}
I have two actions, SELECT_USER and SELECT_FILTER.
When I click on a filter (SELECT_FILTER fires), I want the ui.userList.selected to persist if that user is still in the filter, and the ui.userList.selected to be set to null if the user is not in the filter.
So if I now click on Eating, I'll see a list with Bob and Frank in it, and Frank is selected. But if I click on Running, I'll see John and Bob, but neither are selected.
However I'm struggling to do this in the conventional Redux methodology. When the userList reducer sees the SELECT_FILTER action, there's no way for it to check the data state to see if the currently selected user is still in that filter condition or not.
What's the right way to do this?
function filter(state = {enjoys: null}, action) {
switch (action.type) {
case SELECT_FILTER:
return {
...state,
enjoys: action.enjoys
}
default:
return state
}
}
function userList(state = {selected: null}, action) {
switch (action.type) {
case SELECT_USER:
return {
...state,
selected: action.name
}
default:
return state
}
}
const ui = combineReducers({
filter,
userList
})
let initialUsers = [
{
name: 'John',
enjoys: ['Sailing', 'Running']
},
{
name: 'Bob',
enjoys: ['Running', 'Eating']
},
{
name: 'Frank',
enjoys: ['Sailing', 'Eating']
}
]
const rootReducer = combineReducers({
ui,
data: (state=initialUsers) => state // in reality, loaded from server
})
export default rootReducer

Reducer should be aware only of a small part of state.
Good place for described logic is the action creator. With redux-thunk you will be able to make a decision based on a global state.
function selectFilter(enjoys) {
return (dispatch, getState) => {
dispatch({type: SELECT_FILTER, enjoys});
// if getState().ui.userList.selected exists in getState().data
dispatch({type: SELECT_USER, name: null});
}
};

You need another action for this.
If you are filtering the users in the data reducer, you will need to dispatch an action in one of your components' hooks (componentWillUpdate or componentWillReceiveProps) when you detect that the array of users has changed. This action will provide your filter reducer with the current array of users, and there you can set the selected field as you like.
If you are filtering the users in the server, I guess you already have an action like FETCH_USERS_SUCCESS that you can use for this.

It should be handled by the filter reducer. You need to send the users data as part of the action payload. Hence the reducer could Calc the selected user logic. You should consider adding a new action, as #cuttals suggested.