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.
Related
I have this code which has plenty of inputs, one for each price value to modify it.
As the amount of inputs is high (3 prices per tarification, 3 tarifications per area), in order not to rerender everything each time, I'm using useMemo on the function that updates the value of the inputs and aside of this, I'm using useReducer to avoid having a very long code to control inputs.
However, inserting characters (or numbers in this case) in the inputs is not instant as it should be, instead it takes a short time for them to appear, not to mention consecutive inputs.
const handleUpdate = useMemo(
() => (property, valu, obid) => {
dispatch({ type: "UPDATE_DATA", property, payload: valu, id: obid });
},
[dispatch]
);
And the reducer:
function reducer(state, action) {
switch (action.type) {
...
case "UPDATE_DATA":
return {
...state,
data: state.data.map((item) => {
if (item.id === action.id) {
return { ...item, [action.property]: action.payload };
}
return item;
}),
};
}
}
I suggest checking the whole code as the problem (or solution) could be somewhere else. In order to see the whole code, you can refer to this sandcodebox link. Excuse the bad css formating as I copied just some part of it.
Note that the fetch function has been replaced by a long array simulating the data.
https://codesandbox.io/s/unruffled-feynman-g9nox2?file=/src/App.js
The point of useMemo generally is to cache the values of expensive calculations done during rendering. However, in your case, you do not have any expensive rendering calculations; you are just rendering a really large tree every time an input changes. In fact, because all your state is on the App component, you rerender the entire app every time.
The way to optimize this in React is to skip rendering components when possible. To do so, split unrelated pieces of the page into distinct components. Once you separate the logic, wrap it with React.memo(), which is a different optimization technique that can skip the rendering of a component altogether.
To me, the most obvious changes you can make are:
Move TodosDatos outside the App component because it is constant and doesn't need to be redefined on every render (which can be memory-intensive).
Move your <Table> into a new component that you memoize with React.memo(). Make sure to pass all the table's dependency values into the new component's props.
I implemented these changes here: https://codesandbox.io/s/green-breeze-mmum6n?file=/src/App.js. You should notice now that typing is nearly instantaneous. You can probably optimize it in several other places too for even better performance.
I've structured my redux application such that my data models are handled on separate branches of the state tree.
{concerts, venues}
I've also used react-navigation-redux-helpers to put my navigation state into the tree:
{concerts, venues, nav}
However, I want to record information about the visibility state of a particular model. When the ConcertScreen is shown, I want to know when a user's looking/stops looking at a particular concert ID (and letting the server know), with the eventual goal of measuring how long a particular concert ID was visible on screen.
I've done this by adding branches for Navigation/NAVIGATE, Navigation/RESET, and Navigation/BACK to the concerts reducer, and setting visible: true on the appropriate object under concerts.
This has been error prone, since the navigation state can be modified by actions other than these specific actions. (A logout action handled directly by the nav reducer, for example.)
I see two alternatives, both not ideal:
Use props.navigation.addListener to listen to focus and blur events on the ConcertScreen, trigger custom concertFocused/concertBlurred actions, and handle those in my concert reducer instead of the Navigation/* actions.
Create a selector that computes the currently visible concert from the nav state and refactor the business logic that expects concert.visible as input to use the selector instead.
The problem with 1 seems to be that it's adding overhead to the event loop, all the extra actions flying around means extra rendering overhead.
2 avoids the extra actions, but it seems like a lot of refactoring for not a whole lot of gain, and it means I have to move business logic out of the concert reducer and put it elsewhere.
Say I use option 2. I add a middleware that, on any action, applies the selector to state.nav and from that computes what Concert is currently displayed. If I wanted to measure duration, how would I store start/end time? Fire a new action with that added data so the concert reducer catches it? That just seems like option 1 with extra steps.
I could also have this middleware add a field to every action indicating the concert display state, and have the concert reducer handle it in the default/fallthrough case. Do people do that?
I would approach your use-case in such a way, that I will get the best of both solutions.
First of all, having many actions dispatched you're worried about rendering overhead. Using a selector library, let's say reselect, the library memoization will prevent unnecessarily components rerendering.
Later on, if I understand you correctly, your goal is to let the server know the visibility status of an item (concert) and eventually its visible time. If your goal is notifying the server only, without letting know the rest app's front-end users, why do you want to keep tracking it in Redux too? You can skip the Redux part and send updates to the server only.
Let's assume, that you need Redux for the tracking. You can try on your way structuring the Store, as you already mentioned, adding the visible flag to each object in the Redux store. But if your items' structure is bigger enough and it's costly to copy and update the object each time when changing the visible flag, you can consider creating a dedicated Store branch and reducer, that will be responsible only for the tracking needs. Something like that:
tracking : {
concerts: {
1: { visible: true, time: 10 }
}
}
Now, updating an item's flag, only the above tiny structure has to be copied and modified. Even, you can make it smaller and more specific for a certain item type (trackingConcerts).
* Keep in mind, it's on your own to decide whether or not such a dedicated Store branch will improve the performance, because we don't know your detailed architecture and Store specifics.
Continuing with the solutions ...
Relying on navigation actions + middleware is error prone, as you mentioned. What about the use-case you have a general page of components (i.e. navigation action with generic name will be dispatched), but you render there one of your items (concert)? Also rendering an item, would be always coupled with modifying the mapping logic in your middleware or wherever place you track the items by action name. Another tricky case is when you render different type of items (concerts, venues) on exactly one page. How will you differ and track the items, considering you have only 1 navigation item? Also in a such setup, I don't see a straightforward way for handling an item visible time.
About the selectors as a solution - they can be only a small part of the solution. The selector is responsible for selecting and managing derived state. Nothing more.
Show me the code, please.
I would create a wrapper component around react on screen (or any similar library that tracks component visibility) and implement only the tracking visible time of the component.
The wrapper will trigger callbacks when the component visibility state is changed and a callback on componentDidUnmount including the visible time.
That's all! Now you can attach handlers on these callbacks and you can update your Redux and/or notify the server for the visibility changes, without relying on any navigation actions and middlewares.
Usage:
const App = () => (
<Tracking
onVisibilityChange={isVisible => {}}
onUnmount={visibleSeconds => {}}
>
<Concert id={1} />
</Tracking>
)
Tracking Wrapper:
import TrackVisibility from 'react-on-screen'
const Tracking = ({ children, libraryProps, ...rest }) => (
<TrackVisibility {...libraryProps}>
<TrackingCore {...rest}>
{children}
</TrackingCore>
</TrackVisibility>
)
TrackingCore, our custom tracking logic:
class TrackingCore extends React.Component {
constructor (props) {
super(props)
this.state = {
visibleSeconds: 0,
interval: null
}
}
componentDidMount() {
this.track()
}
componentWillReceiveProps (nextProps) {
this.track(nextProps)
}
componentDidUnmount() {
const { visibleSeconds, interval } = this.state
const { onUnmount } = this.props
onUnmount(visibleSeconds)
clearInterval(interval)
}
track (nextProps) {
const { isVisible, onVisibilityChange } = this.props
const { visibleSeconds, interval } = this.state
const hasVisibilityChanged = (isVisible !== nextProps.isVisible) || !nextProps
const isVisibleValue = nextProps ? nextProps.isVisible : isVisible
// On visibility change, invoke the callback prop
if (hasVisibilityChanged) {
onVisibilityChange(isVisibleValue)
// If it becomes visible, start counting the `visibleSeconds`
if (isVisibleValue) {
this.setState({
interval: setInterval(() => this.setState({
visibleSeconds: visibleSeconds + 1
}), 1000)
})
} else {
clearInterval(interval)
}
}
}
render () {
return this.props.children
}
}
I try to use ApolloClient 2.1 with the new Mutation Component.
Simple use cases are working but now I have something more complex.
What I want to achieve is to query data and put them in a list, then sort this list (here via react-sortable-hoc) and once sorted, I want to update the new position for all elements in the list.
So the basis is something like this, which is working for simple Querying:
const query = gql`
{
items( order:{by:"position", direction:"desc"}) {
id
name
position
}
}`
const ItemView extends Component {
onSortEnd = ({ oldIndex, newIndex }) => {
console.log("Sort ended: ", oldIndex, newIndex);
}
render() {
<Query query={query}>
{({ loading, data, error }) => {
if (loading) return <p>Loading...</p>;
if (error) return <p>Error</p>;
return (
<ItemList items={data.items} onSortEnd={this.onSortEnd} />
)
}}
</Query>
}
}
Now I really struggle at a lot of parts in order to do the mutation.
I think I need to wrap the Mutation Component. But how can I provide a GraphQL Query in there, because I want to do batch mutation with a similar query being fired multiple times, such as
mutation {
updateItem1: updateItem(id: 457092155, input: {position: 1}) {
item {
id
}
ok
errors
},
updateItem2: updateItem(id: 54489270, input: {position: 2}) {
item {
id
}
ok
errors
},
... // much more mutations, one for each item in the list
}
So my main question is, how do I pass a GraphQL mutation with dynamic amount of mutations to the Mutation component? Or should I do this completely differently?
Thanks a lot for any hints
You will have to compose multiple Mutations together in order to achieve this. You can use react-adopt for this. They have even addressed this here https://github.com/pedronauck/react-adopt#leading-with-multiple-params.
You can also take a look at the discussion going on here https://github.com/apollographql/react-apollo/issues/1867 and jasonpaulos has an example demonstrating this with hooks
Hi everyone! I believe that the new Apollo hooks, useQuery,
useMutation, and useSubscription, adequately address this use case. To
demonstrate this, I have converted #Cridda's example that uses
react-adopt and modified it to use #apollo/react-hooks here:
https://codesandbox.io/s/apollo-and-react-hooks-4vril
This example is by no means perfect, but it serves as a demonstration
of how hooks can massively simplify some use cases.
Hope this helps!
As Hemant mentioned already, the #compose annotation in Apollo 2.1 is the "correct" / conventional way to solve this problem. If that doesn't work for you for whatever reason, there is possibly another cruder/hacky way to accomplish this:
If your Item model has a parent model, you can mutate multiple nodes with one mutation by passing the children in as the array values to the connect / create / update actions.
The unfortunate limitation here is that there is no way to individually identify child nodes to be updated. What I mean is that you can filter child Items to be mutated based on a criteria (like postition = 2) but that will only allow you to mutate the filtered items to the same state; you won't be able to update them differently from one another this way.
If we allow ourselves one more crude step, you can delete the Item nodes that you wish to update before calling the update mutation - this will allow you to call the mutation with all of the updated items under the create: key in the mutation, which will allow you to specify each item to be created. In this way, the number of items you can create is only limited by the size of your request payload.
There are many cases where deleting and creating nodes is unacceptable (as opposed to updating them)...if you use this method then be sure there are no negative side effects to your use case(s) from deleting item data in this way.
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.
I am using redux with react and typescript for my application. I am working with many items used at different places of my app. My state looks like this:
{
items: {42: {}, 53: {}, ... }, //A large dictionary of items
itemPage1: {
itemsId: [ 42, 34, 4 ],
...
},
itemPage2: { ...
},
...
}
The user can modify some attributes of the items dispatching some actions. When this happen I need to redraw the components that have been modified in each pages. The issue is that my items are quite big and I cant afford to redraw all of them at each small modification. I was wondering is this approach would work:
I have a fist component <ItemPage1> which connects to the store to get all of the states stored in the tree under itemPage1 e.g. the list of items id: itemsId.
Inside <ItemPage1>, I loop over the itemsId property to generate multiple FilterItem components: itemsId.map( itemId => return <FilterItem id=itemId>);
Finally each Item is connected using ownProps to get the correct part of the state:
const mapStateToItemProps = (state, ownProps) => {
return {
item: state.items[ownProps.id],
}
}
const mapDispatchToItemProps = (dispatch, ownProps) => {
return null;
}
const FilterItem = connect(
mapStateToItemProps,
mapDispatchToItemProps
)(Item)
Can you confirm or refute that if I update the item of id 42, then only this item is going to be re-rendered ?
When rendering big list you need to take into considerations few things :
Lower the total number of DOM elements that you need to render (by not rendering items that are not actually visible on the screen, also known as virtualization)
Don't re-render items that have not changed
Basically, what you want to avoid is a complete re-render of your list (or your page) when the user edits one single row. This can be achieved exactly how you did it, i.e : by passing to the list container only the ids of items that need to be rendered, and to map over these ids to connect each component by using ownProps. If you have a dump <Item/> component, your <ItemPage/> component will create connected connect(<Item/>) component.
This is going to work, if your put a console.log('item rendered') in your <Item/> component class you will notice that there is only one call.
BUT (and it's a big but), what is not obvious when working with react-redux is that all connected components that depends on their ownProps will always rerender if any part of the state change. In your case, even if the <Item/> components will not re-render, their wrapped component connect(Item) will ! If you have few dozens of items, you might encounter some latency if actions need to be dispatched quickly (for example when typing in an input). How to avoid that ? Use a factory function to use ownProps as the initial props :
const mapStateToItemProps = (_, initialProps) => (state) => {
return {
item: state.items[initialProps.id], // we're not relying on the second parameters "ownProps" here, so the wrapper component will not rerender
}
}
const mapDispatchToItemProps = (dispatch, ownProps) => {
return null;
}
const FilterItem = connect(
mapStateToItemProps,
mapDispatchToItemProps
)(Item)
I suggest you to take a look to this other answer.
You might also be interested in these excellent slides : Big List High Performance React & Redux
And finally, you should definitively take a look to react-virtualized to perform the virtualization of your list (i.e, displaying only the item that the user can actually see).
Ok, I've found this discussion: https://github.com/reactjs/redux/issues/1303
At the bottom it is clearly stated (from multiple protagonists):
[...] react-redux takes care of this. It lets you specify specific parts of the state you care about, and takes care to bail out of updating React components when the relevant parts have not changed.
[...] Just wanted to fully understand that what's going on under the hood here, So if the Redux store gets updated but one specific component state hasn't changed, Redux won't trigger the forceUpdate() method for that component? [...]
The wrapper component generated by React-Redux's connect() function does a several checks to try to minimize the number of times your actual component has to re-render. This includes a default implementation of shouldComponentUpdate, and doing shallow equality checks on the props going into your component (including what's returned from mapStateToProps). So yes, as a general rule a connected component will only re-render when the values it's extracting from state have changed.
So I believe my implementation is good, it won't re-render all the items since only one item will see its properties modified.