9 ms·

Ironically, there's a name clash with a fairly popular immutable update library for JS: https://github.com/immerjs/immer https://github.com/immerjs/immer Look

Ironically, there's a name clash with a fairly popular immutable update library for JS: https://github.com/immerjs/immer https://github.com/immerjs/immer Looks like the C++ one started first (2016-05 vs 2017-12).

aidos 7y ago
I assumed it was some sort of port, but they’re totally different things! OT but it’s worth reading the code for immerjs. It’s super small, super clever and shows the power of proxies in js.
- acemarke 7y ago
  Yep. Michel Weststrate is a genius, and also an all-around nice guy. I hope to have a chance to meet him in person. (For reference, I'm a Redux maintainer. We now recommend Immer as the best way to write immutable update logic in Redux apps, and use it in our Redux Starter kit package.)
  - akuji1993 7y ago
    Saw this code in a client's redux project, it was awesome to see that. So much easier than how we were about to do our very complex state updates. It takes away a lot of the complexity. Immediately copied that and showed it to our webdev channel.
    - acemarke 7y ago
      Glad to hear it! Please let me know if you have any further feedback from using it. Here's the current roadmap towards 1.0: https://github.com/reduxjs/redux-starter-kit/issues/82 https://github.com/reduxjs/redux-starter-kit/issues/82 I just pushed out a breaking set of changes a few days ago, and will likely make one more set of breaking changes to `createSlice` in the near future. After that, I'm hoping the API will _mostly_ be good to go, and I can push it towards 1.0 in the very near future.
  - k3liutZu 7y ago
    Immer looks awesome but we're relying on Immutablejs shallow object comparison to stop rendering React components when not needed. When I last checked I could not figure out how to achieve the same thing with Immer. Do you know some reference that addresses this? And if we're here an additional question: since our store data is currently composed of deep immutable JS data structures, do you know of a way to slowly migrate to Immer? I've tried to move parts of the store to Immer, but since the root store obejcts are still Immutable js objects, this didn't go well.
    - acemarke 7y ago
      Shallow object comparison is not a special property of Immutable.js. It's just a matter of iterating over the keys and values of two objects and comparing them. In fact, that's how React-Redux (and many other React ecosystem libs) work. `connect` decides whether to re-render your component by doing shallow comparisons of the previous and current `mapState` return object to see if the extracted values have changed. All that's necessary is to do immutable updates of your data, by always making _copies_ of the data and modifying the copies (see [0] and [1] for discussions of immutable updates). It doesn't matter whether the new object references were produced by manually creating copies ( `{...obj}`, `someArray.map()`, etc), by using Immutable.js's API, or Immer tracking the "mutations" via a proxy and creating the new references internally. As long as you have immutable updates and new references, shallow comparisons work fine. So, there's nothing special you need to do to make Immer work with comparisons. You literally just use it as described in the docs. Specifically for comparisons, `PureComponent` and `React.memo()` both do shallow comparisons of `props` by default. Yes, the pervasiveness of Immutable.js's API is one of the reasons I've long suggested that folks avoid it [2]. I don't have any detailed suggestions for migrating, other than perhaps consistently using Reselect selectors to encapsulate reading values from the store and handling the Immutable.js -> `toJS()` conversion (which you should probably be doing anyway as a perf optimization, since that conversion is relatively "expensive"). That way, as you switch over chunks of reducer logic from Immutable.js to Immer, the code consuming those values _should_ still be getting POJOs out of the selectors, with no actual visible change. [0] https://redux.js.org/recipes/structuring-reducers/immutable-update-patterns https://redux.js.org/recipes/structuring-reducers/immutable-... [1] https://daveceddia.com/react-redux-immutability-guide/ https://daveceddia.com/react-redux-immutability-guide/ [2] https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra...
  - cagmz 7y ago
    OT: how do you know when it's time to add an immutable library as a dependency (as opposed to following immutable update patterns in vanilla JS)?

aidos 7y ago

I assumed it was some sort of port, but they’re totally different things! OT but it’s worth reading the code for immerjs. It’s super small, super clever and shows the power of proxies in js.

acemarke 7y ago
Yep. Michel Weststrate is a genius, and also an all-around nice guy. I hope to have a chance to meet him in person. (For reference, I'm a Redux maintainer. We now recommend Immer as the best way to write immutable update logic in Redux apps, and use it in our Redux Starter kit package.)
- akuji1993 7y ago
  Saw this code in a client's redux project, it was awesome to see that. So much easier than how we were about to do our very complex state updates. It takes away a lot of the complexity. Immediately copied that and showed it to our webdev channel.
  - acemarke 7y ago
    Glad to hear it! Please let me know if you have any further feedback from using it. Here's the current roadmap towards 1.0: https://github.com/reduxjs/redux-starter-kit/issues/82 https://github.com/reduxjs/redux-starter-kit/issues/82 I just pushed out a breaking set of changes a few days ago, and will likely make one more set of breaking changes to `createSlice` in the near future. After that, I'm hoping the API will _mostly_ be good to go, and I can push it towards 1.0 in the very near future.
- k3liutZu 7y ago
  Immer looks awesome but we're relying on Immutablejs shallow object comparison to stop rendering React components when not needed. When I last checked I could not figure out how to achieve the same thing with Immer. Do you know some reference that addresses this? And if we're here an additional question: since our store data is currently composed of deep immutable JS data structures, do you know of a way to slowly migrate to Immer? I've tried to move parts of the store to Immer, but since the root store obejcts are still Immutable js objects, this didn't go well.
  - acemarke 7y ago
    Shallow object comparison is not a special property of Immutable.js. It's just a matter of iterating over the keys and values of two objects and comparing them. In fact, that's how React-Redux (and many other React ecosystem libs) work. `connect` decides whether to re-render your component by doing shallow comparisons of the previous and current `mapState` return object to see if the extracted values have changed. All that's necessary is to do immutable updates of your data, by always making _copies_ of the data and modifying the copies (see [0] and [1] for discussions of immutable updates). It doesn't matter whether the new object references were produced by manually creating copies ( `{...obj}`, `someArray.map()`, etc), by using Immutable.js's API, or Immer tracking the "mutations" via a proxy and creating the new references internally. As long as you have immutable updates and new references, shallow comparisons work fine. So, there's nothing special you need to do to make Immer work with comparisons. You literally just use it as described in the docs. Specifically for comparisons, `PureComponent` and `React.memo()` both do shallow comparisons of `props` by default. Yes, the pervasiveness of Immutable.js's API is one of the reasons I've long suggested that folks avoid it [2]. I don't have any detailed suggestions for migrating, other than perhaps consistently using Reselect selectors to encapsulate reading values from the store and handling the Immutable.js -> `toJS()` conversion (which you should probably be doing anyway as a perf optimization, since that conversion is relatively "expensive"). That way, as you switch over chunks of reducer logic from Immutable.js to Immer, the code consuming those values _should_ still be getting POJOs out of the selectors, with no actual visible change. [0] https://redux.js.org/recipes/structuring-reducers/immutable-update-patterns https://redux.js.org/recipes/structuring-reducers/immutable-... [1] https://daveceddia.com/react-redux-immutability-guide/ https://daveceddia.com/react-redux-immutability-guide/ [2] https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra...
- cagmz 7y ago
  OT: how do you know when it's time to add an immutable library as a dependency (as opposed to following immutable update patterns in vanilla JS)?