Let's look at a list of frequently asked questions related to Immutable.js, as follows:

1. Do I need Immutable JS in my application?

If you are not sure what benefits Immutable JS can bring to your application, you should not use it. Just because a library is being used by enterprise applications does not mean that you have to use it. Before considering using it, you should understand it and feel a need for using it.

2. Is there something wrong with mutating objects?

There is nothing wrong with mutation. Several developers in the community have discussed and presented their thoughts regarding mutating objects, and how it does not harm the application. Why should we complicate things when we can do them in simpler ways? Say, if we have object money and it dies, we do not need a second monkey to track the change? A lot of people would argue that monkey.isDead = true should solve our problem.

3. When should I consider using Immutable JS?

You should use Immutable JS in the following cases:

• When you feel that you are doing a multitude of unnecessary data copying, using newState = Object.assign({}, oldState, { isMonkeyDead: true });.
• When you feel that you are mutating the reducers, time and time again. According to the Redux principle, reducers should never mutate the previous state tree; however, this is difficult to achieve. There is no strict validation in the library, or in the language, that asserts the fact that a developer has not mutated some state accidentally. It is impossible to mess up with Immutable JS.
• Your application is large enough to handle a massive amount of data in the state tree.