Can we use `batch` with `createAsyncThunk` to dispatch multiple actions alongside the `fulfilled` action?

[calvinwyoung]

Suppose I have a thunk created with createAsyncThunk, and due to various implementation constraints, that thunk must dispatch multiple actions during execution.

In order to reduce the number of re-renders, I can use react-redux's batch() API to dispatch all intermediate actions in a single render update. However, once the thunk returns, it will also dispatch a .fulfilled action, which will trigger another render.

Is there a way to include the .fulfilled action in the same batch() as the intermediate actions such that the entire async thunk will trigger only a single render update?

[phryneas]

React will only rerender if one of your components actually subscribes to a state value that is changed as a reaction to that .fulfilled action.

That said, no, that is not possible, I couldn't think of how that would be implemented as well.

My question would be why you dispatch additional actions that should take place the same moment as .fulfilled in the first place, as most of the time that would be an antipattern.
The recommendations from the style guide would be to Model Actions as Events, Not Setters and to Allow Many Reducers to Respond to the Same Action there.
Having multiple events at the same time would mean that you are not doing that.

[calvinwyoung]

@phryneas Thanks for the quick response — all of that sounds very sensible. Agreed that the design isn't ideal, but there are a couple of quirks that make this difficult to untangle.

As a side note, your work on #547 should help alleviate at least some of the issue, so I'll be very excited to see that move along :)

[phryneas]

Now I've got to ask: why do you dispatch multiple actions at the same moment there?

[calvinwyoung]

Suppose we have a redux store with the following slices:

• entity-1: Stores entity data for Entity1
• entity-2: Stores entity data for Entity2
• ui: Stores UI-specific information related to multiple entities
• meta: Stores derived data that should get updated whenever any entities get updated. Some of this information can't be derived exclusively from the state (e.g., undo stack), otherwise we could use a selector here.

Now suppose we have an async thunk whose response should update the ui slice, as well as the entity-1 and entity-2 slices. We could have the entity-1 and entity-2 slices listen directly for the thunk's .fulfilled action. However, we'd also like to recompute meta whenever either entity-* gets updated, and they could get updated from a number of places. Our thinking then is that it'd be better to dispatch a separate entityXUpdated that the entity-* and meta reducers can respond to.

The reason the actionListenerMiddleware could help is that in some cases, it'd be useful to trigger a side effect when meta gets updated.

Is there a better way to architect this?

[phryneas]

For example

const mythunk = createAsyncThunk(() => {
  // ...
  return {
    entityData: {
      entitiyType1: [ a, b],
      entitiyType2: [ c, d],
    },
    otherData: {}
  }
})

myEntity1Slice = createSlice({
  // ..
  extraReducers: builder => {
    builder.addMatcher(
      action => action.type.endsWith('/fulfilled') && action.payload?.entityData?.entityType1, 
      (state, action) => {
        myEntityAdapter.upsertMany(state, action.payload.entityData.entityType1)
      }
    )
  }  
})

[MatthewWid]

@phryneas as an example use case for this; contrived but based on a real situation I am struggling with.

I am using React, React Redux and Connected React Router.

---

Say my system has user accounts, and users are referenced by their username which is unique (unfortunately this is an axiom of the back-end that I cannot change - no unique and unchanging IDs). Users can visit their own profile at /profile/<username>. I have a map in my Redux store of username to account data that looks something like the following:

{
  "users": {
    "byIds": {
      "john": { ... },
      "mary": { ... }
    }
  }
}

When a user visits the profile page of a user not in the map, their account data is loaded by a useEffect in the ProfilePage component (that is wrapped by a key={username} to force a teardown and re-render of its many subcomponents) that invokes an async thunk getUserByName that adds their name and data to the map and their profile page shows their information.

The user on their own profile page can change their username, which requires me to update their name in the map. So for example we dispatch a changeUsername async thunk, and when changeUsername.fulfilled is dispatched we do the following in our reducer:

users.byIds[newUsername] = users.byIds[oldUsername];
delete users.byIds[oldUsername];

This "replaces" the username, in effect.

The problem comes where, because they are on the profile page pointing to /profile/oldUsername I need to direct them to /profile/newUsername. I do this with connected-react-router by doing:

dispatch(push(`/profile/${newUsername}`));

And I could do this either inside the changeUsername action, which unavoidably dispatches before changeUsername.fulfilled does, or afterwards, at the site that I originally called dispatch(changeUsername(...)) such as an event handler.

The problem occurs as the following things occur in order in the first case:

1. User clicks submit button and changeUsername.pending dispatches and sends a request to the server.
2. The server receives a response and dispatches the push action to pre-emptively direct them to the new profile page.
3. ProfilePage re-renders and does not find the username in the map as changeUsername.fulfilled has not yet fired.
4. ProfilePage invokes the getUserByName async thunk.
5. changeUsername.fulfilled dispatches and populates the user data and ProfilePage gets populated with information.
6. getUserByName.fulfilled dispatches and re-populates the user object with the exact same data, having no effect and wasting a network request and three dispatches.

In the second case a similar thing happens, but the ProfilePage invocation to getUserByName fails and errors because it looks up the old instead of the new username.

---

Batching the dispatch of push and changeUsername.fulfilled would resolve this issue as there is not a render of the component tree between the username update and the route change.

At the moment I'm just implementing and allowing the first case to exist as is as the user does not notice the unnecessary update, but I'm sure there is a better solution to this.