Before jumping into its documentation, we need to understand the concept behind the evolution of Immutable.js. And in this post, we just focus on basics of Immutable.js.
So, what is Immutability?
The whole point of immutable objects is that if you have a reference to an immutable object you don’t ever have to bother checking whether any of its properties have changed or we can just say, “After a object has been created, it can never change.”
And, what are its consequences?
There are some consequences of that – whether they are good or bad depends on your expectations:
1. There is no difference between pass-by-value and pass-by-reference semantics
2. Some comparisons can be easier
3. When you pass a reference to an object somewhere you don’t have to worry that some other part of code will change it
4. When you get a reference to an object from somewhere you know it will never change
5. You avoid some problems with concurrency because there is no notion of a change in time
6. When nothing ever changes you don’t have to worry whether changes are atomic
7. It’s easier to implement software transactional memory (STM) with immutable data structures
But the world is mutable..!!!
Of course in practice we often deal with values that change in time. It may seem that immutable state can’t describe mutable world but there are some ways people deal with it.
Look at it this way: if you have your address on some ID and you move to a different address, that ID should be changed to be consistent with new true data, because it is no longer true that you live at that address. But when you get an invoice when you buy something which contains your address and then you change your address, the invoice stays the same because it is still true that you lived at that address when the invoice was written. Some data representations in the real world are immutable, like invoices in that example, and some are mutable like IDs. It may be true that the data is not up to date but it will always be consistent and true for some point in time, and it will never change.
What About Performance?
You might think that this would yield terrible performance, and in some ways you’d be right. Whenever you add something to an immutable object, we need to create a new instance by copying the existing values and add the new value to it. This will certainly be both more memory intensive and more computationally challenging than mutating a single object.
Because immutable objects never change, they can be implemented using a strategy called “structural sharing”, which yields much less memory overhead than you might expect. There will still be an overhead compared to built in arrays and objects, but it’ll be constant, and can typically be dwarfed by other benefits enabled by immutability. In practice, the use of immutable data will in many cases increase the overall performance of your app, even if certain operations in isolation become more expensive.
Conclusion:
Immutable data cannot be changed once created, leading to much simpler application development, no defensive copying, and enabling advanced memoization and change detection techniques with simple logic. Persistent data presents a mutative API which does not update the data in-place, but instead always yields new updated data.
-By
Uma Maheswar
Helical It Solution
Best Open Source Business Intelligence Software Helical Insight is Here
