is:open Why would you use "Posts" in the tutorials for RTK Query? Doesn't that seem like the worst name you could possibly use?

[thujone]

It just makes it that much harder to understand.

[phryneas]

It's a blog application. What else would you call them? And why does it make it more difficult for you to understand?

[thujone]

Because it’s confusing that POST is an action type. Call it BlogPost if you have to, that would be better than Post. Also the tutorial does not go in depth enough with how to add editing an existing row. It would be much more helpful if you actually had a real form with several fields instead of just one field. The tutorial seems lazy to me

…

On Sun, Mar 19, 2023 at 3:24 AM Lenz Weber-Tronic ***@***.***> wrote: It's a blog application. What else would you call them? And why does it make it more difficult for you to understand? — Reply to this email directly, view it on GitHub <#3280 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEQNDIRVPF2DTSLKTXSDBTW43NEJANCNFSM6AAAAAAV74T52M> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[phryneas]

It is not a "program with us until you have a full application" type tutorial, but one showing you every possible concept.
For the concept of learning things, it's counterproductive if there were more than just title and content, as it would distract from the content to be learned.
The point of the tutorial is not how to build forms, or how to use React, but learning to use Redux Toolkit.

As for Post: there is even a getPost endpoint. These things always exist in multiple contexts - that can't be helped either way. HTTP Verbs are very common words, and there are surely also a few other words that exist in multiple different contexts.
Tbh., it should be very apparent throughout the tutorial that we are only talking about the HTTP "POST" method when the code says literally method: 'POST'.

The tutorial seems lazy to me

Creating this tutorial took multiple dozens, if not hundreds, of hours to get to the point where it is now. This is just insulting.

[markerikson]

Yeah. As Lenz said, I spent hundreds of hours designing that tutorial and writing it. You don't have to like it, and I'm sure there's ways it could be improved, but saying it's "lazy" is absolutely insulting. Please don't do that :(

[thujone]

Ok, I'm sorry about that. And I was a little upset and frustrated yesterday, and I took a bad tone late at night. For that I truly apologize. But look, I've bought and paid for several online tutorials, and these instructors have all just copied what you have done and kind of changed some words and shuffled code around to make it seem like they didn't copy it from you, but they did. So currently there are no examples that I can find online of how an existing form with input fields hooks up using RTK Query. I WAS able to finally figure it out by putting a debugger in the edit mutation definition in the slice file. Whether the Redux team feels like they need to explain how React forms work or not, there are plenty of schmucks like me who don't the have expertise and need help to adopt RTK Query properly. Someone like me is looking for clear examples of CRUD, and not broken out into "basic" and "advanced" topics. For instance, why is DELETE considered an advanced pattern?

…

On Sun, Mar 19, 2023 at 7:32 AM Mark Erikson ***@***.***> wrote: Yeah. As Lenz said, I spent *hundreds* of hours designing that tutorial and writing it. You don't have to like it, and I'm sure there's ways it could be improved, but saying it's "lazy" *is* absolutely insulting. Please don't do that :( — Reply to this email directly, view it on GitHub <#3280 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEQNDKU7HSJ3Y5CIGB23ILW44KHBANCNFSM6AAAAAAV74T52M> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[markerikson]

@thujone : people "copying from the docs and shuffling things around" is their problem, and we can't do anything about that.

Trust me, one of my biggest frustrations is that there's thousands of outdated Redux tutorials across the web, showing patterns that we have been recommending against for years, and there's literally nothing I can do to fix those and point people to our docs and how we want people to use Redux today.

For tutorial content in general, some of the hardest things about writing a good tutorial are:

• coming up with a meaningful example application. It has to be relevant enough to help teach the concepts, simple enough that it doesn't overwhelm the user with irrelevant or distracting details, but detailed enough that it actually does demonstrate "what is this thing and why/how do you use it"
• figuring out how to build that application step-by-step in such a way that it teaches the concepts and APIs you want to explain, in the order you want to have people learn them, and actually have it all make logical sense in terms of building the app (ie, "oh, yeah, we're going to build feature D next, and that just happens to give us a good reason to learn API X as part of that")
• Being able to structure the explanations in such a way that the reader is able to learn things at an appropriate speed, understand how the concepts relate, and take them to heart
• Figuring out where to draw boundaries so that you don't have to start the tutorial with a 5-hour lecture on particle physics in order to explain silicon in order to explain CPUs in order to explain assembly in order to explain browsers in order to explain JS in order to explain the actual JS library you want to teach

If you look at Part 1 of the Essentials tutorial, it very clearly calls out the list of "prerequisites" you are expected to know already, so that the tutorial can focus on just the Redux-specific concepts and APIs. That includes HTML, JS, CSS, and React.

The "Essentials" tutorial is already 25000 words long. If I had to add in "here's how you manage forms in React", that would add another 3000+ words. I have to draw the line somewhere :)

There's a couple reasons why the RTKQ content in the "Essentials" tutorial is broken into "Basic" and "Advanced" sections. One is page length. At 25K / 8 pages, that's an average of 4000 words per page. That's a lot of reading, and it's already way longer than a lot of folks are comfortable looking at in one page. On top of that, it does neatly segregate concepts. Part 7, "Basics", covers: what is RTKQ, what problem does it solve, how do you set it up, and how do you write + use a query and a mutation. Those all go together pretty neatly. Once you've written those, you now have enough knowledge to write many queries and mutations... and that is your basic CRUD right there. Part 8, "Advanced", covers many of the optional features in RTKQ that may be useful depending on what problems you need to solve, but aren't strictly required and won't always be necessary.

So, it's not that "DELETE is an advanced pattern". A DELETE is just a mutation, and the basic idea of a mutation has already covered in Part 7.

This particular tutorial doesn't happen to deleting data. It probably would be nice if it had at least one example of that. But, per above, the tutorial is already 25K words long, and the particular example app I ended up designing is read-heavy and doesn't currently delete anything. Maybe I could look at doing that later when I redo the tutorial to be TS-first.

But, overall points:

• The tutorial is already really long
• It has to have boundaries in terms of what it assumes the reader knows so it doesn't get even longer
• It can only explain so much - it's ultimately up to the reader to take the lego pieces described and figure out how to build their own app using those

For your specific question of "examples that show how an existing form with input fields hooks up using RTK Query": there's a great post I read years ago that says "you don't need a tutorial for everything". It's usually best to break a problem down into smaller pieces, and look for tutorials that cover the individual parts. In this case:

• How do I use a form in React?
• How do I handle form data when the user is done with it?
• How do I trigger a server-side update with RTK Query specifically?

But along with that, the "mutation" example in Part 7 is the basic pattern you would generally use: a controlled input, setting state when the input changes, and passing that to the mutation trigger function on submit. And that is true regardless of what the specific HTTP method for the mutation request is.

[phryneas]

This tutorial is not meant to teach you about Forms. The most popular form library changes every two weeks, and it's not part of a Redux tutorial to teach that.

Likewise, REST, or HTTP, are not the point of this tutorial. It's shown a few times, and after that we assume that you can move on and change the word PATCH to the words POST or DELETE on your own. DELETE is not an advanced pattern. The essentials tutorial doesn't even mention it.

There is also no "basic or advanced" between "GET" and "POST" going on here.
The "basic" tutorial teaches you basic things about RTK Query: how to make an endpoint, how to use the hooks. What a query is, or what a mutation is.
The "advanced" tutorial teaches you advanced features of, again, RTK Query, nothing else. Cache invalidation and automatic refetching with tags. Dynamically injecting endpoints. Response transformation. Manual cache updates.
Nothing of these have anything to do with forms - or, really with HTTP.

You could do all of these things with HTTP, with WebSockets, with RPC calls or a client-side database. RTK Query doesn't care about that, because that's not part of RTK Query. We show a little bit how to make a few HTTP calls, because fetchBaseQuery is part of RTK Query. But fetch is not. It's a part of your browser and there are better places to read up on that. We will not incorporate every other tutorial into our tutorial, since it would be an outdated mess after 5 minutes.

If you see a tutorial that teaches you 5 technologies, you can be sure that it will be outdated on at least 4 of them. Identify your problem, ask a question, read up on that singular question. Divide your problem.

"How to use RTK Query" and "how to write a Form in React" are two independent problems. Combining them shouldn't need an individual tutorial. It's like that with most technologies. Our jobs as programmers is to learn things individually first, and then to put those puzzle pieces together.

[thujone]

Ok, thanks for your feedback on my feedback. I do appreciate it

…

On Sun, Mar 19, 2023 at 12:47 PM Lenz Weber-Tronic ***@***.***> wrote: This tutorial is not meant to teach you about Forms. The most popular form library changes every two weeks, and it's not part of a *Redux* tutorial to teach that. Likewise, REST, or HTTP, are not the point of this tutorial. It's shown a few times, and after that we assume that you can move on and change the word PATCH to the words POST or DELETE on your own. DELETE is not an advanced pattern. The essentials tutorial doesn't even mention it. There is also no "basic or advanced" between "GET" and "POST" going on here. The "basic" tutorial teaches you basic things *about RTK Query*: how to make an endpoint, how to use the hooks. What a query is, or what a mutation is. The "advanced" tutorial teaches you advanced features of, again, *RTK Query*, nothing else. Cache invalidation and automatic refetching with tags. Dynamically injecting endpoints. Response transformation. Manual cache updates. Nothing of these have anything to do with forms - or, really with HTTP. You could do all of these things with HTTP, with WebSockets, with RPC calls or a client-side database. RTK Query doesn't care about that, because that's not part of RTK Query. We show a little bit how to make a few HTTP calls, because fetchBaseQuery is part of RTK Query. But fetch is not. It's a part of your browser and there are better places to read up on that. We will not incorporate every other tutorial into our tutorial, since it would be an outdated mess after 5 minutes. If you see a tutorial that teaches you 5 technologies, you can be sure that it will be outdated on at least 4 of them. Identify your problem, ask a question, read up on that singular question. Divide your problem. "How to use RTK Query" and "how to write a Form in React" are two independent problems. Combining them shouldn't need an individual tutorial. It's like that with most technologies. Our jobs as programmers is to learn things individually first, and then to put those puzzle pieces together. — Reply to this email directly, view it on GitHub <#3280 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEQNDLV667XN5Q777JYE5DW45PE7ANCNFSM6AAAAAAV74T52M> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[thujone]

Thanks for this info, I do sympathize a lot more now. For what it's worth, I do think it's a great tutorial overall -- I described it as such to my team last week. I do have a fair amount of experience with Redux going back several years, but not in the last couple of years. So quite a bit rusty, but not altogether clueless.

…

On Sun, Mar 19, 2023 at 12:40 PM Mark Erikson ***@***.***> wrote: @thujone <https://github.com/thujone> : people "copying from the docs and shuffling things around" is *their* problem, and *we* can't do anything about that. Trust me, one of *my* biggest frustrations is that there's *thousands* of outdated Redux tutorials across the web, showing patterns that we have been recommending against for *years*, and there's literally nothing I can do to fix those and point people to our docs and how we *want* people to use Redux today. For tutorial content in general, some of the hardest things about writing a good tutorial are: - coming up with a meaningful example application. It has to be relevant enough to help teach the concepts, simple enough that it doesn't overwhelm the user with irrelevant or distracting details, but detailed enough that it actually does demonstrate "what is this thing and why/how do you use it" - figuring out how to *build* that application step-by-step in such a way that it teaches the concepts and APIs you *want* to explain, in the *order* you want to have people learn them, and actually have it all make logical sense in terms of building the app (ie, "oh, yeah, we're going to build feature D next, and that just happens to give us a good reason to learn API X as part of that") - Being able to structure the explanations in such a way that the reader is able to learn things at an appropriate speed, understand how the concepts relate, and take them to heart - Figuring out where to draw boundaries so that you *don't* have to start the tutorial with a 5-hour lecture on particle physics in order to explain silicon in order to explain CPUs in order to explain assembly in order to explain browsers in order to explain JS in order to explain the *actual* JS library you want to teach - If you look at Part 1 of the Essentials tutorial, it very clearly calls out the list of "prerequisites" you are *expected* to know already <https://redux.js.org/tutorials/essentials/part-1-overview-concepts#how-to-read-this-tutorial>, so that the tutorial can focus on *just* the Redux-specific concepts and APIs. That includes HTML, JS, CSS, and React. The "Essentials" tutorial is already 25000 words long. If I had to add in "here's how you manage forms in React", that would add another 3000+ words. I have to draw the line *somewhere* :) There's a couple reasons why the RTKQ content in the "Essentials" tutorial is broken into "Basic" and "Advanced" sections. One is page length. At 25K / 8 pages, that's an average of 4000 words per page. That's a *lot* of reading, and it's already way longer than a lot of folks are comfortable looking at in one page. On top of that, it does neatly segregate concepts. Part 7, "Basics", covers: what is RTKQ, what problem does it solve, how do you set it up, and how do you write + use a query and a mutation. Those all go together pretty neatly. Once you've written those, you now have enough knowledge to write *many* queries and mutations... *and that is your basic CRUD right there*. Part 8, "Advanced", covers many of the *optional* features in RTKQ that *may* be useful depending on what problems you need to solve, but aren't strictly required and won't always be necessary. So, it's not that "DELETE is an advanced pattern". A DELETE is *just* a mutation, and the basic idea of a mutation has already covered in Part 7. This particular tutorial doesn't happen to deleting data. It probably would be nice if it had at least one example of that. But, per above, the tutorial is *already* 25K words long, and the particular example app I ended up designing is read-heavy and doesn't currently delete anything. Maybe I could look at doing that later when I redo the tutorial to be TS-first. But, overall points: - The tutorial is already really long - It has to have boundaries in terms of what it assumes the reader knows so it doesn't get even longer - It can only explain so much - it's ultimately up to the reader to take the lego pieces described and figure out how to build their own app using those — Reply to this email directly, view it on GitHub <#3280 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEQNDKRMWEBQVIIV5A5HLLW45OJ5ANCNFSM6AAAAAAV74T52M> . You are receiving this because you were mentioned.Message ID: ***@***.***>