3 ms·

Immer seems like it lets you take the same approach as mobx, but instead of rerendering based on an optimized run-time constructed dependency graph, Immer has t

by nawgz 6y ago

Immer seems like it lets you take the same approach as mobx, but instead of rerendering based on an optimized run-time constructed dependency graph, Immer has to rebuild every single item "under" your mutation. Doesn't this seem like it would be insanely expensive for modifying arrays or things like this? I also have to imagine the amount of boilerplate you write to use Redux + Immer is orders of magnitude over mobx, but maybe some people prefer it to be slightly more explicit

acemarke 6y ago
Immutable updates in JS have always required making copies of each level of nesting that has to be updated [0]. However, that process is very tedious and error-prone due to writing lots of nested spread operations. Immer effectively does those same steps, but automatically. This is all completely different than how Mobx works. Immer has a slight performance overhead [1], but in practice reducer logic is almost never a meaningful perf bottleneck in a React+Redux app - the cost of updating the UI is might higher. It's also worth noting that Immer was actually created by Michel Weststrate, the author of Mobx :) [0] https://redux-toolkit.js.org/usage/immer-reducers#basics-of-immutability https://redux-toolkit.js.org/usage/immer-reducers#basics-of-... [1] https://immerjs.github.io/immer/docs/performance https://immerjs.github.io/immer/docs/performance
- nawgz 6y ago
  Yes, absolutely that is my understanding of immutability. It's why I asked the performance question, but Immer docs are convincing, I see your point. Not a surprise to me that mwestrate is the author after seeing the description of Immer - he has an excellent graph knowledge and applies clever architectures & optimizations from that. I recognize it's completely different from how MobX works, I simply mean to say that I feel MobX is superior and this mere idea of mutability / copying instead of smartly updating a graph and correspondingly only the observer portions of your UI seems like the core of that

by nawgz 6y ago

acemarke 6y ago

Immutable updates in JS have always required making copies of each level of nesting that has to be updated [0]. However, that process is very tedious and error-prone due to writing lots of nested spread operations. Immer effectively does those same steps, but automatically. This is all completely different than how Mobx works. Immer has a slight performance overhead [1], but in practice reducer logic is almost never a meaningful perf bottleneck in a React+Redux app - the cost of updating the UI is might higher. It's also worth noting that Immer was actually created by Michel Weststrate, the author of Mobx :) [0] https://redux-toolkit.js.org/usage/immer-reducers#basics-of-immutability https://redux-toolkit.js.org/usage/immer-reducers#basics-of-... [1] https://immerjs.github.io/immer/docs/performance https://immerjs.github.io/immer/docs/performance

nawgz 6y ago
Yes, absolutely that is my understanding of immutability. It's why I asked the performance question, but Immer docs are convincing, I see your point. Not a surprise to me that mwestrate is the author after seeing the description of Immer - he has an excellent graph knowledge and applies clever architectures & optimizations from that. I recognize it's completely different from how MobX works, I simply mean to say that I feel MobX is superior and this mere idea of mutability / copying instead of smartly updating a graph and correspondingly only the observer portions of your UI seems like the core of that