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.
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 😊