3 ms·

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 sh

• 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...
    • thebosz 7y ago
      ImmerJS is a direct replacement for ImmutableJS. We recently switched from using ImmutableJS in our Redux store to using ImmerJS. We took the approach one reducer at a time. We have multiple reducers and we're using combineReducers (the ImmutableJS one until it was completely converted). We had no issues whatsoever in the change. ImmutableJS doesn't care about plain JS objects (which is what ImmerJS reducers return) so everything worked as expected. React's shallow comparison worked as expected since ImmerJS produces new objects on mutation (just like ImmutableJS). Essentially: there is no case where ImmutableJS is needed. All functionality and benefits are available in ImmerJS which is a much easier to use library. To do the migration, we literally just used the docs on the Github repo. This was back with version 1.0 or something and it wasn't documented very well but we were able to figure it out. The first code example is how to use it with Redux. Also the section on Currying is useful. Edit to add: This is all within the context of web apps, specifically React apps with Redux. I'm sure there's probably some places where ImmutableJS is desirable, but I don't know of any.
  • 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)?