Mark Erikson: The thing is, the docs showed a pattern of organizing your different types of code into different files, and then organizing those files into folders by type. So you have a reducers folder, an actions folder, a constants folder etc.
A guy named Erik Rasmussen actually came up with a pattern for putting all the logic for a given feature into one file, which he named the Ducks pattern. A small segment of the Redux community adopted it, but we didnât officially suggest it. And I always had a couple concerns about it, particularly about how it kind of suggests that only one reducer can never handle an action of a given type, when really the intent was any reducer can respond to any action.
So given that these are specific pain points that people talked about, how does Redux Toolkit try to address them? The docs say that I created Redux Toolkit really to solve three different problems. Itâs too hard to set up a store, you have to add a bunch of extra packages to do anything useful, like Redux Thunks, and Reselect and whatnot⌠And it requires too much boilerplate code.
Item one, Redux Toolkit has a function called configureStore, that is a one-line call. You provide either the reducer function youâve already built yourself, or the slice reducers for the different features, and it will assemble them itself. It automatically sets up the Redux DevToolsâ browser extension setup that is needed, and it automatically adds the Redux Thunk middleware, and in development mode a couple of dev check middleware that will throw errors if you do things like accidentally mutate any state in the store⌠So protecting against by far the most common mistake that people make when using Redux.
From there, thereâs a couple of utilities like createAction, which generates action creators based on a given type string⌠And createReducer, which allows you to define reducers using an object look-up table syntax rather than a switch statement, because for some reason a lot of people really hate switch statements.
And createReducer also uses this Immer library inside to let you write what looks like mutating syntax in your reducers, but itâs actually turned into safe, correct, immutable updates internally. So from there, we have an API called createSlice, and weâve traditionally used the word âsliceâ to refer to the reducer for a single part of your Redux state. For example, if I have a blogging app with state.users, state.posts and state.comments, the users reducer and the users actions represent a slice of your state.
[31:55] So createSlice builds on createAction and createReducer. You give it a set of reducer functions in an object, and you give them meaningful names. Giving the classic to-do app example, todoAdded, todoToggled, changeFilter, stuff like that⌠And it automatically generates the action creators and the action types internally, based on the names of the reducer functions that you provided. And this actually gets to that grepability factor that you were asking about earlier.
One of the advantages of having all those action types as const variables in the codebase was that you could look at the Redux DevTools and see âOkay, I dispatched the Add_todoâ action type, and now I can Ctrl+Shift+F, search the whole codebase textually for uses of that action type.
Well, weâre actually now recommending that people use a naming pattern where the string is lower camel cased, and you define it as domain-eventname. For example, maybe the domain is todos/todoadded, rather than upper screaming snake case AddToDo.
