Using `connect()` with `Immutable.Map` state object about react-redux

[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.

[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?

[msuperina]

Sorry for commenting a closed issue but I keep coming here when googling for a similar issue.
I spent a lot of time to understand how to integrate Immutable with Redux, even implementing my own version of connect, and finally understood how to use the @connect from 'redux-connect'
I just wanted to understand @Gaeron answer from 17 august 2015

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

It seems to work ( and looking at the shallowEqual code it seems reasonable ) when state.get('stuff') and state.get('otherStuff') are Immutable objects, not plain JS.
Can someone confirm it is the case or am I missing something ?

[bherrmann7]

Our project uses an Immutable.Map as our store and connect like so,

  App = connect(state=>state.toObject())(App);

Which seems to neatly pass everything from the map into the App. Our entire application has 125 Components and only the 1 connect. Are we using an anti pattern? It seems performant...

[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.

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()?

[patoncrispy]

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

[markerikson]

The actual return value from mapState does need to be a plain object. However, the values within that object can certainly be Immutable.js data structures. So, in that example, if "stuff" was an Immutable Map, and "otherStuff" was an Immutable List, that would be just fine, as long as your actual component is expecting to get a Map and a List, rather than a plain JS object and a plain JS array.

As a side note, there are a number of utilities out there already to integrate Immutable.js into a Redux app. See https://github.com/markerikson/redux-ecosystem-links/blob/master/immutable-data.md#immutableredux-interop for a list of some of them.

[lee1994522]

@bherrmann7 How about those nested immutable Data?They can't be converted to a plain object by toObject() function.Only by toJS() can we convert all nested immutable data.