You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At first glance, this seems like it would be bad for performance on several levels. The constant calls to .toJS() are potentially expensive; part of the reason to use Immutable.js in the first place is to enable fast shouldComponentUpdate implementations via shallow equality, and Immutable references make that easier; and the constant .toJS() calls as far as I know mean you're returning a new object every time anyway.
As I understand it, generally to get the best performance you would want to keep things in Immutable form all the way down to your render function.
Also, there's a bunch of existing Immutable.js<->Redux interop libs already, most of which are listed over at the Immutable Data page in my Redux addons catalog.
The text was updated successfully, but these errors were encountered:
At first glance, this seems like it would be bad for performance on several levels. The constant calls to
.toJS()
are potentially expensive; part of the reason to use Immutable.js in the first place is to enable fastshouldComponentUpdate
implementations via shallow equality, and Immutable references make that easier; and the constant.toJS()
calls as far as I know mean you're returning a new object every time anyway.As I understand it, generally to get the best performance you would want to keep things in Immutable form all the way down to your render function.
Also, there's a bunch of existing Immutable.js<->Redux interop libs already, most of which are listed over at the Immutable Data page in my Redux addons catalog.
The text was updated successfully, but these errors were encountered: