Hacker News Reader

Comment by ratww | Hacker News Reader

Not OP but: You probably know the answer to your own question, since I'm guessing you made Toolkit to scratch your own itch! :) The "Redux Experience" is a bit overwhelming, boilerplatey, verbose and full of gotchas. Structures are all over the place. IMO that is solved by Toolkit.

The only problem with Toolkit is that it's not Redux. People don't know it yet, and I have to fight to convince people it's good enough. In an ideal world for me you'd be able to deprecate old Redux and just replace it with Toolkit.

View on HN

I'm not sure what you mean by "it's not Redux".

It's still 100% Redux. You create reducers, add them to a store, dispatch actions, and read that data in your components. None of that has changed. You're just writing less code to do it.

What RTK does is eliminate the "incidental complexity" that came along with the original Redux usage patterns: writing action types and action creators by hand, writing complex nested immutable update logic by hand, making a mistake in that immutable update logic and causing accidental mutations, etc [0].

I do understand the suggestion to "replace the Redux core with RTK", and I take it as a great compliment that people suggest that. However, it can't happen, because a lot of people are already using Redux with their own customizations and abstractions. Changing the Redux core to suddenly include a bunch of other dependencies would not be what they want.

The other aspect is that the Redux core was designed from the beginning to be unopinionated, while RTK is _deliberately_ opinionated. Not all Redux users want RTK's opinions. As it is, we've had folks who didn't like the fact that RTK _is_ opinionated and requires use of Immer in our `createReducer` and `createSlice` APIs.

We had a long discussion issue about whether it made sense to add things like this to the Redux core (which was actually part of what prompted us to create RTK in the first place) [1].

FWIW, we explicitly recommend RTK as the standard way to write Redux logic [2], and now that Redux Toolkit 1.3 is out with some new APIs [3], my next task is to create a new "Quick Start" tutorial page for the Redux core docs [4] that does actually teach Redux using RTK as the default syntax, ie, "this _is_ how you write Redux code", in the same way that the Apollo docs teach Apollo-Boost as the default way to use Apollo.

[0] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...

[1] https://github.com/reduxjs/redux/issues/3321

[2] https://redux.js.org/style-guide/style-guide#use-redux-toolk...

[3] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.3.0

[4] https://github.com/reduxjs/redux/issues/3674

Maybe "it's not Redux" is meant in the same way as "Toyota Camry isn't Car". It's a car, but you can have a car that isn't a Camry.

Otherwise, I'm really not sure what that "it's not Redux" comment means, either.

edit: Oh, crap, I just made a software/car analogy. I hate those.

To stay on analogies, it's more like GNU and Linux.

Vanilla Redux on its own is like Linux without an userland, so you have to implement yourself.

Redux Toolkit is a proper Linux with GNU userland. It's ready to use, and people can even use each other's computers without reading through the source code!

It doesn't make a lot of difference for smaller projects, but the thing about Redux is that as soon as you have 20+ or 30+ people working on the same codebase you get a hodgepodge of different patterns and structures. Toolkit solves it.

I mean the problems is that it's not Redux itself. People have to actively look for RTK to use it, and few do. I wish you guys had replaced Redux with RKT and moved redux to @reduxjs/core like proposed on the issue and proclaimed "Redux is dead, long live Redux!"

Starting a project with Vanilla Redux is like starting a Vanilla PHP or Vanilla Javascript project: you're on your own. And most people don't really have a very big grasp on the full concept and just blindly follow some rando tutorial they saw in 2017 or 2018, because that's the best they can do.

That's kind of fine! I don't really mind using different architectures, or even different frameworks. But in large projects the inconsistencies from different approaches generates bit rot and lot of bikeshedding.

I find RTK really good (maybe I'm biased because I've been using Immer from day 1), but that's beside the point: the best part is that it removes the least productive and most boring parts IMO of building software in large teams: bikeshedding, boilerplate and lack of structure in large projects.

As I said, we're in the process of rewriting the docs (and by "we", I mean "me", because I'm not getting any assistance with it so far). The "Quick Start" page I'm about to write will show RTK as the default, and we'll emphasize that elsewhere throughout the docs as they get rewritten.

There's also nothing we can do about the 5 million existing tutorials out there on the internet, and it's not like the core APIs would be _removed_. All those are still syntactically valid. Even if we shipped all these additional APIs as part of the core, people would have to look to see that they exist.

Reply on news.ycombinator.com