3 ms·

Any good primers on why it's beneficial to use immutables in JS? (especially with server side dev)

kasbah 9y ago
Not sure what you mean by primer but I prefer using immutable data structures because it eases programming in a functional style. I use Redux for server-side as well as front-end projects but using Redux without immutable data structures is a PITA because you have to constantly think about whether you are mutating things or not. I have been using immutable.js a lot but the difference from standard JS data types is kind of cumbersome and can become annoying so this project looks really neat. I am looking forward to giving it a try.
tommoor 9y ago
Two reasons: - Clarity of code. You can't accidentally mutate data that will then be used elsewhere. - Performance. Being able to avoid deep equality checks makes a huge difference for React in particular.
pault 9y ago
In general hand-wavy terms, it helps you write side-effect free functions; if you are operating on a data structure defined outside of a function's scope and mutate it directly, you lose reproducibility and your code becomes very difficult to test. By ensuring that the data structures are immutable, you remove one common source of unpredictable behavior. You can be confident that no matter how many times you pass a function a particular state, the resulting state will always be the same. You can do this without immutable data structures by being very careful and knowing exactly which operations mutate and which return new structures (you'll see JS devs using `Object.assign` and `Array.concat` for this purpose), but enforcing immutability with a library takes the burden off the individual developer. One of the reasons immutable JS data structures have been gaining in popularity the last few years is the adoption of React; the virtual DOM diffing algorithm relies on a few state management methods for knowing which nodes need redrawing and the DOM won't update correctly if you directly mutate the data structures the components are using for their state. As for server-side, I can only assume it's the general trend of JS developers increasingly adopting a more functional style. One of the nice side effects (hah) of using immutables the ability to easily keep a history of state transitions and revert to a previous state if something goes wrong. This can be particularly useful when dealing with distributed systems. It's also much easier to reproduce an undesired state when debugging production issues. It's not a silver bullet but it reduces the number of heisenbugs that turn up in production.
- acemarke 9y ago
  To add a bit more context: React itself doesn't care about mutations in terms of re-rendering and virtual DOM diffing. In fact, it doesn't even care about mutations in terms of calling `setState()`. I'll recap a couple previous comments of mine at https://news.ycombinator.com/item?id=14706862 https://news.ycombinator.com/item?id=14706862. You can mutate a component's state and then call `setState()`, and React will still update the component as you'd generally expect. For React, immutability primarily relates to implementing `shouldComponentUpdate` using the standard shallow equality comparison approach for the best performance, and general use of Functional Programming principles for avoiding side effects. For Redux, immutability matters for ensuring that reducer functions are pure with no side effects, as that is a requirement for time travel debugging and proper updates of Redux-connected components. So, overall immutability is definitely an encouraged approach in the React/Redux ecosystem, and there's specific places where that immutability is important for desired behavior.
always_good 9y ago
A hard part of React is determining when and what to re-render. It's one of the main things the state-management tools solve (Redux, MobX, etc). For example, imagine the naive example where you just have a global `const store = { ... }` and all components read from it and update it. You could tell everything to re-render on any change, but that's slow. So you can then implement `shouldComponentUpdate` for each component to manually check if their dependent data changed. But that may be a lot of work where each component needs to know quite a bit about the data. For instance, how do you check if two arrays are the same and without walking both arrays? Depending on your data, it may be as simple as comparing `item.id` of the first item in each array. But it might not be. On the other hand, you can tell if two immutable datastructures are equal with reference equality (obj1 === obj2). If all of your components take immutable data, then you can abstract away `shouldComponentUpdate` with a reference comparison. This is what React's PureComponent does. That's the main use-case. Not as many obvious use-cases on the server side in Javascript.

Not sure what you mean by primer but I prefer using immutable data structures because it eases programming in a functional style. I use Redux for server-side as well as front-end projects but using Redux without immutable data structures is a PITA because you have to constantly think about whether you are mutating things or not. I have been using immutable.js a lot but the difference from standard JS data types is kind of cumbersome and can become annoying so this project looks really neat. I am looking forward to giving it a try.

tommoor 9y ago

Two reasons: - Clarity of code. You can't accidentally mutate data that will then be used elsewhere. - Performance. Being able to avoid deep equality checks makes a huge difference for React in particular.

pault 9y ago

In general hand-wavy terms, it helps you write side-effect free functions; if you are operating on a data structure defined outside of a function's scope and mutate it directly, you lose reproducibility and your code becomes very difficult to test. By ensuring that the data structures are immutable, you remove one common source of unpredictable behavior. You can be confident that no matter how many times you pass a function a particular state, the resulting state will always be the same. You can do this without immutable data structures by being very careful and knowing exactly which operations mutate and which return new structures (you'll see JS devs using `Object.assign` and `Array.concat` for this purpose), but enforcing immutability with a library takes the burden off the individual developer. One of the reasons immutable JS data structures have been gaining in popularity the last few years is the adoption of React; the virtual DOM diffing algorithm relies on a few state management methods for knowing which nodes need redrawing and the DOM won't update correctly if you directly mutate the data structures the components are using for their state. As for server-side, I can only assume it's the general trend of JS developers increasingly adopting a more functional style. One of the nice side effects (hah) of using immutables the ability to easily keep a history of state transitions and revert to a previous state if something goes wrong. This can be particularly useful when dealing with distributed systems. It's also much easier to reproduce an undesired state when debugging production issues. It's not a silver bullet but it reduces the number of heisenbugs that turn up in production.

acemarke 9y ago
To add a bit more context: React itself doesn't care about mutations in terms of re-rendering and virtual DOM diffing. In fact, it doesn't even care about mutations in terms of calling `setState()`. I'll recap a couple previous comments of mine at https://news.ycombinator.com/item?id=14706862 https://news.ycombinator.com/item?id=14706862. You can mutate a component's state and then call `setState()`, and React will still update the component as you'd generally expect. For React, immutability primarily relates to implementing `shouldComponentUpdate` using the standard shallow equality comparison approach for the best performance, and general use of Functional Programming principles for avoiding side effects. For Redux, immutability matters for ensuring that reducer functions are pure with no side effects, as that is a requirement for time travel debugging and proper updates of Redux-connected components. So, overall immutability is definitely an encouraged approach in the React/Redux ecosystem, and there's specific places where that immutability is important for desired behavior.

always_good 9y ago

A hard part of React is determining when and what to re-render. It's one of the main things the state-management tools solve (Redux, MobX, etc). For example, imagine the naive example where you just have a global `const store = { ... }` and all components read from it and update it. You could tell everything to re-render on any change, but that's slow. So you can then implement `shouldComponentUpdate` for each component to manually check if their dependent data changed. But that may be a lot of work where each component needs to know quite a bit about the data. For instance, how do you check if two arrays are the same and without walking both arrays? Depending on your data, it may be as simple as comparing `item.id` of the first item in each array. But it might not be. On the other hand, you can tell if two immutable datastructures are equal with reference equality (obj1 === obj2). If all of your components take immutable data, then you can abstract away `shouldComponentUpdate` with a reference comparison. This is what React's PureComponent does. That's the main use-case. Not as many obvious use-cases on the server side in Javascript.