Redux Reference

Contents

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

Terminology

action

1.

A message containing a “payload”

Related:

• dispatch
• payload
• reducer

dispatch

1.

Function for passing actions to be processed by reducers.

Related:

• action

payload

1.

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

Related:

• action

reducer

1.

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

Related:

• action
• slice
• store

slice

1.

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

Related:

• reducer
• slice

slice

1.

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

Related:

• slice

store

1.

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

Related:

• reducer

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?