Consider rethinking tutorial sequence #371
Comments
|
I would love to get involved with this, bit so far I haven't been using RTK, nor TypeScript with it. But I'm happy to discuss this further if you would be interested. |
|
Might need a little help but I'd love to work on this |
|
FWIW, I think we could try a different example which is a more verbose than a to-do app, especially in the advanced guide |
|
What about a full App with router and multiple pages? Maybe use: material-ui, axios, ... Different routes could do similar things but using different libraries. Others could easily fork the project to show off a different way of doing something by just adding a new route. Comparing code between folders makes it easy to see the pros and cons of different solutions/libraries. This can help show off a reference architecture/best practices. Simple hello worlds still can exist for some routes. Tutorials will focus on explain the code in one route at the time. Building up from Basic to quite Advanced ones. |
|
@andreawyss : that sounds way more complicated than I want to do. Remember, the goal here is to teach how to use Redux Toolkit, specifically. At the moment, we're orienting the docs towards "you already know how to use Redux, here's how RTK is different", but it would be nice if we could include some info on the Redux core concepts as well. I don't want to show sagas at all, because most apps don't use them and we don't include them in RTK. I don't want to spend time on things like using Material-UI, because that's not relevant to teaching RTK. |
|
Maybe build a counter, but as it counts, it does a new API call to avatars.adorable.io That way you can sneak thunks in, the API is extremely simple and just change RTK0@adorable.io to RTK1, RTK2, RTK3 etc. etc. would display a different avatar face / color etc. it would be slightly more interesting as the pics are funny faces randomly generated by the email like identifier. While not adding too much complexity to explaining the key RTK concepts. Also would offer a chance to explain to novices the concept of a isLoading value and how that is handled in RTK? |
|
Actually, I think it'd be nice to have an example which isn't a counter for once 😅 Perhaps it could be another example besides the counter but it'd be refreshing to have a non-todo-list-or-counter example. |
|
@sreetamdas I think the concept of a beginner tutorial being simple enough to grasp yet engaging is important, and I think that async should be involved in beginner tutorial as well, in a very simple way. That was where my head was coming from. |
|
Just from my experience from workshops: |
I agree that async should be introduced much earlier in docs, but maybe not necessarily in tutorial, but rather in usage guide or something similar. Quick lookup section that explains the async necessities like how thunks are to be used now with RTK concepts. |
|
I would love to help out with this in any way I can. |
|
I'd love to give a crack at this. It seems the existing Todo app provides a decent starting point, just rewriting it from scratch. I'll take a look over the next week and come up with some text to poke at, if that's alright. |
|
@markerikson I'm considering two substantial changes to the tutorial approach and wanted to get your thoughts before going down the rabbit hole: 1. Flipping the order of discussion between the tutorials. To me, it seems like the primary use case people have is creating slices, versus individual action creators or reducers with payload-free actions. It feels like those are special cases, versus everyday occurences. By doing the slice tutorial first, I feel that lets programmers get what they came for up front. If they do need to create single action creators, or create payload-free reducers, or share actions between slices, these cases can be outlined in the last tutorial, as "expert features" in a sense. This would introduce RTK from the top down versus the current bottom-up flow. I feel that could help developers see their code in action, get a feel for it, then let them dive into the details once they have a lay of the land. Async would remain as the middle tutorial. 2. Significantly expand application design discussion. Since the current tutorial is a pure conversion, it didn't need to talk about why data is organized into slices or how actions align with reducer functions. The Redux tuorial does this, but I'd like to walk down those avenues in detail here as well. This would give the reader an idea of not just how RTK works, but also how to design for it, in a format that helps the reader see how to build the app start to finish. The main drawback is this will make these tutorials much larger. I'm contemplating ways to signal experienced Redux users about the specific parts that are the meat of RTK, so they can skim the design elements, but I also want to help developers who are still somewhat new to Redux. |
|
@landisdesign : for reference, I'm planning on writing a new "Quick Start" tutorial page for the Redux docs in the very near future. That page will teach Redux itself, using a top-down approach, by showing how to use RTK. Once that's done, I intend to rewrite the existing Redux core tutorial sequence. It will still be a bottom-up approach, but it would culminate in "now that you know how to do this stuff by hand, here's how to use RTK so it's easier - use it as the default". That brings up the question of what the RTK docs should be covering, and how. My main points of concern with the existing RTK tutorials are:
I'm less concerned about trying to teach Redux itself in the RTK tutorials, although I do think we need to actively direct folks over to the Redux core docs more clearly. I think I've got a note along those lines at the start of the Basic tutorial, but not in the RTK getting started page. It would probably be good to list what points we want to cover and what target audiences we're aiming for, and try to sketch out a revised set of RTK docs based on those points. |
|
@markerikson Makes sense. I'll put something together in the next couple of days. |
|
@markerikson With your points in mind, I'll focus on rewriting the existing counter and to-do's from scratch. (Sorry, @sreetamdas!) For the advanced tutorial, I'm thinking of creating a color picker app that fetches data from https://reqres.in/ that @phryneas references. For the Basic Tutorial, since we are starting from the ground up, versus conversion, I'd like to reverse the order of function introduction. My personal experience of action and reducer creation is working on the actions, then reducers, then using that to configure the store. So that introduces the functions as:
For the Intermediate Tutorial, trying to rebuild the existing ToDo app seems way too big. Creating a much smaller version, with minimal styling, might do the trick. I would outline the components without attempting to explain them to any real extent, but the reader would be able to enter them in and see it work. For the Advanced Tutorial, the color picker would be a simple drop-down of colors, fetched from the above source. Choosing a color shows the color as a PANTONE square below the drop-down. Perhaps adding to a list of "previously picked colors" with Thoughts? |
|
I'll have to think about it a bit. I'm admittedly still kind of attached to the current tutorial sequence in some ways, both because it's there already and because I wrote it. Tell you what, go ahead and try sketching out what you think you might want to do for these, and we can discuss further. Also interested in any thoughts on how we can reuse / repurpose the existing tutorials. |
|
Ahh, yeah, I definitely know that feeling. Let's see how this comes together: Overall, for each of the tutorials, I'm thinking of a basic outline of
This feels like this will give the reader steady progress to a satisfactory conclusion. The counter example code feels good as-is. Its small size lends itself to being walked through quickly, start to finish, to cover the bases needed in the Basic Tutorial. My concern with the ToDo example is that, as an example, it's sweet and elegant, but if we're aiming to show how to build from scratch with RTK, it feels rather large. I'm concerned about trying to walk a reader through from inception to finished product. Perhaps there can be a line drawn somewhere that says "From here on out, you can copy the components from the repo to hook up your RTK learnings to a real application." This could be a way to retain the current app's structure and leave the rest as a copy/paste exercise. The same size concern applies to the example in the Advanced Tutorial as well, but to an even greater scale. Again, a nicely designed application, but doing it from scratch seems like it will be even longer than the conversion tutorial as it stands. I personally didn't have the stamina to walk through it when I was first learning. The main focus for me in the Advanced Tutorial is using thunks. With that in mind, it feels like creating a small app devoted to that specific focus could lend itself to the subject in a shorter format. Data retrieval feels like the main example. The less data massaging or manipulation involved, the more the thunk usage would stand out. When I looked at the data coming from https://reqres.in, it looked nicely digestible and presentable. It might make sense to separate the TypeScript usage into its own tutorial, perhaps rewriting one of the earlier apps with TypeScript in mind ("You've seen how to build this with RTK. Now let's look at it with RTK and Typescript."). How does this sound? Let me know if there's things I should consider or change focus on. |
|
Advanced tutorial felt like a tutorial about using typescript with redux... It would be really great to have a separate advanced tutorial without typescript.. |
|
Some feedback on the current RTK docs: Not sure I agree with the criticisms, but FYI. |
I read through the reddit thread and jumped through those docs. I think they're just suggesting we split the Usage Guide up into simple, rapidly consumable sections that are the recommended conventions only and don't focus on the why so much. I suppose we could always add 🤛's to code samples as well. Overall, RTK's docs explain 'how and why' and elaborate on the reasoning a lot more than easypeasy's docs. The flow of RTK's content is the same, just presented differently and a bit more verbose. I think I can see the benefit of splitting the usage guide into clear sections and doing the same with the TypeScript guide. Although we do that already, I think it's a presentation issue more so than anything. I could take a crack at that later this week after I address the other pending docs requests to see how it'd feel? |
|
Sure, interested in seeing what you come up with. |
|
I have read the basic and the intermediate tutorials. In the advanced one, I gave up. There's too much mixed contents with RTK itself. It sounded like the docs assuming the following things:
Don't get me wrong about 1, I do know what Redux is all about, but I'm used to write in Angular, so About 2, I have a fresh Typescript React app that I want to implement RTK in it, but the docs were mixing lots of non RTK specific stuff and I'll elaborate:
I guess that what I'm trying to say is, split the tutorials from the actual usage. Maybe try to reorganize the docs by different topics. For example:
|
|
@Newbie012 thanks for the feedback. Responding to your comments:
Even if we do restructure the tutorials, I'm not sure there's going to be a set of pages that serve the "Angular user" viewpoint. Redux is ultimately going to be used with some UI layer, and since that's normally React, any examples will be using React-Redux. The overall intent of the "Advanced" tutorial page was to show a more "real-world"-ish usage case. Since Create-React-App is the most common React app setup, the example is based on that. The point of the HMR was to be able to hot-reload both React components and reducer logic, without needing to refresh the whole page every time. I haven't worked with Next.js, so I don't know how you set up HMR for it. We can't cover every possible build tooling variation out there, even with multiple tutorial pages - it's just not feasible. I do agree that the tutorials need to be rethought and split up, per this thread. We also need to explicitly list assumptions and prerequisites at the start of each page to help folks know what they're getting into. That's something I'm trying to do as I write a new set of tutorials for the Redux core docs. Writing tutorials is hard, because we've got to balance trying to teach concepts, keeping things simple enough that the user can learn what's actually being taught, and at the same time meaningful enough that the user sees the purpose and motivation behind why and how to do things. |
I didn't say that there should be tutorials for Angular users. I stated the fact that I'm a "newcomer," and I believe that this library can be perfect for people who don't want to learn deep the official React-Redux.
And that's perfectly fine. I didn't ask for a tutorial that describes how to integrate with NextJS. I think you did an excellent job with this lib and the tutorials. I can't imagine how hard it was to create those very descriptive tutorials, and for that, I want to thank you. To wrap up, I guess that it's your decision if you wish just React-Redux devs to use the lib or any newcomer that interested in an alternative. That's just my thoughts. I'm sure some people will disagree with my opinion :) |
|
Yeah, I'd certainly like any and all Redux users to use RTK, whether or not they're using React. That said, there's only so much effort we (I) can devote to writing the docs. I do want to have a new "Using Redux with a UI" section in the Redux core docs, which would cover how to use it with React, Angular, Vue, vanilla JS, etc. That won't come for a while, though, and given how closely Redux is associated with React, it's reasonable to assume that they're being used together and write the tutorials accordingly. |
|
To @Newbie012's point, do you want the RTK tutorials to build on Redux, or be able to stand alone? |
|
@landisdesign : sorta seeing two different interpretations of your question, so I'll try to answer them both. I can write a state-only bunch of code with RTK, the same way I can write state-only code with a plain Redux store. But, a real app will always have some actual UI, so a tutorial should also show how you'd use RTK as part of an actual app with UI setup, ie, React, meaning use of React-Redux. In terms of whether the RTK tutorials should assume pre-existing knowledge of Redux or not... that's kinda the question we're trying to figure out here. If we assume no prior knowledge of Redux, how much of those Redux core concepts should we be explaining? Seeing What I'm trying to do with the new Redux core "Quick Start" tutorial is spend just enough time introducing the core Redux concepts, but then show the RTK APIs as the default way to write code for those concepts. |
|
@tim-rohrer I'd go one step further and question the tradeoffs of testing reducers and selectors. IMHO Kent Dodds has the right ideas when it comes to testing: https://testing-library.com/docs/react-testing-library/intro. Isolated tests that test how things work are brittle and make refactoring expensive. Test your features instead :) |
|
@RyanAtViceSoftware that becomes more of a philosophy question than a "what should the tutorial/API provide" question. @tim-rohrer, in terms of testing code that takes advantages of the RTK, I'd definitely recommend testing your logic, not RTK's. Test the functions being passed into RTK, not the output. Let RTK handle the rest. |
|
@landisdesign, I agree with that and remain happy to be testing the code I write. I do understand the idea of testing features, and avoiding testing implementation details, but am not convinced those are black and white scenarios. Reducers and their associated action creators reflect the results of things done by users. I want to be confident those results are predictable and repeatable. That said, I also recognize most of the code I add to Given that I am quite possibly the least experienced developer in this thread, I am a primary consumer of tutorials. I believe I have finally developed enough basic methods to test most of my code without retesting this great library; however, imo, it took me too long to get to this point, and I am hopeful that future documentation can shorten that curve. @markerikson, and others: Thank you for your hard work and conversations here and in Reactiflux. |
|
I will add my voice here. The way the documentation is written even for the basic tutorial makes it more or less necessary to study the old way of using Redux. I believe you should have a completely separate section for comparison or migration concerns. Have a look at easy-peasy documentation:
Their documentation is crystal clear and there must be a reason if they have 3.5k stars. I understand you certainly spent a lot of time on the documentation but believe me, as said, by several people, the current documentation is confusing as hell and is too much work and ceremony for those who start learning Redux now. |
|
I do want to reiterate that RTK truly is a layer on top of the Redux core. Even if you're not writing a bunch of action creators by hand, you do still need to know what "actions", "action creators", "reducers", "immutability", and "dispatching" are. Those are all Redux core concepts, not RTK concepts. I realize that this does make it a bit difficult to teach RTK by itself. I'm starting to think that maybe what we ought to do is put, very very clearly, that you should spend time reading the Redux core docs first, and then come back to the RTK docs specifically. As I've said a couple times in this thread, the new Redux "Quick Start" tutorial I'm working on will be the "intro to Redux with RTK as the default way to write Redux code" that people are asking for. I'd rather not duplicate that content between both docs sites. |
|
It has nothing to do with having to deal with actions, reducers, dispatching and immutability. The fact is that your tutorial is really a tutorial on how to convert an existing redux application the RTK way. Take the following sentence at the very beginning of the basic tutorial from the point of view of someone that decided to learn Redux :
It's not that this is conceptually difficult ... it's just that one suddenly realizes that he will basically have to learn the old way for making sense of this documentation ;). But I feel stupid here, I did not realize that you were writing a new tutorial using the RTK way. I will check it as soon. Thanks. |
|
@FredericLatour right , like i just said, I agree that focusing the tutorials on migrating existing apps isn't the right approach. Problem is, you're then left with two options :
But if we go with the second option, now we're basically duplicating the Redux core docs, albeit maybe with a different spin on the explanation, and I don't want to have to maintain either copy-pasted docs pages or come up with equivalent but different tutorial content. So yeah, I'm still struggling to figure out what the RTK tutorials should explain, and how they should explain it. |
|
@markerikson there is no way that someone shouldn't understand how redux works before using RTK. I don't even understand how that would work. I think
Is the right idea. But I'd probably rephrase it to be more
at the end of the day, all RTK is is a boilerplate plate reducing tool for doing idiomatic redux. |
|
@RyanAtViceSoftware I completely disagree with your comment (with all due respect). Now I completely understand the maintenance burden that @markerikson has to deal with. At the very least, he will need a guide using the new syntax from the ground up if he wants to attract people more largely. And this is what he is doing. |
|
@FredericLatour no need to worry about disagreeing that's the point of these discussions is to find the right idea by debating the merits of the various options. In that spirit I'd have to vote against your recommendation. Thinking you can have developers be successful with RTK on a real project without them being intimately familiar with not only the basic concepts of redux but also the idiomatic approaches is a recipe for failure and big delays late in your project. Things that RTK obfuscates:
The moment that their is a need to get closer to the metal with Redux everything will come crashing down if your devs don't understand these concepts. Additionally, if users don't understand the boilerplate involved then what's the motivation for using RTK in the first place? It's simply a tool that encourages best practices while reducing boilerplate. My vote is that the goal of this project needs to be a tool that reduces boilerplate while allowing folks to follow best practices. Not as a tool that encourages folks to use Redux without having the read the manual first. |
|
@RyanAtViceSoftware You can have a clear understanding of the overall Redux concepts without having even started to learn the implementation details.
You can come up with this remark with mostly any changes/improvement in the computing area. Abstracting complexity away is always a balance.
The motivation of using RTK would be to use a state management solution with as less boilerplate as possible. If RTK is a tool that encourages best practices, why should I even care with the boilerplate it removes. It's difficult to counter-argue any better because obviously, I don't know much about the implementation details of redux vs rtk and can't say for sure if it's a vital information to know the older way. If what you say is true anyway, maybe Redux is just not for me after all. I'm not completely set on everything but in most cases, I believe I will be happy to handle state (with swr or react-query) at the component/view level. |
|
@FredericLatour if you can't clearly articulate the benefits of redux you are leveraging then IMHO you probably shouldn't be using it. Dan goes through this in this excellent blog post: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367
RTK isn't a state management solution. It's a set of utilities for working with Redux. If you don't want to learn redux, then you shouldn't use redux or RTK. |
|
@FredericLatour tell you what. Go read through that WIP "Quick Start" tutorial I've linked and see if it is roughly what you're looking for in terms of instructional content. |
|
Hi guys, Even though I was tempted to go directly to easy-peasy for it's simplicity and concise and straight to the point documentation, our discussion piqued my curiosity and I decided to add additional efforts into RTK and Redux, wether I'll be using it or not. I spent quite some hours now on. So let me provide some additional feedback. First of all regarding my discussion with @RyanAtViceSoftware , I stand on my position. Everything that is part of Redux concepts is part of RTK (reducers, actions, action creators, ). RTK, is not just a couple of helper functions (even though it provides a couple of them that you can mix with old way). If you take the full of it, you just have a completely new syntax for implementing the Redux pattern. The documentation starts like this:
There is therefore no reason why one could not learn Redux using RTK syntax only. @markerikson : On the documentation side of things, a couple remarks:
Not only, I guess most devs will already know that, but this has nothing to do with the subject and it adds unnecessary cognitive load. I also took the time to read the "new Redux Quick Start tutorial" and here are a couple of remarks:
I know my comments may feel unappreciative while you are obviously doing a great job with redux ( I will certainly get a couple of thumbs down for that ... but I'm fine with that ;)) and I had some hesitation providing such feedback. But honestly, I believe that such a documentation will hurt significantly the attractiveness of Redux and more specifically RTK which is supposed to be an answer to boilerplate criticisms and the increasing adoption of alternatives. You had a discussion sometimes ago with someone on reddit regarding how confusing the documentation was. I can say, I had the exact same feeling as this guy. I know writing documentation is not an easy exercice but I believe you should really try to simplify stuff, refactor structure and maybe give it to someone that is maybe more synthetic. Just to make it clear, I'm not insinuating I could do better. Highlighting weakness and problem is way easier than doing the stuff. In the end, this is just a one guy opinion. Do whatever you want with it :) |
|
@FredericLatour : appreciate the feedback. Busy atm, so let me hit one point specifically: Immutability is an absolutely critical aspect of Redux, and users must understand that concept in order to use Redux correctly. Redux Toolkit's use of Immer hides the fact that the updates are being applied immutably. The code you're writing is mutating the state, and the only reason it's safe is because Immer is trapping those mutations and replaying them to generate a safe immutable update. If users jump straight into RTK and only see examples of I love Immer and the way it lets me simplify my reducers. I never want to write another nested spread operator by hand again. But, if users don't understand the underlying principles behind how you would write Redux code by hand (and immutable updates in particular), they're going to end up completely misusing Redux and writing code that is wrong. That's why, even if RTK is the recommended way to write Redux code, it's critical that they still understand the core concepts behind Redux. We may not have to go into a ton of detail on "here's the old way, here's the new way", etc, but the principles and terms are required understanding whichever syntax you're using. As for the Redux core docs: yes, I'm very well aware that the current main tutorials do things "the old way". That's literally what I'm trying to fix right now. I have a mile-long list of all the pages in the docs I plan to rewrite: Unfortunately, I'm the only one putting any effort into doing so atm, and so it's going very slowly. |
|
@markerikson Yes, I know that you are using immer. But the sentence I propose summarizes what's going on:
This is way enough in the quick start. I will add that you enter into way too technical details but you are not even explaining the point of immutability in the context of Redux (even though the section is called Basic Concept and Structure. I mean the guy that will be learning Redux does not expect to know everything just after a quick start. While learning technical stuff, we need different level of reading. I would add that it's difficult to imagine that devs using React don't have a good understanding of immutability. |
|
Some more excellent feedback from HN, at https://news.ycombinator.com/item?id=23563364:
The "Quick Start" tutorial I'm writing now for the Redux core docs should cover the main stuff they're asking for. |
|
Just a note, I got into RTK with barely knowing Redux and I'm super happy with it. |
|
Circling back around to this issue. Two more thoughts: First, given that we now have the new "Redux Essentials" and "Redux Fundamentals" tutorials in the Redux core docs, I'm really questioning just how much of a tutorial we should have in the RTK docs and what it should cover. Frankly, I'm almost tempted to just remove these RTK tutorials entirely and point over to those new Redux core tutorials instead :) Second, some more feedback from Reddit ( https://www.reddit.com/r/reactjs/comments/jtyshu/what_are_the_current_trends_for_state_management/gcazrxc/?context=3 ):
Follow-up comment:
On the other hand, someone on Discord was saying the other night that they basically learned Redux itself from these RTK tutorials, along with RTK itself. I'd definitely be open to having some kind of a real "Quick Start" one-pager that focuses on just some quick copy-pastable examples, but I still don't have time to work on this myself atm. That could be more interesting now that we have the new TS/JS Markdown plugin that lets us write TS codeblocks, compile them to JS, and show them in selectable tabs. |
|
I would opt to just have a "tutorials" page that links to the redux tutorials section. Aside from that, maybe a small "quick start" and a "migrating to RTK" part, but the RTK docs don't need to be much more than the API docs I believe. Oh, and thinking about it, and we could probably do with a little more docs on |
|
As a new user, I found the beginner tutorial has been greatly enhanced with the new input from Tania Rascia, but the intermediate and advanced are much less useful because they deal with migrating an older application, and swapping of code equivalents. RTK looks like a breath of fresh air, introducing concepts like It is still hard to learn the new way without example when much of the web advice relates to standard redux. I think your new intermediate teaching path target should be to show a best practice example of RTK slice that includes nested entity links (eg. {books} being referenced by {authors}, {commenters}, and {comments}) with the CRUD path for edit and removal of a linked item (such as "delete a book" also deletes relevant comments). I would suggest simplifying the code into 2 steps:
|
|
@madbiker88 : as I said earlier, these tutorials were really written with the assumption that you know how to write Redux code already. That's why the tutorials don't explain what Redux is, and do focus on migrating code. I spent much of this year writing two new tutorials for the Redux core docs: "Essentials": teaches "how to use Redux, the right way" by building a real-world app: https://redux.js.org/tutorials/essentials/part-1-overview-concepts "Fundamentals": teaches "how Redux works, from the bottom up": https://redux.js.org/tutorials/fundamentals/part-1-overview I don't have time to rewrite the RTK tutorials from scratch as well, and so far no one else has stepped in and actually tried to help with them. At this point I'm about ready to just delete the existing RTK tutorials and add a page that points to the Redux core docs tutorials instead. |
|
I've just published some major updates to the RTK docs:
This resolves the concerns raised in this thread. New pages:
I did add a link from the "Tutorials Overview" page to the legacy "Basic/Intermediate/Advanced" tutorial Markdown files in the repo as they existed before I deleted them, so the content is still accessible. |
|
Your updates to the manuals are a huge piece of works and I appreciate the effort that has gone into them. You might be surprised how often I have reread them.
I had seen the latest changes a few hours before this post and have been working through them.
You are clearly a 10 on the scale of experience and I an a 3-4 cut that give a different view, and I am willing to assist if I can.
Currently I am working on a SVG project involving drawing custom SVG graphs using D3 via the visx React library as a hobby project. My application data uses multiple createEntity objects in the same slice because they are so closely related.
I am currently moving the app to typescript. Typescript is new to me, but I have got past most of the Redux type casing. The extensive use of generic types in visx is currently doing my head in.
Anyway back to the topic –
* Feedback on RTK docs is that the code examples with typescript separate from JavaScript is really useful to me, so I hope that your JS/TS style can be continued, though it is clearly more work.
As I started in JS, my reducers did not use the builder pattern. I am confused, because you say in Redux that this is really important, but RTK example also does not use it. Is builder only needed outside createSlice?
Example is https://redux-toolkit.js.org/tutorials/typescript as features/counter/counterSlice.ts.
export const counterSlice = createSlice({
name: 'counter',
// `createSlice` will infer the state type from the `initialState` argument
initialState,
reducers: {
increment: state => {
state.value += 1
},
decrement: state => {
state.value -= 1
},
// Use the PayloadAction type to declare the contents of `action.payload`
incrementByAmount: (state, action: PayloadAction<number>) => {
state.value += action.payload
}
}
})
* In https://redux.js.org/tutorials/essentials/part-4-using-data : preparing action payloads, you comment that reducers should never create random values and I have heard the same from other sources. I assume this is for jest testing reasons.
However your example just below it in features/posts/postsSlice.js does exactly that inside the prepare function using the naonid() function. You also talk about the optional meta and error fields, but there is no example anywhere on how to use these. I think the prepare example is useful, but it would be more useful if you should change the code to something that is not random, or better still change the example to something that returns an error. I would love to know how to reject an action with error. I know some say all checking should be done before dispatch, but the slice is also a keeper of App logic and I think it should be able to reject incompatible data, just I personally do not yet know how to reject a redux action and return with an error and have not seen an example, and have no idea what a real life example using meta might be used for.
In my case I did use a prepare function and called a fuction using local variable and checking that the id did not exist already. You can use it if you wish – the slice is called tasksSlice with both tasks and links being EntityAdapters within the same slice.
import { RootState } from './rootreducer'
const sliceName = 'tasksSlice'
// set numbers for assigning next ids
let nextTaskIdNumber: number = 10
let nextLinkIdNumber: number = 10
// getters for next unused ID numbers
const getNextTaskId = (state: RootState) => {
//console.log('checking next number taskId', current(state))
while (state.taskSlice.tasks.entities[nextTaskIdNumber]) {
// check for existing and get next if required
// am not using uuid to avoid randomness during testing
console.log(
'Info: PreExisting id was found for new taskId at ',
nextTaskIdNumber,
' so ID skips to next number'
)
nextTaskIdNumber++
} // end of while statement
return nextTaskIdNumber
}
*edited to remove email contents*
|
|
Glad to hear you've been reading the docs! The issues really aren't a good place for us to provide support. I'd recommend asking in the That said, some quick answers:
|
I've had a few folks say that they had trouble following the tutorials for different reasons:
I'd be open to the idea of redoing the tutorial sequence in some other way. Perhaps the existing pages could be semi-converted into "Usage Guides" of some kind: Intermediate -> "Migrating Existing Redux Apps", and Advanced -> some combo of "Adding Redux to a React App" and "TypeScript Example"?
But, that means we'd need to rethink what the tutorials should cover, and rebuild them from scratch.
I don't have time to do this myself right now, since I'm focused on the Redux core docs rewrite, but if someone else wanted to tackle this, I could offer guidance.
The text was updated successfully, but these errors were encountered: