Skip to main content

Dispatching multiple Redux actions

I was working in my Redux app today and was facing the question of how best to submit a “create” API call to the backend and then transition to a “confirm” page. I wired up my router to be sensitive to the Redux store, so a reducer could trigger the page change.

I’m using redux-pack to handle async events, which I find quite pleasant so far (though I haven’t gotten deep into testing it, which is a bit awkward because it requires faking out some internals).

One solution is to have the component that is handling the “submit” button dispatch the API call action and then use the Promise that redux-thunk provides as a return value to chain the router action. But, the Promise will always resolve when the action completes, even if the API call was not successful, leading to some awkwardness in detecting if the create actually happened without error before doing the redirect.

I also have a fantasy of generically dispatching actions via POSTs on the backend (“isomorphic Redux,” if you will) so having that chained logic in the component isn’t ideal.

My current solution is to have two reducers each listening to the “submit” action. One updates the UI to include the response from the submission, the other changes the router state. Both of these use the “success” case of redux-pack’s handle method, so both will happen only if the API call goes through.

While this feels very “Reduxy” from the perspective of “reducers just interpret actions! There’s no direct 1-to-1 correlation!” I worry that it presents a maintenance problem in the future. One reducer is in an obvious place, and the other one is hidden away under a “route” namespace. The odds are good that someone it the future will bang their head trying to figure out how the damn routes are changing on submit.

Some Googling led me to this “Can I dispatch multiple actions from Redux action creators?” article by James K Nelson. I actually really like this approach, which is to have one action trigger others (perhaps by using redux-thunk). It feels nice to remove this logic from the component, while still allowing for focused sub-actions (“make API call” and “change route”) that discoverably map to specific reducers.

I’m also mildly interested in trying out the “Ducks” approach to co-locating action creators and reducers, based on the observation that co-locating logic, rendering, and presentation in React was a big win for rapid, stable development. It also lends itself to co-locating selectors, which is something that Dan Abramov has been advocating.


Popular posts from this blog

Separation of Concerns Leading to Implicit Dependencies

I’ve been building a toy app to feel out server-side React, Redux, GraphQL, &c . to explore ways to build my next webapp(s). One thing this has introduced me to is react-router . react-router has good support for SSR because it lets you statically determine the set of Component classes that match a route so that you can load their data before rendering them. Its route descriptions allow nesting, which translates interestingly to your rendered UI. Here’s my routes.js file: <Route path="/" > <IndexRedirect to="/rails/rails" /> <Route path=":ownerName/:repoName" component={App}> <IndexRoute component={IssueListPage} /> <Route path=":number" component={IssuePage} /> </Route> </Route> This is used to make pages that look something like these: (When in doubt, make a GitHub viewer.) The App component renders the header with the repo name, and react-router passes it a child component,

Convention vs. Abstraction to Prevent Bugs

When I was working on Blogger, I caught the dependency injection bug and led a conversion of the frontend code to a new, DI-heavy pattern. This greatly helped our testability, as it let us move away from the service locator   anti-pattern we had been relying on. I got a bit carried away, though. One piece that I generalized out was the concept of a link to another part of the UI. All these links had to have a blogID query parameter to work, but exposing that to the page controller was a mixture of concerns, right? We could instead inject type-checked BlogUri representations of these URLs into the page controllers, and they could render them without ever having to know the right blogID to use. This code enforced that you could never write bugs about linking to the wrong page, or using the wrong blogID parameter. Useful, right? Nope. Those are two bugs that people basically will never write. If you’re on a settings page, linking to a template page, there’s no circumstance wh