The Case for React

At Bluewire we have been adopting an exciting new library from Facebook called React, which offers a new perspective on how to write large modern web applications like Epro.

JavaScript started as a “progressive enhancement” over static HTML, allowing a web page to update near-instantly without having to go through the slow process of refreshing the entire page. Making updates is a breeze using jQuery. If an element needs a new class name, we might write:

    jQuery(element).addClass("emergency");

jQuery searches the element’s className property for “emergency”, then if it doesn’t find it, adds the new class on the front. Preserving the existing classes is important: with this API the only way to know which classes the element should have is by looking at which classes it currently has. Where the current ones came from is unknown. Perhaps they were in the original HTML? Perhaps they were added earlier through another script?

React fixes the ambiguity by making the application state explicit, then computing class names from the state. Here the classes for an element are computed from an appointment using the classNames package:

    function appointmentElementClassName(appointment) {
        return classNames({
            emergency: appointment.nature == Nature.Emergency,
            overDue: appointment.date > cutoffDate
        });
    }

The class name returned by this function can be set directly on the element. Since all of the application state that determines the class name is passed into the function, the initial value for the element’s class name can be ignored: as long as the application state is correct, the class name will be correct.

But where did the application state come from?

Read on in part two.