[acemarke]

`redux@^4` currently has two dependencies: `symbol-observable` for compat with observable libs, and `loose-envify` for compat with Browserify. I plan on removing both of those when we release Redux v5.

Our official Redux Toolkit package [0], which is now our recommended approach for writing Redux logic, _does_ have a few more deps: Immer, Reselect, Redux-Thunk, and the Redux core. But, those are all things you probably would have had in your app anyway.

If you're not familiar with Redux Toolkit, it includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once.

I just published a brand-new "Redux Essentials" core docs tutorial [1], which teaches beginners "how to use Redux, the right way", using our latest recommended tools and practices. I'd encourage folks to check it out.

[0] https://redux-toolkit.js.org

[1] https://redux.js.org/tutorials/essentials/part-1-overview-co...

[spanhandler]

Thanks for your work on it. I've found Redux super-helpful and pleasant to use for multi-platform JS UI work, in particular, to bundle HTTP client (and other network services, if not in the browser) libs behind a common, small, well-understood-by-React-devs state interface. I'm a huge fan of dependencies I can abuse—fake-up in an afternoon on unsupported platforms in another language, rip out of one place and cram in another without a fuss, stuff like that. Redux is one of the rare deps in JavaScript I never feel queazy about including in a build.

I'm too out-of-the-loop these days to know what Immer is, will have to give it a look.

[acemarke]

Thanks!

Quick summary:

Immer is an incredibly useful immutable update library, created by Michel Weststrate (author of MobX).

It exports a single function `produce(originalState, updateCallback)`. The callback receives a `draftState` value that _looks_ like your original state, but has been wrapped in an ES6 Proxy. You can then "mutate" the draft all you want. Internally, Immer tracks all the mutations, and the final result is a safely immutably-updated value.

It drastically simplifies immutable update logic - no more nested spread operators!

See https://immerjs.github.io/immer/docs/introduction and https://redux.js.org/recipes/structuring-reducers/immutable-... .

Redux Toolkit comes with Immer built into our `createReducer` and `createSlice` APIs automatically.

[the_other]

When I first came across Immer, I wasn’t impressed. I though “If you’re going to the trouble of using functional-ish state management, why add a “mutations-like” API in there. Surely you’re “crossing the streams?”

But then a couple of weeks later I had to wrangle data in subsections of three “slices“ of state at the same time.

Immer lets you focus on just the state you want to change, and hides the problem of maintaining the state you don’t want to change. Brilliant. I’ll take the “it looks like mutation” hit for that.

[acemarke]

Yeah, Dan's pointed out a number of times that even with FP and immutability, _local_ mutation is fine. After all, the mechanism for immutable updates is to make copies of the original data, and then mutate / overwrite pieces of the copies.

Immer just does that in a really slick way.

My only concern for using Immer by default in RTK is the potential that someone would learn Redux by osmosis through looking at a codebase where every reducer is doing `state.someField = someValue`, think that actual mutation _is_ the right way to use Redux, and then try to do the same thing in another project and actually mutate data for real.

I can't prevent that, so my only answer was to repeatedly emphasize in this new tutorial that you _must_ do immutable updates, and that you can _only_ "mutate" inside of RTK's APIs thanks to Immer:

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

- https://redux.js.org/tutorials/essentials/part-3-data-flow#s...

But yeah, the massive improvements in code size and readability are more than sufficient to justify the small potential downside there.

[azangru]

> I plan on removing both of those when we release Redux v5.

Gasp! Will redux store no longer be an observable then?

[acemarke]

`symbol-observable` is just a polyfill lib for `Symbol.observable()`. Worst case, we copy-paste the 2 lines of code directly into our codebase just to remove that dependency. The Redux store will still implement the observable contract.