9 ms·

Bit confused (ignorant actually) here. Can someone give a 'real world' example of the benefits of immutabile objects in js?

• ionforce 12y ago
  Immutable objects in general or immutable objects in JavaScript specifically?
  • abaco 12y ago
    A general example would be good :)
    • ionforce 12y ago
      It is a guarantee to you that the data structure has not been tampered with by the time it reaches you. // pseudo code var fruitBasket = new FruitBasket('banana, 'apple) muckWithFruits(fruitBasket) suspiciousLogger(fruitBasket) weirdCallback(fruitBasket) // here assert(fruitBasket.length == 2) By the time we reach "here", we know that none of the functions since the inception of fruit basket have tampered with it. This may not be a big deal if you are disciplined about never modifying your source data, but this moves the guarantee from a soft one to a mechanical one. And then there's all this typical stuff about functional programming blah blah... But that's the most practical example I can think of.
      • bsimpson 12y ago
        If everything is immutable, it also makes it a lot easier to parallelize tasks, because you can easily deduce a dependency graph.
    • frankosaurus 12y ago
      In multi-threaded environments, immutable objects are thread-safe. When multiple threads are sharing data, you would normally have to worry about synchronization. However, immutable data structures guarantee that the shared data will not change, so synchronization issues simply go away. That said, I'm not sure how this applies to JS, which is single-threaded.
      • ionforce 12y ago
        Even though it's single-threaded (not with web threads maybe?), it can still be asynchronous, which is where the issues really lie.
• friesenj 12y ago
  The first time I understood why immutable objects are important was in this podcast with ClojureScript and Mori author David Nolan: http://podcasts.thoughtbot.com/giantrobots/93 http://podcasts.thoughtbot.com/giantrobots/93 What I thought was the key point was this: Let's say you have a regular JS array. There is a reference to it in memory and it has a certain value. Now you change an element in that array. You've just mutated it. In JS, the reference in memory doesn't change, but now the value of what it's pointing to has. So in order to know if the value has changed, you need to do a comparison on every element on that array, which is expensive. Now let's say you have a immutable array (such as from the Immutable FB library or Mori). If you change an element in that array, you get a new array and a new array reference in memory. In other words, if you check that the reference in memory is the same, you are guaranteed that the value is the same (in this case, the array). So checking for equality is fast and cheap because you are only checking the reference, not each value in the array. One way this is important in React is that now if your component state (or entire app state) is represented by an immutable data structure, you can just check for reference equality in the shouldComponentUpdate() method when deciding to re-render that component. If the reference is equal, you are guaranteed that the data backing that component hasn't changed and you can return false, telling React not to re-render. What's surprising is that people have made these data structures also very memory efficient. You can see David Nolan talking about how they work and memory comparisons here: https://www.youtube.com/watch?v=mS264h8KGwk https://www.youtube.com/watch?v=mS264h8KGwk
  • nawitus 12y ago
    Note that you can have cheap equality detection by using e.g. flags or revision counters and so on (but there are limits due to JavaScript's nature..). The problem is that JavaScript currently doesn't support this properly out of the box, but Object.observe is coming in the next standard. I personally like the safety benefits of immutability. You can give objects to functions and not worry about the functions changing the object. The only way to guarantee that otherwise is to clone the object, but that takes quite a bit of performance.
    • sebmarkbage 12y ago
• deleted 12y ago
  [deleted]