I'm becoming a bit confused about how to update state in NgRx reducer, here is the question.
Say I have a state
{
xxx: num
yyy: classtpe
...
data: Data[]
}
If I have an action to add a Data item to the list.
I know I can't call data.push() because that just update the array but data pointing to same array so in the reducer I have
state.data = cloneDeep(state.data)
state.data.push(newdata)
so state.data now is different from previous one because they are 2 individual arrays.
my question is, can I return state directly now? If yes then the old and new states point to same variable, they have exactally same members except data.
The other way is, return a brand new state like
return Object.assign({}, state, {
data: [...state.data, newdata]
})
or
const newstate = cloneDeep(state)
newstate.data.push(new data)
return newstate
this way new and old state are totally different.
I think it's actually related to how difference is checked in NgRx? first way they need to go through each memeber, if any member is different then the state is differnet?
2nd way the 2 states are different, but all the memebers need to be checked to see if contents are same.
I would recommend you to use ngrx-immer, https://github.com/timdeschryver/ngrx-immer
It's an Immer wrapper around ngrx reducers so you can update all of the state mutably, and it will do the rest for you. Immer is also used in the redux-toolkit to make it simple to update state.
Related
Does it exactly mean treating it as "read-only"?
For example, if the state is:
{
arr: arrData,
obj: objData,
aMap: mapData,
aSet: setData
}
For any of the four that has no change to it, we can keep it as is, but let's say 3 level down obj, which is obj.b.c.d, and this d refers to an array, and we need to modify one entry in the array, then we need to make a copy of that array, modify the entry, and let the new state refer to it? But if d refers to a new array, then c needs to have a new d, so c needs to be a new object, and for the same reason, we need a new b, eventually, a new obj?
So it is
let objNew = {
...obj,
b: {
...obj.b,
c: {
...obj.b.c,
d: [...obj.b.c.d]
}
}
};
objNew.b.c.d[someIndex] = someNewValueOrObj;
And now objNew can be returned and the old state was not modified in any way (was reading it only).
So if prevState was the old state, and state is the new state, we just need to make sure right before we return the new state, for prevState, if we were to dump all the values out, it stayed the same as what was passed in, while the new state would dump out the values for our new state.
Redux uses shallow equality to check whether the state has changed to trigger a render in React. If the references to the new state and the previous are the same, i.e. === returns true, Redux considers nothing has changed and simply returns from the reducer.
You will have to produce a new state value that is referentially different to the old one no matter how deep down in your state a value has changed.
I would suggest you consider using a library like immer to help you with that in an efficient way.
Is there any inconvenient at all if I design my reducers to, instead of reading only the partial state, had access to the full state tree?
So instead of writing this:
function reducer(state = {}, action) {
return {
a: doSomethingWithA(state.a, action),
b: processB(state.b, action),
c: c(state.c, action)
}
}
I destructure state inside doSomethingWithA, c or processB reducers, separately:
function reducer(state = {}, action) {
return {
a: doSomethingWithA(state, action), // calc next state based on a
b: processB(state, action), // calc next state based on b
c: c(state, action) // calc next state based on a, b and c
}
}
Would I'd be using more RAM? Is there any performance inconvenient? I understand that in javascript, a reference is always passed as parameter, that's why we should return a new object if we want to update the state or use Immutable.JS to enforce immutability, so... again, would it be of any inconvenient at all?
No, there's nothing wrong with that. Part of the reason for writing update logic as individual functions instead of separate Flux "stores" is that it gives you explicit control over chains of dependencies. If the logic for updating state.b depends on having state.a updated first, you can do that.
You may want to read through the Structuring Reducers section in the Redux docs, particularly the Beyond combineReducers topic. It discusses other various reducer structures besides the typical combineReducers approach. I also give some examples of this kind of structure in my blog post Practical Redux, Part 7: Form Change Handling, Data Editing, and Feature Reducers.
I wanted to implement an LRU for a react-redux application, however I'm not sure what the best strategy of reading and writing data to the store via reducer so that I can maintain the LRU structure.
The goal is to implement an LRU for a most recent list of users. Effectively, whenever the application click on a specific contact, they get added to the most recent list of users. Let's say the list max out at 10 users, so effectively when it hit the max i'll pop off the oldest access user on the list.
I could associate a timestamp for each user in the list, but that means every time I read the state from the store, I would have to sort and find the oldest time stamp which i feel is slow.
I'm new to React/Redux, so please bear with me.
Any suggestions appreciated!
Thanks,
Derek
I would just have a seperate reducer that acts on the "select contact" action (there is probably another reducer that will also act on to set the currently selected user). It will maintain the array and just push to the front, and if the max is reachers, pop off the end.
Something like:
const initialState = []
export const lruReducer = (state = initialState, action) => {
switch(action.type) {
case 'SELECT_CONTACT':
// copy the previous array (I'm assuming ES6 syntax here, but you could use Object.assign or ImmutableJS or something if preferred)
// this is important to keep the state immutable
let newState = [...state]
// add the new contact (this is where you would do any de-duping logic
newState.unshift(action.user)
// keep removing items until constraint is met
while (newState.length > 10) {
newState.pop()
}
// return new array
return newState
default:
return state
}
}
Then just combine this with your other reducers like normal.
I'd like to know how to handle specific use case with redux reducer. To give an example, say I have a form with a DataGrid/Table. On Edit button click from a row, I want to open the popup with seleted row-data. After editing the data, On Popup-Submit button click, I want to update the Table/DataGrid (i.e. DataGrid will now should have the edited values).
I've written two separate Components
1. MainPage.js and its corresponding reducer MainPageReducer (Employee List)
2. PopupPage.js and its corresponding reducer PopupPageReducer (Selected Employee)
How these two reducers share the state?
You may need to read this first
http://redux.js.org/docs/basics/UsageWithReact.html
The main concept is that through the connect function, you would simply map needed properties of your state to the properties of your component i.e MapStateToProps. So in your case, imagine that your state, for contrived purposes, is structed like so:
{employees: {employees: {1: {id: 1, name: 'Foo'}}, editedEmployeeId: 1}
You could map the array of employees to an employees property for your EmployeeList component whilst also mapping a dispatch function, named editEmployee(id) to a click function on each row in the table.
You could map [the employee with the associated editedEmployeeId] to the individual employee in your employees array for your popup component
It may be efficient to just use one reducer instead of two.
Specifically, if you're making an update to an individual employee then you would call an EDIT_EMPLOYEE action and then a SAVE_EMPLOYEE action on save. After the SAVE_EMPLOYEE action, then, I assume, you'd call a post method, and then react-redux would re-render your entire list.
It could look like this:
function employees(state = {editedEmployeeId: undefined, employees = []}, action) {
switch(action.type) {
case EDIT_EMPLOYEE:
return Object.assign({}, state, {editedEmployee: action.employee_id})
case SAVE_EMPLOYEE:
return Object.assign({}, state, {employees: action.employees});
default:
return state;
}
}
There are great holes in my answer because the question you're asking might be too broad; I'm presuming you don't fully understand how the connect, subscribe, and dispatch functions work.
Like one of the comments said, reducers don't share state. They simply take the previous version of your state and return another version of it.
Anyways, hope this helps. Read the redux docs!
I use immutable.js to keep my application state. It's made of multiple combined reducers, that are immutable maps like:
const initialState = new Map({
data: null,
page: 1,
...
});
So I have a request response I need to fetch, save somewhere, get data from, and update the state, whenever something on the webpage changes.
The question is - where do I keep raw request responses in redux?
Let's say, I want to keep it inside the state. I tried the following approaches:
case FETCH_RESPONSE:
return state.merge({
rawRequestResponse: action.response // very slow, deep conversion to Immutable
})
case FETCH_RESPONSE:
return state.set({
rawRequestResponse: action.response // also slow, it's converted to Immutable, though not deeply
})
case FETCH_RESPONSE:
return new Map({
rawRequestResponse: action.response, // just like above
...
})
But they all are too slow. What's the best way to do this?
Not sure about passing a plain object to set(), but if you pass the key as a string, then the value as the second argument, nothing should be converted:
return state.set('rawRequestResponse', action.response)