ImmutableJS

[react-boilerplate]

ImmutableJS

[borisd]

ImmutableJS also offers nicer syntax for reducers, like:

state = state.setIn(['playlist', 'current'], song);

The downside is that the mapStateToProps() function, and the usage of the objects on the React side must also use get() to get usable data.

[mxstbr]

I'm not sure I feel comfortable making developers use that abstraction. Remove Immutable is probably harder than adding it in after the fact.

We could add some documentation on how you would go about adding it though, so people who want to use it have a tutorial right at hand!

[zavelevsky]

Cons:

• Another dependency (increased bundle size, etc.)
• not a standard API (access via get, set, and other functions)
• Incompatible with combineReducers, redux-[simple-]router

Pros:

• Forces immutability
• Rich API for collections and maps with nice optimizations like Seq

I suggest that you do your best to put all direct access to state in no more than one or two places. For example - wrap the state with an abstraction that the reducers will call. You can also implement mapStateToProps there.
Within - it'll be a simple Object.assign - but anyone can change to immutable.

[borisd]

Mapping from ImmutableJS to plain JS in few places will force the developer to use .toJS() - basically exporting the Immutable tree into plain JS (Heavy memory & performance impact).

Not tested, but feels like unless one uses Immutable fully - there will be no performance/memory gains (quite the opposite).

From Doron's comment it sounds like, unless you need all the extra structures of ImmutableJS - it should be avoided.

[mxstbr]

@zavelevsky that sounds interesting, being able to swap in Immutable quickly would be a big plus. To be honest I have no idea how one would go about doing this, would you be able to submit a PR? I'd love to see that!

@borisd I'm thinking, it's a useful tool if you're working across a massive team on a massive app, but until then it's kind of a bit too big to include. That's why what @zavelevsky suggested sounds really good, get all the benefits but none of the drawbacks, and you can swap in Immutable on short notice!

[zavelevsky]

Maybe a clarification is in place (based on @borisd comment) - I'm against passing the entire state tree/object to components - so there's no reason for any component to access the state directly.
Even "controller component" does not access the state directly in redux - they get what they need via props because of mapStateToProps of redux-react @connect().
So in any case you break the state tree to more or less primitive props. You don't have to use toJS on the entire state - you can fetch what you need selectively.

The exception here being huge collections which admittedly aren't handled well in any of the cases (how do you deep copy a huge collection when you perform Object.assign?). Huge collections usually require special treatment anyway.

So - in order to read from the state you simply implement mapStateToProps in a way that reads the desired fields from the immutable Map and from there it's passed via props. To me it makes sense.
No risk of anyone mutating the state anywhere - as the state is only manipulated in one place - and there it's an ImmutableJS Map.

[mxstbr]

@zavelevsky I see what you're saying, but to be honest I don't think including ImmutableJS by default is a good way of going.

Redux enforces a (more or less) immutable app structure by default. (in the sense that you cannot do globalApplicationState = someObject; anywhere)
ImmutableJS might be nice to have on bigger teams to explicitly remind and keep people from ever setting the state, but the boilerplate already isn't very beginner friendly and adding even more magic won't make it easier on them.

I think ImmutableJS is a nice lib itself, so adding a section on how to use it with the boilerplate to the advanced documentation would be nice - would love a PR about that. (I've added it to the documentation todo list in #14)

[mxstbr]

I've reconsidered using ImmutableJS and have opened a new issue/discussion, see #129

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.