Using `connect()` with `Immutable.Map` state object

My store is an Immutable.Map object, and I would like to pass it down my tree of React components. I suppose that in most cases I can get good performance by using something like PureRenderMixin (or ES2015 equivalent) when doing so.

I started out simple decorating my App class with @connect(state => state), and I got this error:

“Uncaught Error: Invariant Violation: mapStateToProps must return an object. Instead received Map {…”

I’m able to do something like @connect(state => {return {state};}), and then unwrap the object in App’s render(), but I get the sense that this is not an ideal solution.

[gnoff]

The return of the mapStateToProps needs to be an object because the object is spread as props to the wrapped component. Your work around is in fact the idiomatic way to use @connect. In this case your wrapped component will have a prop named 'state' which is an Immutable.Map

Now you may want to reconsider passing the entire app state to your connected component however. This will make refactoring your state shape a lot harder when your app is more complicated. Though in simple cases it is fine.

Ah, I understand.

I already pass what that I consider being the app state. By passing the entire app state, do you mean doing @connect(state => state.toJS())?

I haven’t fully decided whether or not I want the immutable or a plain JavaScript object floating through the component tree, but performance is the number one priority in this particular case. I need to look into how shouldComponentUpdate() and each alternative will work with my data. I also consider using several @connect() a bit higher up the tree, instead of one at the root component.

[gaearon]

I already pass what that I consider being the app state. By passing the entire app state, do you mean doing @connect(state => state.toJS())?

That would be slow. I suggest you don't do that, and if perf is your main concern, use @connect granularly.

I need to look into how shouldComponentUpdate() and each alternative will work with my data.

Actually @connect already implements a rather decent shouldComponentUpdate so don't worry about it too much.

[gaearon]

Indeed, as @gnoff said above, you can't just return Immutable object because we spread over the values you return, and this wouldn't make sense with Immutable.

I’m able to do something like @connect(state => {return {state};}), and then unwrap the object in App’s render(), but I get the sense that this is not an ideal solution.

The idiomatic way is to do this:

connect(state => ({
  stuff: state.get('stuff'),
  otherStuff: state.get('otherStuff')
})

only for the fields you actually care about, so @connect can bail out when the parts the component doesn't need, did not change. I don't suggest using toJS() because AFAIK it's deep, but deep conversions won't be as performant as just extracting the stuffy you want.

I also consider using several @connect() a bit higher up the tree, instead of one at the root component.

This is the way to go, and it's more performant than just one @connect at the top.

[gaearon]

btw if you're concerned about performance, make sure you check out reselect and Computing Derived Data.

Great, thank you both!

[liorbrauer]

Thanks! This really cleared up the same issue I was having.

[thewillhuang]

@gaearon Hey Dan, what are your thoughts of running immutable AND reselect together versus just one or the other?

[gaearon]

Feel free to use them together. They're solving different problems and can be used complementary.

[patoncrispy]

Wasn't aware connect() implemented a shouldComponentUpdate() which is great to know... is this in the docs somewhere? Is there a suitable way of making props immutable further down the tree to prevent more nested components updating unnecessarily?

[gaearon]

Wasn't aware connect() implemented a shouldComponentUpdate() which is great to know... is this in the docs somewhere?

This is an implementation detail. We say “performant” in the repo description but I wouldn’t detail the optimizations as they may change.

Is there a suitable way of making props immutable further down the tree to prevent more nested components updating unnecessarily?

Not sure what you mean. Any connected component does a shallow comparison. If its props (including props from store) don’t change, it doesn’t update.

[patoncrispy]

Sorry, I can see how that made little sense. Well, If I have a container (uses connect()) that has an array of components (could be 100+) which may update frequently but sporadically, would it be possible to only update those that changed in some way? Or would it simply be a case of having to redraw them all as it is the Container that uses connect()?

[gaearon]

What do you mean by “update”? React only updates DOM when necessary. There is a cost for reconciliation process (which is where it compares the element trees), and shouldComponentUpdate() lets you bail out of this process.

When you use connect() on a component, it is subscribed to the store, and if the calculated props change, it will cause reconciliation on the connected component.

So if you connect a list to the store, and a list renders 100 rows, if the calculated props change after a store update, React will reconcile those 100 row elements. Then it will look at rows themselves. If your row components implement shouldComponentUpdate() you can bail out there. If your row components are connected, the shouldComponentUpdate() implementation we provide will bail out if props are shallowly unequal.

Does this make sense?

[patoncrispy]

Yes. Thanks for your wisdom, Dan! Just as I think I'm understanding things then 'WHAM!'... something else comes up. :)