Following the example on the reselect docs:
import { createSelector } from 'reselect'
const shopItemsSelector = state => state.shop.items
const subtotalSelector = createSelector(
shopItemsSelector,
items => items.reduce((acc, item) => acc + item.value, 0)
)
In a typical redux app, subtotalSelector will recompute if a user updates item.name, even though this has no impact on the result. Is there a way to avoid this?
Two solutions:
Let it be. Unless you have a large number of items, the browser's computing capacity is well enough to handle the recompute.
Seperate prices from the item object. That is, you have state.shop.items.itemNames(containing id-name pairs) and state.shop.items.itemValues(containing id-value pairs). Then only the itemValues is passed to the selector.
I have a similar problem and I have found a sort of hack to get arround it.
I have a complex set of filters, and a huge number of items to filter through. Part of the filter state includes display state. I want to ignore changes in the display state so I don't filter a huge list all the time. This is an easy-ish solution:
const getFilters = createSelector(
state => state.filters,
filters => {
const filtersWithoutDisplay = {};
const ignoreObj = { collapsed: null };
for (let filterGroup in filters) {
filtersWithoutDisplay[filterGroup] = Object.assign({}, filters[filterGroup], ignoreObj);
}
// We create a new object every time, so this cannot be memoized properly unless we stringify.
return JSON.stringify(filtersWithoutDisplay);
}
);
It returns a JSON string that has to be parsed, but it's a primitive so as an input to another selector it doesn't trigger a recomputation if the actual contents don't change. That's kind of a hack.
You could also define an object outside of the selector function and always keep the same reference, change the insides according to this same patter, and then use a custom deep equality check by pulling in createSelectorCreator, as explained here https://github.com/reactjs/reselect#q-why-is-my-selector-recomputing-when-the-input-state-stays-the-same . This is probably a better way to go, but as it says:
Always check that the cost of an alternative equalityCheck function or deep equality check in the state update function is not greater than the cost of recomputing every time.
That goes for the JSON.stringify hack as well. I wouldn't do it for the huge list, but for the filters, sure.
In my situation, it's probably better to refactor my state because the filter values may be a separate concern from the filter display settings, and this may not be the only time I want them separate.
Related
I am learning Redux Toolkit. From a React POV it seems very intuitive to access whatever part of the state you need from within useSelector using an inline arrow function, and then conduct any calculations. As an example consider a cart item with its data (like item count) in redux store.
function CartItemCounter({ itemId }){
const cart = useSelector(state => state.cart);
const itemInCart = cart.items[itemId];
const count = itemInCart?.count || 0;
return <div>{itemId} - {count} nos</div>
}
But I'm seeing all this information saying you should define your selectors beside your slice, use createSelector and all. What is the right way, and why is it better?
The information that is out there is essentially talking about different levels of optimization while using useSelector.
What you need to understand before anything else, is how useSelector works internally.
How does useSelector work?
When you pass a function to useSelector (obviously inside a react component), it essentially hooks on to the global redux state. Whenever any change happens in any part of the global state (i.e. when dispatch() is called from any part of the app), redux will run all the functions you passed to useSelector in your app, and perform certain checks.
Redux will take the result from each function, and compare it to the value it got the last time it ran the same function.
How does it make this comparison?
It uses a reference equality for this comparison. So if redux has to think that the result of the function hasn't changed, either the value returned from the function has to be a primitive and equal.
4 === 4 // true
'itemA' === 'itemA // true
Or, the value returned must be a derived data type (arrays, objects), with the same reference. So essentially the same object.
const x = { name: 'Shashi' }
const fn1 = () => x;
const fn2 = () => x;
const fn3 = () => { name: 'Shashi' }
fn1() === fn2(); // true
fn1() === fn3(); // false, because the objects are different, with different references
In practice, redux changes the wrapping object if either a key (or key of a nested object) is changed, or you manually change the entire object using a dispatch action (This is related to the immer library integration). This is similar to how you would do in regular React.
/* See how most keys are spread in, and will hence maintain reference equality.
While certain keys like 'first', 'first.second', 'first.second[action.someId]'
are changed with new objects, and so will break reference equality */
function handwrittenReducer(state, action) {
return {
...state,
first: {
...state.first,
second: {
...state.first.second,
[action.someId]: {
...state.first.second[action.someId],
fourth: action.someValue,
},
},
},
}
}
Otherwise it maintains the same objects within its state, and returns the exact same objects with the same references, when you access them. To verify this, if you access your cart twice, its literally going to be the same object.
const cart1 = useSelector(state => state.cart)
const cart2 = useSelector(state => state.cart)
cart1 === cart2; // true
What does it do with this comparison?
If the comparison returns true, i.e. the new value is the same as the old value, Redux tells that instance of useSelector to chill tf out, and not do anything. If it returns false however, it tells that component to re-render. After all, the value you are accessing from state has "changed"(according to Redux laws), so you probably want to show the new value.
With this information, we can make change the kind of function we pass to the useSelector, in order to get certain optimization benefits.
Optimization Levels
Level 0: Accessing slice data inline
const cart = useSelector(state => state.cart)
// extract the information you need from within the cart
const itemInCart = cart.items[itemId];
const count = itemInCart?.count || 0;
This is not a good way to access the data. You actually need a subset of the data from the cart, but you are fetching the whole thing, and doing the calculation outside the selector.
Problems:
When you put stuff like this inline, what happens if you change the shape of your data in the future? You have to go to every place that uses useSelector and manually change it. Not so good.
More importantly, every time any part of the cart changes, the entire cart object actually changes. So Redux sees your component that asks for the cart, and thinks
The cart has changed. This component is asking for the cart. It should probably re-render.
BAM Every single instance of this component rerenders. And for what? The count of the item you're referencing probably didn't change. So ideally there shouldn't have been a re-render.
Level 1: Centralize the selector
An easy optimization is to put the selector function in a centralized location next to your slice. That way, if your data shape changes in the future, you can just change it in one place, and your whole app (wherever it uses that data) will work with the new shape.
// inside or next to the slice file
const selectCart = (state) => state.cart
//...
// somewhere inside a react component
const cart = useSelector(selectCart)
Level 2: Access the relevant data
Since redux is comparing the results of your selector function, if you want to avoid unnecessary rerenders, you want to make sure the results have reference equality (===). So target the exact value you wish to look at, in your selector.
// extract the information you need from within the cart, *within the selector*
const count = useSelector(state => state.cart.items[itemId]?.count || 0)
// You don't have to use a one-liner, a multi-line function is better for readability
When Redux executes these functions, it keeps a record of the value returned from these selector functions, for each individual useSelector. This time the values are going to be the same for every single counter, except the one that actually changed. All those other counters that didn't actually change in value don't have to unnecessarily re-render anymore!
And if any of you folks think this is premature optimization, the answer's no. This is more along the lines of putting a dependancy array on your useEffects to avoid infinite loops.
Not forgetting the Level 1 optimization, we can also extract this function centrally
const selectItemById = (state, itemId) => (state.cart.items[itemId]?.count || 0);
function CartItemCounter({ itemId }){
//...
// somewhere inside a react component
const count = useSelector((state) => selectCart(state, itemId))
//...
}
So that solves all of our problems right?
For now, yes. But what if this selector function has to run some expensive computation.
const selectSomething = (state) => reallyExpensiveFn(state.cart)
//...
// somewhere inside a react component
const cart = useSelector(selectSomething)
You don't want to keep running that do you?
Or what if you have no option but to return new objects from your select function. A common scenario for this case would be returning a subset of data from the state.
const selectFilteredItems = (state) => state.itemsArray.filter(checkCondition) // the filter method will always return a new array
//...
// somewhere inside a react component
const cart = useSelector(selectFilteredItems) // re-renders every time
To solve this you would have to memoize or cache the results from the function call. Essentially you would need to make sure that if the input arguments are the same, the result will maintain reference equality with the previous result. This introduces the need to maintain some kind of cache state.
Level 3: createSelector
Fortunately, Reselect library, which is reexported with Redux Tookit, does this work for you. You can take a look at the redux toolkit for the syntax.
const selectFilteredItems = createSelector(
(state) => state.itemsArray, // the first argument accesses relevant data from global state
(itemsArray) => itemsArray.filter(checkCondition) // the second parameter conducts the transformation
)
//...
// somewhere inside a react component
const cart = useSelector(selectFilteredItems) // re-renders only when needed
Here the second function is called the transformation function, and is where we put the expensive computation, or the function that returns inconsistent references as a result (filter,map etc).
The createSelector caches
a) the arguments to the transformation function
b) the result of the transformation function
of the previous call to the selectFilteredItems function. If the arguments are the same, it skips executing the transformation function, and gives you the result you got the last time it was executed.
So when useSelector looks at the result, it gets reference equality. Hence the re-render is skipped!
One little caveat here is that createSelector only caches the very previous result. This makes sense if you think about a single component. In a single component you are only concerned about differences in values and results compared to the previous render. But in practice, you are likely to share selectors across multiple components. If this happens, you have a single cache location, and multiple components using this cache. i.e. Stuff breaks.
Level 4: createSelector factory function
Since the logic for your selector is the same, what you need to do is run createSelector for each component that uses it. This creates a cache for each component, giving us the desired behaviour. In order to do this, we use a factory function.
const makeSelectFilteredItems = () => createSelector(
(state) => state.itemsArray, // the first argument accesses relevant data from global state
(itemsArray) => itemsArray.filter(checkCondition) // the second parameter conducts the transformation
)
//...
// somewhere inside a react component
const selectFilteredItems = useMemo(makeSelectFilteredItems,[]); // make a new selector for each component, when it mounts
const cart = useSelector(selectFilteredItems) // re-renders only when needed
You intend to make a new selector (and by extension, cache) for each new component that mounts. So you put it inside the actual component function and not on the module scope. But this will re-run makeFilteredSelector for each render, and hence create a new selector for each render, and hence eliminate the cache. This is why you need to wrap the function in a useMemo with an empty dependency array. It runs on every mount.
And voila!
You now know where, why and how to use selectors in Redux. I personally feel that the createSelector syntaxes are slightly contrived. There is some discussion on changing cache sizes going on. But for now I feel that sticking to the docs should get you through most situations.
But I'm seeing all this information saying you should define your selectors beside your slice, use createSelector and all.
That's the way to go if you're deriving something from the state, which ends up being an expensive computation or something that's reused often throughout your app. Imagine, for example, your state.cart can contain 50.000 items and you need to sort them from most expensive item to least expensive. You don't want to re-calculate this all the time because it slows your app down. So you cache/memoize the result.
What is the right way, and why is it better?
The right way is to use memoization helpers like createSelector when/if you want to avoid expensive computation. Most people optimize prematurely, so I'd just stick to useSelector and keep it simple if in doubt.
I have a list of cards which I want to filter/sort, using 4 different select / input fields.
For 3 of the 4 filters, things work great. Cards are successfully filtered and sorted, and the filters can be combined with no problem.
On the first one though, I have to click it twice, or click it once then activate another filter, to see the changes in my cards.
I do not understand why this particular filter does not trigger the rerender of the cards because like all the others filters, its value is updated in the state, which looks like this :
const [filters, setFilters] = useState({
orderByFilter: null, // doesn't work the first time
titleFilter: null,
dateFilter: '',
searchFilter: '',
});
What I did to address the asynchronous state update is that I watch from changes in filters in a useEffect hook, to update the filtered data. Again, works fine for the other 3 filters.
useEffect(() => {
setFilteredData(filterCards(dataCards, filters));
// forceUpdate();
}, [filters]);
I am able to make it work for the 4 filters when I trigger a force update after setFilteredData :
const forceUpdate = React.useReducer(() => ({}), {})[1] as () => void;
But it feels like a hack to me and shows that I didn't understand what the real problem is.
Is there a way to make this work without this force update ?
PS : Edited the code to avoid indexation by search engines, as this is semi-sensitive data.
I think the issue here is that for the order filter you're using sort, which sorts the array in place, so in the end you get the same array, but with sorted values, which doesn't get picked up by React as a change, i.e. does not trigger a render. To fix this, when initialising the filter array, try using it's copy:
let filteredArray = [...valueListCards];
Also the approach of saving the filtered data to state is not optimal, as it results in these kinds of bugs, plus you need to keep the state in sync with the actual data. A better idea would be to derive the state, which is basically applying the filters at render.
I'm trying to use some kind of memoization in my workflow with React, and I'm searching for the best and most importantly the "easiest" solution to integrate with my workflow that includes React and Redux.
I came across many articles talking about memoization in general and some demonstrate the use of "memoize-one" and brace it as the fastest and easiest to get up and running with, and others don't even mention it and talk about "reselect".
I just want to know which is better and easiest and which should I invest in.
Both libraries return a function which accepts a given numbers of arguments and returns a value:
getA(arg1, arg2, arg3) // Returns a value
The difference lays in what happens under the hoods when the function is called.
memoize-one
collect provided arguments
compare arguments with the ones provided in previous call (===)
arguments are the same: return cached result
arguments are NOT the same: re-evaluate result function and return
reselect
collect provided arguments
run a set of inputSelectors function providing them with the collected arguments
collect inputSelectors return values
compare inputSelectors return values with the ones obtained in previous call (===)
values are the same: return cached result
values are NOT the same: re-evaluate result function and return
Conclusions
memoize-one is a value-based memoize utility: memoization is performed over the value of provided arguments.
reselect adds a further evaluation layer on top of it: memoization is NOT performed over arguments values BUT over the results of a set inputSelectors functions fed with those initial arguments.
It means that reselect selectors are easily composable since each inputSelectors can be another reselect selector.
I haven't used reselect, but memoize-one works great for me when I want to calculate something from props inside render. This is a great pattern for doing an expensive operation, like mapping a large array, on props that may change over time but also may not change on some re-renders. It ensures an expensive operation used in render is re-computed only when the inputs change. It also avoids having to use lifecycle methods like getDerivedStateFromProps (if it can be calculated from props, it probably shouldn't be on state).
import memoize from 'memoize-one'
class Example extends Component {
mapList = memoize(
(list) => list.map(item => ({text: item.text}))
)
render() {
// if this.props.list hasn't changed since the last render
// memoize-one will re-use the last return value from cache
const mappedList = this.mapList(this.props.list)
return (
...
)
}
}
Keep in mind, in most cases, you’ll want to attach the memoized function to a component instance vs. using a static class variable. This prevents multiple instances of a component from resetting each other’s memoized keys.
react memoization reactjs
I suggest to use reselect, since it was specifically designed to use with React/Redux. memoize-one is more like a general purpose memoization library.
It's really easy to use reselect, it just wraps your selectors:
import { createSelector } from 'reselect';
const shopItemsSelector = state => state.shop.items;
// without reselect
const subtotalSelector = state => {
const items = shopItemsSelector(state);
return items.reduce((acc, item) => acc + item.value, 0);
}
// with reselect
const subtotalSelector = createSelector(
shopItemsSelector, // list the selectors you need
items => items.reduce((acc, item) => acc + item.value, 0) // the last argument is actual selector
)
I'm starting to see performance problems and trying to optimize it.
As a first step, I'm dealing with Perf.printWasted()
That is I'm trying to eliminate unnecessary renders.
One of my component is being rerendered because of two props
a new date object.
newly created [todo] array
Suppose you are creating a calendar for todo.
For each date, I'm passing a date, and list of todos which are due that day.
I'm doing something like (simplified)
todoForDay = _.filter(todos, (todo) => {return todo.dueDate == today})
react's shallowEqual wouldn't see those two cases as equal, how should I proceed?
For #1, I could think of passing moment(date).format() as props and converting back to date object every time I pass the date.
But it would get really tiresome, because there are so many child components that needs access to the date.
Have you tried to implement the shouldComponentUpdate lifecycle method? You could check for the inequality of the passed in date prop and todos array like so:
class MyComponent extends Component {
shouldComponentUpdate(prevProps) {
const {
date,
todos,
} = this.props;
const {
date: prevDate,
todos: prevTodos,
} = prevProps;
return (
date.getTime() !== prevDate.getTime() ||
!_.isEqual(todos, prevTodos)
);
}
render() {
// render...
}
}
The _.isEqual method performs a deep equality comparison of the two todos arrays. There is also a _.isEqualWith method you could use to define your own notion of equality for those arrays if you want to be more specific.
Alternatively, you could look into something like Immutable.js as it would allow you to do an easier todos !== prevTodos comparison, but this might be overkill for your needs (depending on how much data you're working with).
If you're already doing something like this, perhaps provide some more code (your implemented shouldComponentUpdate method so we can suggest other alternatives).
For #1 you don't need to convert the prop. You can simply compare the dates with getTime() in shouldComponentUpdate():
shouldComponentUpdate(nextProps) {
return this.props.date.getTime() !== nextProps.date.getTime()
}
And for #2 unfortunately it looks like an array which contains objects, I think doing a deep equal here is more expensive than just a render.
Note that executing render() doesn't mean that the DOM will get an update. If you setup key properly then it should be fast enough. (If the todos may change its order or the newly added todo is added on top then don't use indexes as the key. Real unique keys are better in that case)
You should try to avoid unnecessary setState (if you are not using a state management library). Also try to split your components to small pieces. Instead of re-rendering a huge component every time it has an update, updating only the minimum sections of your app should be faster.
Another possibility is to re-structure your state. But it's based on your requirements. If you don't need the full datetime of each todo, you can group your state something like:
todos: {
'2017-04-28': ['Watch movie', 'Jogging'],
'2017-04-29': ['Buy milk']
}
By doing this you don't even need the filter. You can grab the todos of the date your want easily.
In a more complex case which you need more information, you can try to normalize your state, for example:
{
todos: {
1: { text: 'Watch movie', completed: true, addedTime: 1493476371925 },
2: { text: 'Jogging', completed: true, addedTime: xxxxxxxxxx},
3: { text: 'Buy milk', completed: false, addedTime: xxxxxxxxxx}
},
byDate: {
'2017-04-28': [1, 2],
'2017-04-29': [3]
}
}
Now if add a new todo to the todos, it won't affect your component which is referring to byDate so you can make sure that there is no unnecessary re-renders.
I'm sharing my solutions.
For calendar based todo list, I wanted to avoid implementing shouldComponentUpdate for every subcomponents for a calendar day.
So I looked for a way to cache the dates I created for the calendar. (Unless you change the month, you see the same range of dates) .
So https://github.com/reactjs/reselect was a great fit.
I solved #2 with the reselect as well.
It memoizes (caches) function result until function params change.
Given the following Array of objects how would one update all of the qty's in each of the nested "locationData" Arrays Objects? By all, I mean not just all in the Object, but all in all Objects. The base object is say an Item and the locationData is locations the items are in.
What I am doing is displaying all Items with the locations to the user and the user can then click different buttons to distribute the un-allocated Quantity to the locations, which will update all of the objects with the chosen distribution.
Would I loop through the data in the React component and do a dispatch for each Item with a new locationData Array, replacing the old one?
Would I loop through the Items in the Actions and then call the Reducer with an entirely new Array of items with the new locationData?
I can do it with or without ImmutableJs, but I am not sure the best way to do this.
[
{
"isSelected":false,
"itemid":"2557",
"name":"Accessories : Awesome Cable",
"quantity":6000,"quantityByCase":600,
"locationData":[
{"id":"5","name":"QA Location","enabled":true,"percentage":"200","shipcarrier":"","shipmethod":"","qty":0},
{"id":"7","name":"Single Bin Location","enabled":true,"percentage":"50","shipcarrier":"","shipmethod":"","qty":0},
{"id":"1","name":"Warehouse - East Coast","enabled":true,"percentage":"","shipcarrier":"1","shipmethod":"92","qty":0}
],
"unAllocatedQuantityByCase":600
},
{
"isSelected":false,
"itemid":"40",
"name":"Accessories : Crusher Game Pad",
"quantity":50,"quantityByCase":50,
"locationData":[
{"id":"5","name":"QA Location","enabled":true,"percentage":"200","shipcarrier":"","shipmethod":"","qty":0},
{"id":"7","name":"Single Bin Location","enabled":true,"percentage":"50","shipcarrier":"","shipmethod":"","qty":0},
{"id":"1","name":"Warehouse - East Coast","enabled":true,"percentage":"","shipcarrier":"1","shipmethod":"92","qty":0}
],
"unAllocatedQuantityByCase":50}]
Currently, I am doing the the calculations in my reducer EVEN_DISTRIB, but this does not feel right. What I am doing is taking the entire state and mapping it to the items variable. items.isSelected is hard coded to true at the moment for testing. I then do an even distribution of the 'unAllocatedQuantityByCase' for each item and then lastly return all of the items and the new state for this reducer. There will also be weighted and like item distributions later, but wanted to get the even distribution right before proceeding further.
export default function (state = [], action) {
switch (action.type) {
case types.PO_RECEIVED:
return state.concat(action.payload);
case types.EVEN_DISTRIB: {
let items = state.map(item => {
item.isSelected = true;
if (item.isSelected) {
let quantity = item.unAllocatedQuantityByCase;
let updateLocations = item.locationData.filter(location => location.enabled);
let remainder = quantity % updateLocations.length;
let divideqty = (quantity - remainder) / updateLocations.length;
let loc = updateLocations.map(location => {
var tempQty = divideqty;
if (remainder >= 1) {
tempQty++;
remainder--;
} else if (remainder > 0) {
tempQty += remainder;
remainder = 0;
}
location.qty = tempQty;
return location
});
item.locationData = loc;
}
return item;
});
return items;
}
default:
return state;
}}
Should these types of calculations be done in the reducer? or should I do them in the component and then call the action with this as the payload? or is there a better way to do this... Normalizing the data structure and then just updating all of the locations. I guess my question is where do these types of calculations take place in a React/Redux app?
Actions: are functions that just return an action object. no logic in actions.
Would I loop through the data in the React component and do a dispatch for each Item with a new locationData Array, replacing the old one?: this just causes unnecessary re-renders cause the state will change each time you dispatch.
show some code
make your question clear so others can learn from it. and please show some code of what you are trying to do or be clear and to the point in your explanation.
looking forward to helping you.
First, the general suggested approach for organizing nested or relational data in a Redux store is to normalize it, much like tables in a database. That makes your state flatter and easier to manage. See Redux FAQ and Querying a Redux Store for more information on that concept.
Second, while it's up to you to decide how exactly you want to split your update logic, generally that work should be done in action creators or reducers, but not in your components. Redux FAQ gives some suggestions on how to think about splitting that logic. Some people will do all the work in their action creators and leave their reducers to simply merge the action contents into the store, others will have the action creator just dispatch and let the reducer do all the work. I personally am somewhere in the middle-ish - I try to put sufficient info into the action for the reducer to do the work, and am willing to let the action creator do needed prep calculations, but prefer to keep the contents of the action relatively minimal.
Third, your current reducer logic looks overly complicated. At a minimum, I would suggest breaking it up into smaller, simpler, pure helper functions that are easier to think about. Also, remember that with Redux you should update your data "immutably", ie, always make copies and modify the copies, never modify the original versions. The line location.qty = tempQty; appears to be directly mutating some of the original data, and that will generally cause your React components to not update properly. (The item.selected = true line does so as well, obviously.)