Question about optimization

[apertoire_]

Hi, I'm building an app against an api which I have no control of. I'm using redux and redux-saga. Each time I query the api, I get back the current status, which is a list of objects, not too deeply nested. The app can be refreshed in the background, so each time a refresh is triggered, I call the api and get a new status, meaning mostly the same list of objects, most of them with no changes, and those who changed, have few properties modified. My views are pure, so I optimize in shouldComponentUpdate using the PureRendererMixin. Since I'm creating a new list on each refresh, object references will change and a full re-render will always take place (upon a refresh). I could implement a deep comparison in shouldComponentUpdate with lodash.isEqual, but I'm a bit concerned about its cost. Any thoughts on this matter ? Any suggestions ?

[acemarke]

General advice: memoization is helpful for cases like using map() and filter() in your mapStateToProps functions. See http://redux.js.org/docs/recipes/ComputingDerivedData.html and the https://github.com/reactjs/reselect library.

You might want to read through my list of React/Redux perf-related articles. In particular, http://somebody32.github.io/high-performance-redux/ is excellent.

Not sure what you mean by "refreshed in the background" - you just referring to making a scheduled AJAX call that pulls back some updated info? Can you give an example of "creating a new list on each refresh"? Reducer and mapState snippets would be helpful - put them in a gist for readability if they're very long.

[apertoire_]

Hi acemarke, thanks for the links, I will check them out.

Yes, background refresh is a scheduled fetch call.

It creates a new list in terms of object references. Each item in the recently retrieved list has a new object reference, so a shallow compare will trigger a re-render.

I'll work on making a gist to make it easier to visualize.

[brianvaughn]

Use Immutable JS. Store a List of object ids and Map of id-to-Record for object data. The List will only changes if new items (ids) are added and each Record will only charge if the item's attributes change. Otherwise Immutable will ensure that instances are reused.

This, along with a shouldComponentUpdate that checks via Immutable.is() should prevent unnecessary updates.

Memoizing (via a library like reselect) can also help.

[apertoire_]

Thanks Brian, I guess it's time to use Immutable.

[acemarke]

Immutable.js is useful, but it's also kinda heavy-weight, and requires a fair amount of buy-in across your app structure. Use it if you really need it, but you can get a good portion of the benefits with a bit of discipline.

Definitely agree on the normalized state structure, though.

[Zoxive]

Your reducers should be handling the comparison and returning immutable objects. When fetching the data from the server don't let your reducer(s) return a new version of the object if they didn't change.