4 ms·

Yeah, we specifically built Redux Toolkit around Immer from the very first prototype that I wrote. I had catalogued _dozens_ of immutable update libs between 2

Yeah, we specifically built Redux Toolkit around Immer from the very first prototype that I wrote. I had catalogued _dozens_ of immutable update libs between 2015-2018, and Immer is simply superior to all of them. Which is why Immer is a non-negotiable part of RTK, and something we specifically tell everyone they should be using with Redux: - https://redux.js.org/style-guide/#use-immer-for-writing-immutable-updates https://redux.js.org/style-guide/#use-immer-for-writing-immu... - https://redux-toolkit.js.org/usage/immer-reducers https://redux-toolkit.js.org/usage/immer-reducers (in fact, I recently got quoted on the top of the Immer docs with a tweet I wrote saying how awesome Immer is :) https://immerjs.github.io/immer/ https://immerjs.github.io/immer/ )

TurningCanadian 4y ago
Where will the Record & Tuple proposal (Stage: 2) fit in? https://tc39.es/proposal-record-tuple/tutorial/ https://tc39.es/proposal-record-tuple/tutorial/
- acemarke 4y ago
  I'm not sure, tbh. I agree that having the ability to construct objects/arrays that are compared by nested values, rather than references, will be useful. But, given that Immer already exists, and only meaningfully requires ES6 Proxy support, I'm not sure how much of an impact the availability of Records will have. In the case of RTK specifically... Immer is built into `createSlice/createReducer`, and it's _always_ getting called even if you manually create an immutably-updated result yourself. So I don't see any real change or benefit there.