Discussion on: The Great Redux Toolkit Debate

[Sam Magura]

Thanks for the positive response!

I also don't understand why people hate switch statements 😂. Regardless, I will reconsider using createSlice!

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.

I am curious — do createReducer or createSlice work with React's useReducer? It's nice to write reducers in the same way whether you're using Redux or useReducer. Thanks.

[Lenz Weber]

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

[Sam Magura]

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 🙂

[Lenz Weber]

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.

[Mark Erikson]

Hmm. Yeah, I left out the store setup piece, but that's trivial:

import postsReducer from '../features/posts/postsSlice'
import usersReducer from '../features/users/usersSlice'
import notificationsReducer from '../features/notifications/notificationsSlice'
import { apiSlice } from '../features/api/apiSlice'

export default configureStore({
  reducer: {
    posts: postsReducer,
    users: usersReducer,
    notifications: notificationsReducer,
    [apiSlice.reducerPath]: apiSlice.reducer
  },
  middleware: getDefaultMiddleware =>
    getDefaultMiddleware().concat(apiSlice.middleware)
})

It's really only two lines: adding the slice reducer, and adding the middleware.

I'm curious, what about that aspect feels "intimidating"? I would think that the middleware setup in particular is less confusing than having to use applyMiddleware + compose with vanilla Redux.

And yes, a reducer function is just a function, and you can absolutely use reducers from createReducer/createSlice with React's useReducer hook. I've done it frequently, including in apps that weren't using a Redux store at all, because I wanted to write some complex reducers with good TS typing.