Have you ever wanted to respond to a change in your Redux store’s state by dispatching another action?

Now you know that this is frowned on. You know that if you have enough information to dispatch an action after the reducer does its thing, then it is a mathematical certainty that you can do what you want without dispatching another action.

But for some reason, you just don’t care. Maybe your store is structured in such a way that it is easier to send requests after an action is processed. Maybe you don’t want your actions or components to be in charge of fetching remote data for each new route. Or maybe you’re just a dark side kind of person. Whatever the reason, actors will allow you to dispatch with impunity.

Why you need actors

But before we jump into the details, lets review the alternative: connect. Here’s an example using react-redux:

class Counter extends React.Component {
  render() {
    return (
      <button onClick={this.props.onIncrement}>
        {this.props.value}
      </button>
    )
  }
}

const CounterContainer = connect(
  state => ({ value: state.counter }),
  dispatch => ({ onIncrement: () => dispatch(increment()) })
)(Counter)

const targetEl = document.getElementById('root')

ReactDOM.render(
  <Provider store={store}>
    <CounterContainer />
  </Provider>,
  targetEl
)

Instead of subscribing to the store’s state and rendering the UI explicitly, we’ve delegated the job of re-rendering to the connect function. The simplicity here is beautiful, but it presents a problem to us dark-siders: connect renders every state that the connected data passes through, even when we don’t want it to.

But don’t we want to render every state? Not if we’re dispatching actions after actions. For an example, what if we want to fetch out-of-date data after each action is processed?

store.subscribe(function fetcher() {
  const state = store.getState()
  const location = state.navigation.location

  switch (location.name) {
    case 'documentList':
      if (outOfDate(state.data.documentIndex)) {
        store.dispatch(data.document.fetchList())
      }
      return

    case 'documentEdit':
      if (outOfDate(state.data.document[location.id])) {
        store.dispatch(data.document.fetch(location.id))
      }
      return
    }
  }
})

Each time our subscriber receives a new state, an additional fetch action may be dispatched. This will cause your app to render once after an action is processed, and then again if fetch is dispatched. This is bad for performance, but more importantly, it will flash out-of-date data on screen — which looks terrible.

And that’s why we need actors!

What are actors?

Actors are a sequence of functions which are called each time your store’s state changes, with one important exception: they aren’t called in response to actions dispatched from other actors.

Each actor receives your store’s dispatch function and current state. The upshot of this is that if an actor dispatches an action, the next actor’s state will reflect the result of that action.

If this sounds at all complicated, it won’t after you see the implementation:

// An array of actor functions taking a `state` object and `dispatch` function
var actors = [ ... ]

var acting = false
store.subscribe(function() {
  // Ensure that any action dispatched by actors do not result in a new
  // actor run, allowing actors to dispatch with impunity.
  if (!acting) {
    acting = true
    actors.forEach(function() {
      actor(store.getState(), store.dispatch)
    })
    acting = false
  }
})

And now you can dispatch with impunity, safe in the knowledge that your final actor will receive a state object which takes into account any actions dispatched by previous actors.

Examples of actors

Knowing what actors are is half the battle; the rest is knowing how to use them. With that in mind, I’ve put together some examples of actors I use.

redirector(state, dispatch)

Redirecting is one of those things which probably should be handled before your store even knows about the new URL, i.e. in an action creator. But even so, I find this actor from the Unicorn Standard Starter Kit easier to grok than any action creator based approach:

function redirector(state, dispatch) {
  const {name, options} = state.navigation.location || {}
  const currentURI = window.location.hash.substr(1)
  const canonicalURI = name && ROUTES.generate(name, options)

  if (canonicalURI && canonicalURI !== currentURI) {
    // If the URL entered includes extra `/` characters, or otherwise
    // differs from the canonical URL, navigate the user to the
    // canonical URL (which will result in `complete` being called again)
    dispatch(navigation.start(name, options))
  }
  else if (name == 'root') {
    // If we've hit the root location, redirect the user to the main page
    dispatch(navigation.start('documentList'))
  }
}

fetcher(state, dispatch)

Say you have a route which renders data from your store, but that data needs to be fetched from an API before you can use it. How do you fetch this data?

• Option 1: Call the API in the action creators which navigate to that route. Just hope that these actions are the only place you need the API.
• Option 2: Dispatch fetch actions from your route Containers. Just hope that you don’t want to display any metadata about the fetch process – or you’ll get that pesky double-render.
• Option 3: Make a fetcher Actor.

To me, it feels like the Dark Side is actually less dark than the alternatives:

function fetcher(state, dispatch) {
  const location = state.navigation.location

  switch (location.name) {
    case 'documentList':
      if (outOfDate(state.data.documentIndex)) {
        dispatch(data.document.fetchList())
      }
      return

    case 'document':
      if (outOfDate(state.data.document[location.id])) {
        dispatch(data.document.fetch(location.id))
      }
      return
    }
  }
}

renderer(state, dispatch)

This is the actor which every application has. It usually sits at the end of your actors sequence, rendering the result of the preceeding actors.

Your renderer can be implemented with anything: Vanilla JS, jQuery, riot.js, the list goes on. Personally, I use React:

var APP_NODE = document.getElementById('react-app')
function renderer(state, dispatch) {
  ReactDOM.render(
    <Application state={state} dispatch={dispatch} />,
    APP_NODE
  )
}

But what is this <Application /> component? Think of it as a nexus; it accepts the entire application state, then uses that state to decide which view to render.

Great, but how do I make this work with my router?

If you’re using react-router, then your <Router> component does most of the job of <Application> for you. The problem is that it doesn’t do the most important part; it doesn’t pass state or dispatch through to your route handlers.

One solution is to wrap your <Router> component with an <Application> component which passes state and dispatch to your route handlers via a React Context. But if that sounds a little complex, there is a simpler way: doing the routing yourself!

function Application(props) {
  const location = props.state.navigation.location

  switch (location.name) {
    case 'documentEdit':        
      return <DocumentContainer {...props} id={location.options.id} />
    case 'documentList':
      return <DocumentListContainer {...props} id={location.options.id} />

    default:
      return <div>Not Found</div>
  }
}

But how do you go about writing Container components now that you don’t need connect? How do you resolve routes and store them in state.navigation?

All will be revealed in my free guide to Simple Routing with Redux and React! Join my newsletter now to make sure you don’t miss out. And in return for your e-mail, you’ll immediately receive three print-optimised PDF cheatsheets – on React (see preview), ES6, and JavaScript promises. All for free!

One more thing – I love hearing your opinions, questions, and offers of money. If you have something to say, leave a comment or send me an e-mail at james@jamesknelson.com. I’m looking forward to hearing from you!

Read More

• Learn Raw React
• Learn why you need Containers: Smart and Dumb Components by Dan Abramov

Related Projects

• See actors in action in Unicorn Standard’s Redux/React Boilerplate