4 ms·

My point is that the code that shown in this tutorial is, from our point of view, "wrong" at this stage. We _don't_ want people writing action constants, objec

My point is that the code that shown in this tutorial is, from our point of view, "wrong" at this stage. We _don't_ want people writing action constants, object spreads, or action creators by hand any more, or splitting Redux code across separate files for "actions, constants, and reducers". We _do_ want them using Redux Toolkit as the standard approach for writing Redux logic. Similarly, while `connect` still works, we really want people using the hooks API instead. I obviously can't change the thousands of Redux tutorials that are out there already, but I really want any new tutorials written in 2021+ to be following the patterns we recommend. Using these recommended patterns results in code that is shorter, it's easier to understand, and eliminates many common bugs that we've seen over the years.

rglover 6y ago
> My point is that the code that shown in this tutorial is, from our point of view, "wrong" at this stage. That's a bummer because, to be frank, the abstractions introduced by that toolkit are anything but easy to understand. This is incredibly alienating compared to the block above it which, at the very least, clearly uses the redux package (which maps to the mental model of a beginner—if I'm using Redux, I expect to see something called Redux): https://redux.js.org/introduction/getting-started#redux-toolkit-example https://redux.js.org/introduction/getting-started#redux-tool... You even say it here: > This architecture might seem like a lot for a counter app, but the beauty of this pattern is how well it scales to large and complex apps. There's a big gap between a large and complex app and the basic parts required to comprehend what Redux is doing and why it's valuable. It sounds like you'll disagree with me but there's a ton of value in starting with the simple parts to explain the concepts (the "wrong" stuff) and then building on top of that with what the toolkit introduces. A good flow would be: 1. What is Redux? 2. What are the basic mechanics of Redux? 3. How do I build a basic Redux app? 4. How do I refactor my basic app to support a larger, complex app? Skipping straight to #4 may make sense from your perspective (assuming you're at Facebook or another large-codebase company), but from the viewpoint of a developer who's just trying to get up to speed, it's a bat to the head.
- acemarke 6y ago
  And that's exactly why we have a core docs "Fundamentals" tutorial that _does_ walk through the "how it works underneath", but culminates in "and now that you know how to write this code by hand, use RTK and never write all that extra code again: https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... But, even while the "Fundamentals" tutorial does show things like hand-writing reducers and action type strings with no abstractions, it approaches teaching a lot of the common patterns differently than we used to. It doesn't talk about "action creators" until almost at the end, there's no multiple files by type, inline type strings instead of `const ADD_TODO = "ADD_TODO"`, etc. So sure, I agree that there's value in understanding how this code works by hand. But, all older tutorials and a lot of the _new_ tutorials I see still being written don't even mention RTK at all. The "Fundamentals" tutorial clearly states up front that: > The initial code will be less concise than the way we suggest writing real app code, but writing it out long-hand is the best way to learn. Once you understand how everything fits together, we'll look at using Redux Toolkit to simplify things. Redux Toolkit is the recommended way to build production apps with Redux, and is built on all of the concepts that we will look at throughout this tutorial. Once you understand the core concepts covered here, you'll understand how to use Redux Toolkit more efficiently. Meanwhile, for people who do just want to jump in and start writing something "real", the Essentials tutorial covers that learning use case. Out of curiosity, which of RTK's abstractions do you feel are "difficult to understand"?
  - rglover 6y ago
    So, I'm confused. The links you shared covered what I covered, but your original comment made it sound as though I got it completely wrong...which doesn't seem to be the case. From what I gather, your ask is to add information about the usage of the toolkit and steer people towards that. Is that correct? If so, I don't mind adding it, but I think the existing information is helpful. Re: which abstractions are difficult to understand, the first instance of toolkit that you encounter is this: https://redux.js.org/introduction/getting-started#redux-toolkit-example https://redux.js.org/introduction/getting-started#redux-tool.... The createSlice and configureStore convention makes sense if you've used Redux before (and spend some time with it), but if you're brand new to it, the naming doesn't make it terribly clear what you're doing. The docs talk about features, but we're creating slices. What's a slice? A feature? Why not just call it createFeature? The other aspect that's confusing is that these hooks separate you from the core API quite a bit. They're obviously still there under the hood, but that disconnect means when you learn Redux now (assuming you take this blessed path), you're not really learning Redux, you're learning the abstraction that's built on top of Redux. The reason I harp on that specifically is that I teach people 1-on-1 every day and I routinely see confusion around stuff like this. You mentioned Apollo Boost in the docs somewhere as prior art and I've run into issues where both myself and people I was teaching were confused as to what it did or didn't do. From what I've observed teaching others, it helps to apply concepts in layers (like coats of paint). You're doing that somewhere in the docs as evidenced by your links, but the main Getting Started page drops devs straight into the toolkit (https://redux.js.org/introduction/getting-started#redux-toolkit-example https://redux.js.org/introduction/getting-started#redux-tool...), circumventing useful knowledge about the core of Redux. The Getting Started page is most important because, again, as I've observed people reading through docs and putting stuff together, they're big on skimming and copy/paste on first runs with new tech. This ties back in to what I mentioned above with learning the abstraction, not the core thing, which can lead to mental model issues later. For example, if I'm working on a team that's still using "old" or "wrong" stuff and a version bump isn't reasonable, and all I've learned is the toolkit method of using Redux, I'm unnecessarily stuck. If you run with the assumption that people will just linearly go through the docs, what I'm saying likely sounds crazy. But from observation, devs dart around like bees while they're learning and only pick off certain concepts as they go. The more abstractions present, the more fragmented their understanding of the tool is and the less efficacious their skillset (which leads to propagation of misunderstanding to colleagues, etc).

rglover 6y ago

> My point is that the code that shown in this tutorial is, from our point of view, "wrong" at this stage. That's a bummer because, to be frank, the abstractions introduced by that toolkit are anything but easy to understand. This is incredibly alienating compared to the block above it which, at the very least, clearly uses the redux package (which maps to the mental model of a beginner—if I'm using Redux, I expect to see something called Redux): https://redux.js.org/introduction/getting-started#redux-toolkit-example https://redux.js.org/introduction/getting-started#redux-tool... You even say it here: > This architecture might seem like a lot for a counter app, but the beauty of this pattern is how well it scales to large and complex apps. There's a big gap between a large and complex app and the basic parts required to comprehend what Redux is doing and why it's valuable. It sounds like you'll disagree with me but there's a ton of value in starting with the simple parts to explain the concepts (the "wrong" stuff) and then building on top of that with what the toolkit introduces. A good flow would be: 1. What is Redux? 2. What are the basic mechanics of Redux? 3. How do I build a basic Redux app? 4. How do I refactor my basic app to support a larger, complex app? Skipping straight to #4 may make sense from your perspective (assuming you're at Facebook or another large-codebase company), but from the viewpoint of a developer who's just trying to get up to speed, it's a bat to the head.

acemarke 6y ago
And that's exactly why we have a core docs "Fundamentals" tutorial that _does_ walk through the "how it works underneath", but culminates in "and now that you know how to write this code by hand, use RTK and never write all that extra code again: https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... But, even while the "Fundamentals" tutorial does show things like hand-writing reducers and action type strings with no abstractions, it approaches teaching a lot of the common patterns differently than we used to. It doesn't talk about "action creators" until almost at the end, there's no multiple files by type, inline type strings instead of `const ADD_TODO = "ADD_TODO"`, etc. So sure, I agree that there's value in understanding how this code works by hand. But, all older tutorials and a lot of the _new_ tutorials I see still being written don't even mention RTK at all. The "Fundamentals" tutorial clearly states up front that: > The initial code will be less concise than the way we suggest writing real app code, but writing it out long-hand is the best way to learn. Once you understand how everything fits together, we'll look at using Redux Toolkit to simplify things. Redux Toolkit is the recommended way to build production apps with Redux, and is built on all of the concepts that we will look at throughout this tutorial. Once you understand the core concepts covered here, you'll understand how to use Redux Toolkit more efficiently. Meanwhile, for people who do just want to jump in and start writing something "real", the Essentials tutorial covers that learning use case. Out of curiosity, which of RTK's abstractions do you feel are "difficult to understand"?
- rglover 6y ago
  So, I'm confused. The links you shared covered what I covered, but your original comment made it sound as though I got it completely wrong...which doesn't seem to be the case. From what I gather, your ask is to add information about the usage of the toolkit and steer people towards that. Is that correct? If so, I don't mind adding it, but I think the existing information is helpful. Re: which abstractions are difficult to understand, the first instance of toolkit that you encounter is this: https://redux.js.org/introduction/getting-started#redux-toolkit-example https://redux.js.org/introduction/getting-started#redux-tool.... The createSlice and configureStore convention makes sense if you've used Redux before (and spend some time with it), but if you're brand new to it, the naming doesn't make it terribly clear what you're doing. The docs talk about features, but we're creating slices. What's a slice? A feature? Why not just call it createFeature? The other aspect that's confusing is that these hooks separate you from the core API quite a bit. They're obviously still there under the hood, but that disconnect means when you learn Redux now (assuming you take this blessed path), you're not really learning Redux, you're learning the abstraction that's built on top of Redux. The reason I harp on that specifically is that I teach people 1-on-1 every day and I routinely see confusion around stuff like this. You mentioned Apollo Boost in the docs somewhere as prior art and I've run into issues where both myself and people I was teaching were confused as to what it did or didn't do. From what I've observed teaching others, it helps to apply concepts in layers (like coats of paint). You're doing that somewhere in the docs as evidenced by your links, but the main Getting Started page drops devs straight into the toolkit (https://redux.js.org/introduction/getting-started#redux-toolkit-example https://redux.js.org/introduction/getting-started#redux-tool...), circumventing useful knowledge about the core of Redux. The Getting Started page is most important because, again, as I've observed people reading through docs and putting stuff together, they're big on skimming and copy/paste on first runs with new tech. This ties back in to what I mentioned above with learning the abstraction, not the core thing, which can lead to mental model issues later. For example, if I'm working on a team that's still using "old" or "wrong" stuff and a version bump isn't reasonable, and all I've learned is the toolkit method of using Redux, I'm unnecessarily stuck. If you run with the assumption that people will just linearly go through the docs, what I'm saying likely sounds crazy. But from observation, devs dart around like bees while they're learning and only pick off certain concepts as they go. The more abstractions present, the more fragmented their understanding of the tool is and the less efficacious their skillset (which leads to propagation of misunderstanding to colleagues, etc).