for Tardy React Status Indicators

The White Rabbit, Wikimedia Commons
The White Rabbit, Wikimedia Commons

In one of my favorite movies “The Blues Brothers”, the wife of the trucker pit stop owner proudly exclaims that they play ‘both kinds of music – Country and Western’. Readers of my blog know I too tend to serve two kinds of articles. In think-pieces, I tend to pontificate on a topic that buzzes between my ears that week. In ‘hey, look at this code we wrote’, I share something we learned by doing. I am sure there is an audience for both kinds but if you are in the latter camp, this is your day.

I’m late, I’m really really late

The problem we had to solve recently was as follows: a React store contains a list of items. These items are rendered in a hierarchy of React components, with a ‘dummy’ React component rendering a card for each item. The item has a number of visual elements on it that can be easily rendered from the item’s properties, but it also contains a status indicator.


This status indicator was killing us: when we fetch the array of items via the XHR API call, we can get them fairly quickly. However, each item represents an entity that can be working or not working (and therefore have a green or red status indicator). Computing this status takes a while, needs to be done separately for each item, and cannot hold the main XHR call.

We solved this problem with the help of the module (at this point I need to remind you we use Node.js for our server side). You can apply the solution even if you are not using it, nor using Node at all – just use whatever Web Sockets library comes with your stack of choice.

The devil is in the pudding

OK, on to the details. What we do is as follows:

  • Whenever we want to update the status of the store, we issue an XHR.
  • The XHR fetches the items on the server via a downstream API call.
  • Before sending the response, the server endpoint initiates an array of async parallel calls to obtain status for each of the items. It sends the response to the client without waiting.
  • The client renders the cards, with the status rendered as a gray circle.
  •  When the status API calls return, the result is sent back via Web Socket channel as an event.
  • On the client, this event is converted into a Flux action, which in turn updates the Store, which updates the views.


Produce the code

OK, enough architecture, produce the code. In the interest of space conservation, I am going to assume you have rudimentary knowledge of both React and Flux. If not, Google away until React components, dispatcher, actions and stores are all concepts that make sense to you.

Our action creator is capable of dispatching two actions – fetching items and initiation service status update:

var AppDispatcher = require("./dispatcher");

var ServiceConstants = require("./action-constants");

var ServiceActions = {
	fetchItems: function(data) {
			actionType: ServiceConstants.FETCH_ITEMS,
			data: data
	serviceStatusUpdate: function(data) {
			actionType: ServiceConstants.SERVICE_STATUS_UPDATE,
			data: data

module.exports = ServiceActions;

OK, on to the ItemStore. It is a fairly standard affair. When asked to fetch items, it makes an XHR request to the endpoint in the Node.js server that returns server items. When status update arrives, it merges the provided status with the items and fires a change event again. This will drive the view to re-render:

// Modules

var Constants = require("./action-constants");
var EventEmitter = require("events").EventEmitter;

// Globals

var AppDispatcher = require("./dispatcher");
var XhrUtils = require("./xhr-util");

var EVENT_CHANGE = "items";
var items;
var emitter = new EventEmitter();
var listeningForSocket = false;

// Public Methods ------------------------------------------------------------->

var ItemStore = {

	getItems: function(type) {
		return items;

	emitChange: function(data) {
		emitter.emit(EVENT_CHANGE, data);

	addChangeListener: function(callback) {
		emitter.on(EVENT_CHANGE, callback);

	removeChangeListener: function(callback) {
		emitter.removeListener(EVENT_CHANGE, callback);


module.exports = ItemStore;

// Private Methods ------------------------------------------------------------>

function fetchItems(url) {
	if (!url) {
		console.warn("Cannot fetch items - no URL provided");

	// Fetch content
	XhrUtils.doXhr({url: url, json: true}, [200], function(err, result) {
		if (err) {
			console.warn("Error fetching assets from url: " + url);

		items = result;

function serviceStatusUpdate(data) {
	for (var i in data) {
		var s = data[i];

function _updateStatus(s) {
	for (var i in items) {
		var item = items[i];
		if ( {
			item.status = s.status;

// Dispatcher ------------------------------------------------------------>

// Register dispatcher callback
AppDispatcher.register(function(payload) {
	var action = payload.action;

	// Define what to do for certain actions
	switch (action.actionType) {
		case Constants.FETCH_ITEMS:
			return true;

	return true;


Finally, the view. It fires the action that fetches items upon mounting, and proceeds to render the initial state with the loading indicator. Once the items are ready, it re-renders itself with the server items in place. Finally, when the status update arrives, it just re-renders and lets React diff the DOM for changed properties. Which is why we love React in the first place:

var React = require('react');
var Router = require('react-router');
var ItemStore = require('../flex/item-store');
var ActionCreator = require('../flex/action-creator');
var ActionConstants = require('../flex/action-constants');

module.exports = React.createClass({
  getInitialState: function() {
    return { loading: true, items: [] };

  componentDidMount: function() {

  componentWillUnmount: function() {

  _handleAssetsChanged: function(type) {
    if(type === ActionConstants.STATE_ERROR) {
        error: "Error while loading servers"
    } else {
        loading: false,
        error: null,
        items: ItemStore.getItems() || []

  render: function render() {
    var loading;
    var items;
    var error;

    if (this.state.loading) {
      loading = (
         <div className="items-loading">
            <div className="LoadingSpinner-dark"></div>
    else {
      items = (
          { {
            var statusClass = "status-indicator";
            if (item.status==="active")
              statusClass+= " status-active";
            else if (item.status==="error")
              statusClass+= " status-error";
              statusClass+= " status-loading";
            return (
               <li className="service-card" key={}>
                  <div className="service-card-status">
                  <div className={statusClass}/></div>
                  <div className="service-card-name">{item.title}</div>
                  <div className="service-card-type">{item.dist}</div>
    if (this.state.error) {
      error = (
         <div className="error-box">{this.state.error}</div>
    return (
       <div id='list'>
             This list shows currently available servers and their status (
             <span className="text-loading">gray</span> - loading,&nbsp; 
             <span className="text-active">green</span> - active,&nbsp; 
             <span className="text-error">red</span> - error)

The status update portion involves module. When the status is being computed, it is being emitted via the Web Socket. Of course, for this example we are faking the delay, but you can imagine actual status API request being involved:

var io = require('')(server);

function emitStatus(items) {
  var status = [];
  for (var i in items) {
    var item = items[i];
    var s = {};
    s.status = (Math.random()<.5)?"active":"error"; =;
    setTimeout(function(status) {
      io.emit("status", [status]);
    }, (Math.floor((Math.random() * 900) + 100)), s);

This status even is being picked up on the client, producing the status update action that is dispatched, picked up by the store and eventually causing the view to update:

  var socket = io.connect(location.origin);
  socket.on('status', function (data) {

Conclusion and commentary

One of the many realization we have come to using React in production is that one can get very far with views alone. A top-level view can make XHR requests, then pass the data down to child components as props. Child components can capture low-level events, and translate them into events of higher level of abstraction via callbacks passed in as props.

We realized many simple pages can be entirely done this way. What we have noticed though is that when Web Sockets and server-side events are involved, Flux architecture really comes to its own and shows its potential. Mixing server side events with events produced by users interacting with the UI is much better done using Flux.

The problem we tried to solve is rendering the initial page. If the user stays on the page for a prolonged period of time, status changes of the items can continue, but the code above can handle it without any changes. Of course, if others can create or remove server items, new events and actions are needed to model that.

As usual, the entire example is available as a Node.js app on Github, and I have deployed it in Bluemix so that you can see the app running here: Just keep refreshing the browser to see the three-step rendering (page, then items, and finally status).

© Dejan Glozic, 2016


6 thoughts on “ for Tardy React Status Indicators

  1. Hey Dejan, thanks for another great article. Question: at what point do you split the “list of cards” view into separate/reusable “card” components? The approach above re-renders the entire list for every socket frame (which contains a single card’s status) which seems like total overkill. Or is this total overkill a commonplace occurrence when relying on Reacts virtual dom diffing (dev effort vs performance tradeoff)? (here’s where I admit.. *shuffle shuffle*.. i haven’t done much React)

    1. Hi Janek, the implementation I provided was somewhat lazy, and in any other framework it would be really atrocious. However, virtual DOM diffing in React is so efficient that in many cases, ‘just re-render’ is all you need to do. In case of status indicators, React will figure out the minimal changes to the physical DOM that are needed when status changes arrive.

      The alternative would be individual cards listening to store changes and reacting to status changes individually (first checking if the status change apply to them). At the end of the day, the added code may end up providing no real improvement. Again, only in React – don’t do this in normal MVC implementations.

      1. Thanks for clarifying. My comment was a bit tangential, and more related to React itself rather than etc. — didn’t mean to start cherry-picking at things especially given that they’re outside of the scope of the article. Nonetheless, it prompted me to wonder w.r.t. React (and React best practices), is this ‘just re-render’ approach quite common, or would you generally not have a React view/component like this in production, despite the library’s rendering performance?

  2. React has provisions for smarter reacting (pun not intended) – components have the ability to skip on the re-render pass via ‘shouldComponentUpdate’. The thing though is that ‘just re-render’ is so surprisingly efficient in most cases that you really need to justify special code that does something surgical.

    One of the concerns is that ‘just rerender’ allows most components to be ‘dumb’ i.e. to simply render its UI based on the props passed to it by their parents. Once leaf components start cherry-picking when to update, they become ‘smart’, and thus away from the ideal. Ideal React hierarchy is one smart-ish component at the top acting as a view/controller, and a component hierarchy where state is passed down via props. Being able to compute if rendering is required will make a child component aware of the parent’s state, making the overall structure more fragile and error-prone.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s