Pages

I have recently come across a situation where I needed to wait for an axios async request to complete, get the final status from the response (either a success or an error message) and then, depending on the outcome, fire off an action creator. Additionally, I needed to complete the UX journey by redirecting the user to his dashboard through React Router.

In other words, what if we want to trigger an action creator in ReactJS after the Redux application state has finished all its mutations?

Since ReactJS is based on component re-rendering, this should be an easy task right? Well...not really...Usually this is the best task for UI rendering only...but conditional action triggering is something more advanced. Most experienced developers would suggest to use an aptly lifecycle Component method, such as ComponentDidUpdate(). This works in most cases, and in general, is the most recommend method:

The problem is that these lifecycle methods, and any other methods outside the render() function, such as generic helper methods, do not work well with React Router 4, specifically <Redirect />*. So for example, in my case, I wanted a customer to pay for a subscription, then when my backend server sends a specially crafted response, this will be updated in my Redux state, and hopefully, trigger this action creator. After that, I want the customer to be redirected to a Dashboard component.

*Although we could not use the <Redirect /> method, we can use another React Router 4 redirect technique which works well with helper methods outside render() functions. This technique will be described in a future post. As a sneak peek, this entails using the this.props.history() technique.

Solution

So if I cannot listen to state changes inside a lifecycle/helper method, what is the alternative? We can always listen to state changes inside the rendered component itself. One trick I like to use is putting a ternary operation or a classic old if condition that triggers when on a state change. Remember, when the state is updated, the component is always re-rendered through React Redux until the condition is matched, and triggering the next action creator. This is the flow I am using:

Note that in my particular case, the success or error object is only made available inside the state tree once the axios operation is complete, hence why I am using the !! notation.

Remember that once the action creator is fired, remember to reset the state tree, otherwise you will end up an infinite loop and keep triggering the same action creator :)

Updated and Better Solution

There is actually a better way of doing the redirect and still using the recommended React component lifecycle methods. Since the <Redirect /> technique does not work well with these methods, I suggest to instead use this.props.history.push() inside the ComponentDidUpdate() to perform a redirect. Just remember to wrap your component with the withRouter() HOC. The code will therefore look similar to this:

Although there are differing opinions on whether accessing state in action creators is a good idea (for example, Dan Abramov strongly discourages such practice), there are some edge cases (such as checking for cached data or for authentication related situations), which will make passing the Redux state into an action creator quite a useful concept.

It turns out that Redux makes this quite easy, through the getState() function. Quoting the official Redux documentation:

getState() returns the current state tree of your application. It is equal to the last value returned by the store's reducer

So let's say we have a reducer that returns the state of a Redux Form and of the application's authentication such as the following:

For the action creator to access the auth state, all we need to do is use the getState() function. First we need to pass it as the second argument after the dispatch, and then save its return as the application state tree:

To get a specific value instead of the whole tree, since state is an object, I can use the object dot notation, as in the quoted example. Alternatively, you can use the ES6 destructuring notation: const { auth } = getState()

In general I try not to pass any state to the action creator and try to solve my problem in a different way (for example, by dispatching multiple actions). But if there are still no alternatives, at the very minimum, I recommend passing the state at the very end of the application state chain. This is to minimise the risk of application state mutation in the wrong places.

ReactJS state and prop data model is so flexible that I cannot fathom how to solve information system problems otherwise, and I keep reminding this to myself everyday I use it. Recently I came across a situation where I needed to re-use a component, passing it props from a parent component, and having the component (or global) state updated on-the-fly.

Let me briefly describe the situation I am referring to. Let's say I am using the official Stripe Checkout component to for my next SaaS application. I want to have a re-usable component so I can create a multi-tier pricing subscription plan.

The Stripe Checkout component will therefore look like this:

Notice that this Stripe component can be used by a parent component so I can generate 3 different pricing plans. This is simply achieved by calling this component three times and using the appropriate props as follows:

Now if I want to be able to set the application state for the planPrice, so other components are aware that what the chosen price is, can be simply achieved by binding an onClick function call to the Button component inside the Stripe Checkout component:

This is a very nifty trick that most ReactJS developers should be aware of. This allows us to re-use our components without losing control of the component state.