IMO Hooks is the best thing that happened to React. Once you get used to it it is a lot more clean and productive. It requires you to unlearn a few things though, e.g. don't think about component lifecycles, but think about data flow/changes. Once you get used to it is a lot more productive and enjoyable way of developing React apps.
I believe it would have been better to have Hooks as a separate library, not part of React. For the developer it is just another design pattern, not really an improvement, especially if you look at all the edge cases and issues you'll find around.
Personally I don't like the design pattern, a matter of taste. But it's very annoying now in the market to have mixed React and Hooks codebases, with all their issues..
How about you don't make it personal, and limit whatever criticism you have to technology. And why not include actual criticism, rather than just stating that you personally are not a fan. Thanks for the pointless comment otherwise.
I'm pretty sure hooks weren't his idea. Can't remember where he said that. The fact that he enjoys communicating doesn't mean he is the only one working on react.
I think React hooks are silly but Redux is an OK solution to a certain problem, and one of the nicer major libraries in all of JavaScript land, wildly better than almost anything else of similar prominence (it's fairly small and IIRC it has one dependency, with one other transitive dependency, and that's it). I don't see the philosophical or practical connection between the two.
`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.
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.
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!
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.
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:
`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.
