More explicit relationship between queries and mutations for the "same" data

[AmyBlankenship]

It's really common for a form to get the original state of data to populate the form (or show empty for new data), then create or update the data. So we logically have one getter and then one or more setter mutations used in that same View. This becomes slightly messy, especially if the View is set up as recommended in the docs, where you deconstruct all your state variables out to individual variables (which you then have to name appropriately).

We already have a loose relationship among these endpoints defined in the tags, and I wouldn't want to lose that, because it allows for some occasional out-of-the-box thinking. But it would be very cool if there were an "official" way of generating a set of endpoints that are all notionally considered to be editing the "same" data and that share a common "loading" state (note that the fact that isFetching is "anytime the query is doing something" and "isLoading" is "anytime a mutation is doing something" make it a bit of a problem to decide which of these should be used in this situation).

The motivation behind this is I use RTK Query to reduce the amount my Views have to get involved in stitching together stuff from different hooks, but the fact that get/post/patch, etc. to the same url become different hooks means I wind up with what feels like a bit of mess around my RTK query code. I can see there might be some issues with trying to do this, especially if users set them up incorrectly, so I could imagine that an interim step toward this might be a section in the tutorial showing how to make a hook that pulls related queries/mutations together into a single hook. This would at least offer people a standard approach in the interim that would help determine if users have problems writing their endpoints in a way that generated hooks would make sense (and give a starting point for a future migration strategy). I believe I have the skills to write this type of tutorial if that was the direction you decided to take.

[markerikson]

I've seen some other folks play with "generate CRUD resource sets" ideas (particularly @Exerosis in Reactiflux). Not sure there's anything specific we can / want to do here.

Specific docs PRs / examples are definitely welcome!

[markerikson]

I'll throw in a link to the "RTKQ Pain Points" thread in #3692 just to create the connection.