Thoughts on ImmutableJs

[diegohaz]

Thoughts on ImmutableJs

[diegohaz]

I'm very interested in ImmutableJs, although I've never implemented it on any project. It hadn't been an actual need.

My problem in adding it to the boilerplate is to force people to learn another library, which they might not need, just to use the boilerplate (for instance, I think redux-saga is already heavy stuff).

On the other hand, I would love to see a section in the README with instructions on how to implement ImmutableJS or even a fork or another branch with ImmutableJS implemented.

[zentuit]

I'm sure Immutable is a good library however it comes at a cost - Immutable objects are not plain javascript objects so there are issues with interoperability where you have to remember to call toJS when using something that expects plain vanilla javascript objects.

I've used it and didn't like it.

For our latest project, we're using timm which are just immutable functions to use for vanilla javascript objects. That's worked pretty well.

[jeremyadavis]

I've done a couple projects with Immutable and I'm still unsure if I'd recommend it. It took longer to get used to than initially expected, mainly because plain objects are so familiar so I'm constantly using dot-notation instead .get('prop') and hitting runtime errors.

The official docs are also pretty awful for getting real examples of how to use the methods.

On the positive side, I'm sure it has help prevent some work with my reducers where I occasionally will accidentally mutate state arrays.

Plus, the main positive is the performance gain with the ShouldComponentUpdate lifecycle method or React.PureComponent

[advance512]

Interesting conclusions regarding Immutable.js:
https://medium.com/@AlexFaunt/immutablejs-worth-the-price-66391b8742d4#.6iax77iwb

[jeremyadavis]

@advance512 Thanks for sharing. I feel like I'm agreeing more and more with the author.