I like how simple your RTK Query example is, but I believe you've omitted connecting the API slice to the store. The connection to the store (especially the middleware) is what I found most intimidating.
This is something you will probably do once in your application and never touch again, ever. Our recommendation is to have only one api slice (there are still mechanisms in place to split it over multiple files if it gets too big) as RTK-Q actually benefits from having everything in one slice for stuff like "automatically refetch this query when I send off that mutation successfully".
Hey Lenz, I'll respond to both you and Mark in this comment.
The number of API slices
Seems I was confused here. I thought you would create a separate API slice for each entity in your application. The word "slice" is a bit confusing since usually you subdivide your Redux state into slices for each entity (like a users slice, a customers slice, an invoices slice, .etc).
Middleware is "intimidating"
I said the inclusion of middleware was intimidating because I feel like middlewares (as a general concept) are often black boxes that the average developer does not understand. Moreover, I thought you would be adding 30+ middlewares to your store, one for each API slice. I am much less concerned now that I know there would just be 1 middleware for the 1 API slice.
I appreciate the explanation of RTK-Q and I'm going to update the description of it in my post to be more positive.
You've also convinced me to give createReducer and createSlice a shot so I'll make that update too 🙂
Well, a slice of a cake does not mean that there is only one type of fruit on it, right?
It really just means a "piece" or "subdivision" of your store - what's in there can vary wildly, from "by-feature" slices to "per-type" slices to "everything" slices :)
I get that middleware are intimidating - but on the other hand it's how we abstract logic. Having people install saga and add a RTKQ saga would probably be even more intimidating for most ;)
Anyway, it's great you are open to all this and I can just encourage you to also experiment a bit with it - it's pretty magical, especially how much everything cuts down on TypeScript types.
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.
This is something you will probably do once in your application and never touch again, ever. Our recommendation is to have only one api slice (there are still mechanisms in place to split it over multiple files if it gets too big) as RTK-Q actually benefits from having everything in one slice for stuff like "automatically refetch this query when I send off that mutation successfully".
Hey Lenz, I'll respond to both you and Mark in this comment.
The number of API slices
Seems I was confused here. I thought you would create a separate API slice for each entity in your application. The word "slice" is a bit confusing since usually you subdivide your Redux state into slices for each entity (like a users slice, a customers slice, an invoices slice, .etc).
Middleware is "intimidating"
I said the inclusion of middleware was intimidating because I feel like middlewares (as a general concept) are often black boxes that the average developer does not understand. Moreover, I thought you would be adding 30+ middlewares to your store, one for each API slice. I am much less concerned now that I know there would just be 1 middleware for the 1 API slice.
I appreciate the explanation of RTK-Q and I'm going to update the description of it in my post to be more positive.
You've also convinced me to give
createReducerandcreateSlicea shot so I'll make that update too 🙂Well, a slice of a cake does not mean that there is only one type of fruit on it, right?
It really just means a "piece" or "subdivision" of your store - what's in there can vary wildly, from "by-feature" slices to "per-type" slices to "everything" slices :)
I get that middleware are intimidating - but on the other hand it's how we abstract logic. Having people install saga and add a RTKQ saga would probably be even more intimidating for most ;)
Anyway, it's great you are open to all this and I can just encourage you to also experiment a bit with it - it's pretty magical, especially how much everything cuts down on TypeScript types.