I'm sorry to tell you this, but the style of Redux you are displaying here is a very outdated style that we are no longer teaching for production use. Modern Redux (since 2019) does not use switch..case reducers, ACTION_TYPE constants or immutable reducer logic and is as a consequence a lot more concise and readable.
I would urge you to check it out by following the official Redux tutorial at redux.js.org/tutorials/essentials/... and it would be very great if you could update the article to showcase modern Redux or at least add a warning at the beginning - still far too many people are learning old-style Redux and new articles in that style unfortunately contribute to that problem.
First of all, this specific project was created about a year ago, so it's inevitable that there is some outdated stuff. You are correct in that I should put a warning at the beginning, I was thinking about this yesterday.
As for the rest of the comment, I suspect that you are referring to using RTK instead of vanilla Redux. When I wrote this code, I was currently learning Redux and I didn't want to dive into abstractions like RTK without taking the time to consider what they are doing for me. I think that every developer should do the same: Create his own action types as stated in the official Flux documents, instead of letting RTK do it for him behind the scenes, learn how to write immutable logic (which I think is really important in itself) and more importantly, WHY he should never mutate the state as stated in the official Redux style guide , etc.
The code I wrote demonstrates the Flux state management architecture, which fundamentally relies on switch..case reducers, immutable data structures and ACTION_TYPE constants. It was written while learning Redux and I think that everyone new to Redux should write at least one project in this way, especially if he is new to Flux state management in general!
Mark Erikson commented something similar on the previous part, I suggest you read my response to your fellow-maintainer. I don't really like magic, I always look under the hood 🧙
P.S.: I am currently working on an Electron application and I really enjoy using Redux Toolkit. I am gonna write a post on it soon! ✌️
Well, in the official tutorials we essentially have two learning paths:
Learn Vanilla Redux, followed by a "learn RTK" and with the preface of "never do this in production". That is the fundamentals tutorial.
Learn RTK directly, Vanilla Redux when you want to get to internals later. The essentials tutorial.
Both learning paths are perfectly viable - as long as the "this shows the internals, never do this in production" sticker is big enough.
We get people into chat on an almost daily basis that are implementing Vanilla Redux in their application after following a tutorial without that warning that are overwhelmed by the amount of concepts and frustrated by the amount of code they have to write.
And telling them that the style of Redux they are learning right now is outdated by 2+ years does not make them a lot happier, since at that point they have burnt a lot of their time.
So, by now, I am very eager to see that "warning label" pretty much everywhere, but especially in new posts.
Also, even for Vanilla Redux, the Redux Style Guide is still very much something we would love to see taught, so even if you are showing how stuff works under the hood, you are not doing your readers a big service by showing a split into multiple files between actions, constants and reducers - even if you write it by hand, we are very much encouraging putting all of that into one file to reduce indirection. (redux.js.org/style-guide/style-gui...)
So maybe that could be a way to go about it and at least reduce indirection in this article a bit?
I am using "single slice files", like you are mentioning, in a medium-sized app and they are not aging very well. Having state, actions, reducers and selectors, all in a single file does not scale well. Especially when following the "ducks" folder structure, a single feature can very well have 50 action types, 50 reducers and 30 selectors, for example. That could mean an over 1000 line file. Nobody wants to work with that. I think that following the single-file approach is better suited to something like RTK, where you omit creating action types.
Splitting those in separate files and exporting them from a single index.js file seems the way to go, IMHO. Of course there are mistakes and I don't claim that my approach is perfect. There are many (mainly structural) changes I want to make.
However, the code was written one year ago, I am glad that I made mistakes that I can now acknowledge. That's why I plan to refactor and post updates, but this is something I don't have the time to do right now. Moreover, I like to be able to see my progress. I am certainly going to put a warning note, though!
Regular "thick" reducers. All API related stuff lives in thunks. It's just a very big module using vanilla Redux.
In an Electron application, where I am using RTK, it scales really well. I think that you have made a great job both in writing the docs for Redux and RTK & in the RTK development itself, it saves from a lot of hassle.
The point I am stretching here is that in order to appreciate and understand RTK or any other abstraction, you have to get your hands dirty first. Keep up the good work 😊
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi, I'm a Redux maintainer.
I'm sorry to tell you this, but the style of Redux you are displaying here is a very outdated style that we are no longer teaching for production use. Modern Redux (since 2019) does not use switch..case reducers, ACTION_TYPE constants or immutable reducer logic and is as a consequence a lot more concise and readable.
I would urge you to check it out by following the official Redux tutorial at redux.js.org/tutorials/essentials/... and it would be very great if you could update the article to showcase modern Redux or at least add a warning at the beginning - still far too many people are learning old-style Redux and new articles in that style unfortunately contribute to that problem.
Hi, thanks for the feedback!
First of all, this specific project was created about a year ago, so it's inevitable that there is some outdated stuff. You are correct in that I should put a warning at the beginning, I was thinking about this yesterday.
As for the rest of the comment, I suspect that you are referring to using RTK instead of vanilla Redux. When I wrote this code, I was currently learning Redux and I didn't want to dive into abstractions like RTK without taking the time to consider what they are doing for me. I think that every developer should do the same: Create his own action types as stated in the official Flux documents, instead of letting RTK do it for him behind the scenes, learn how to write immutable logic (which I think is really important in itself) and more importantly, WHY he should never mutate the state as stated in the official Redux style guide , etc.
The code I wrote demonstrates the Flux state management architecture, which fundamentally relies on
switch..casereducers, immutable data structures andACTION_TYPEconstants. It was written while learning Redux and I think that everyone new to Redux should write at least one project in this way, especially if he is new to Flux state management in general!Mark Erikson commented something similar on the previous part, I suggest you read my response to your fellow-maintainer. I don't really like magic, I always look under the hood 🧙
P.S.: I am currently working on an Electron application and I really enjoy using Redux Toolkit. I am gonna write a post on it soon! ✌️
Well, in the official tutorials we essentially have two learning paths:
Both learning paths are perfectly viable - as long as the "this shows the internals, never do this in production" sticker is big enough.
We get people into chat on an almost daily basis that are implementing Vanilla Redux in their application after following a tutorial without that warning that are overwhelmed by the amount of concepts and frustrated by the amount of code they have to write.
And telling them that the style of Redux they are learning right now is outdated by 2+ years does not make them a lot happier, since at that point they have burnt a lot of their time.
So, by now, I am very eager to see that "warning label" pretty much everywhere, but especially in new posts.
Also, even for Vanilla Redux, the Redux Style Guide is still very much something we would love to see taught, so even if you are showing how stuff works under the hood, you are not doing your readers a big service by showing a split into multiple files between actions, constants and reducers - even if you write it by hand, we are very much encouraging putting all of that into one file to reduce indirection. (redux.js.org/style-guide/style-gui...)
So maybe that could be a way to go about it and at least reduce indirection in this article a bit?
I am using "single slice files", like you are mentioning, in a medium-sized app and they are not aging very well. Having state, actions, reducers and selectors, all in a single file does not scale well. Especially when following the "ducks" folder structure, a single feature can very well have 50 action types, 50 reducers and 30 selectors, for example. That could mean an over 1000 line file. Nobody wants to work with that. I think that following the single-file approach is better suited to something like RTK, where you omit creating action types.
Splitting those in separate files and exporting them from a single index.js file seems the way to go, IMHO. Of course there are mistakes and I don't claim that my approach is perfect. There are many (mainly structural) changes I want to make.
However, the code was written one year ago, I am glad that I made mistakes that I can now acknowledge. That's why I plan to refactor and post updates, but this is something I don't have the time to do right now. Moreover, I like to be able to see my progress. I am certainly going to put a warning note, though!
That kinda sounds like you are really overusing that. Are those real "business logic" reducers or is that just api interaction stuff?
Regular "thick" reducers. All API related stuff lives in thunks. It's just a very big module using vanilla Redux.
In an Electron application, where I am using RTK, it scales really well. I think that you have made a great job both in writing the docs for Redux and RTK & in the RTK development itself, it saves from a lot of hassle.
The point I am stretching here is that in order to appreciate and understand RTK or any other abstraction, you have to get your hands dirty first. Keep up the good work 😊