Redux Reference

Contents

• Redux Terminology
• Commands
• Redux Toolkit (RTK)
  • Async Thunks
  • Entity Adapters / Reducers / Components
• Resources

Redux Terminology

action

a message containing a “payload”

dispatch

function for passing actions to be processed by reducers

payload

the JavaScript object passed via an “action” which will be processed by the reducers

reducer

the function that accepts previous state and an action, returning a new state that, if needed, updates the store

slice

(Redux Toolkit) a convenience wrapper bundling a store, reducers, and actions; represents the entire stack of a specific segment of application state

slice

refers to a literal “slice” of data; can be thought of a way of segmenting state into multiple distinct pieces

store

an object containing a “plain JavaScript” object representing the state of the application

Commands

Create a new project:

$ npx create-react-app experiment-redux-todo --template redux

Redux Toolkit (RTK)

Async Thunks

Reducers should be pure: they should have no side effects. How should one then make requests or log data? Enter the thunk.

A “thunk” refers to deferred work, and “async” refers to the function’s execution context (asynchronous). An async thunk is just like a normal redux action but instead of an object is a function. This allows the function to be executed—in the async thunk case, asynchronously—and called with additional arguments. When created using createAsyncThunk there are a series of arguments—most importantly payloadCreator—that allow you to specify how this function behaves when processed by Redux middleware.

Best practices:

• limit your async thunk payload creator functions to just performing the asynchronous actions; isolate any state modification logic to reducers
• always return data that will be passed as action payloads on success
• always reject with data, for passing as action payloads on rejected
• understand the meaning behind the name of the argument: “payload creator”; it is a function that creates the payload you will be passing to all reducers listening for that action
• consider moving error state to the redux store
• consider using cancellation to prevent a thunk from firing
• minimize the number of dispatch(someOtherThunk()) calls within a thunk—this can make the redux console hard to follow; prefer listening for .pending, .fulfilled, or .rejected events in the reducer (those will fire before the createPayload is called

Keep in mind:

• unhandled errors will be silently ignored: you must reject if you wish to do something about it
• you can either return or throw thunkAPI.rejectWithValue(...)

Entity Adapters / Reducers / Components

Best practices:

• use the DisplayNode pattern: extract all cross-slice logic into a single “display” object that you then store in its own slice. This prevents having components that need to query cross-slice or query multiple objects to determine how to display. Basically: if you have complex query logic in your components, you likely have that logic in the wrong place. Put it in the reducer.

Resources

• redux.js.org
  • Documentation
  • Tutorials
  • API Reference
• Releases
• redux-toolkit.js.org
  • configureStore
  • createEntityAdapter
• On Async Thunks:
  • Redux Fundamentals, Part 6: Async Logic and Data Fetching
  • "How to dispatch a Redux action with a timeout?"
  • "Why do we need middleware for async flow?"

Understanding middleware and async actions:

• Answer to How to dispatch a Redux action with a timeout?
• Answer to Why do we need middleware for async flow in Redux?