I feel weird writing about React. I’m not a contributor or upstanding community member. I’m not even an early adopter – we only started working React into Crashlytics about six months ago.

I’m a fan, though. A huge fan. And even though I thought I was the last person to this party, I keep running into frontend developer pals who haven’t given React a try.

Let’s change that!

The models who couldn’t save themselves

My React fervor was sparked by a bug I wrote. I work on Beta by Crashlytics, and much of our web frontend is written in Backbone. Late last summer, our dialog for managing groups of testers regressed: every so often, it would stop working. Any attempt to edit the group’s name, or add or remove testers, would be met with the same error in the JavaScript console: A “url” property or function must be specified.

How could this be? I had a Group model object, a whole collection of them in fact. You can see them right there in the sidebar. They each had their IDs, and their collection was very clear about how to turn those IDs into URLs. And yet, somehow “save” was broken. Why wasn’t it making its URL?

Let’s be clear, this is my bug. And –  full disclosure  –  I wrote it when converting some other parts of the UI to React. I was finding the Backbone Collection’s “set” method to be too chatty announcing change events, so, for the code that updated our global Group collection in response to a periodic server poll, I changed over to “reset” instead. It even seemed more correct, in my mind: make the groups list exactly like the latest state from the server.

Unfortunately, “reset” works by first emptying the collection of its existing models, then re-populating it. That emptying carries the consequence that those previous occupants — such as the Group object that the editing UI had a reference to — would be orphaned, no longer a member of anything. No parent collection meant no “url” method, and that meant no way to save.

I felt a bit stupid for having caused such a regression, but that was eclipsed by my frustration that such a bug was even possible. Model objects that are capable of saving themselves had already been a pet peeve of mine due to how they hindered testability, but now I found model objects that could arbitrarily lose their ability to save themselves in the middle of my program!

This was a mutation bug on steroids: an object’s functionality changing not even due to local state modifications, but by whether or not another object was holding a reference to it. How could I reason about behavior if this possibility was lurking in my code? What automated test would have even exercised this?

I was determined. I was vengeful. It was now time to, as they say, React all the things.

The DOM Doctors

Doubling down on a new UI rendering library might seem a strange way to solve a model logic problem, but React has the remarkable power to send ripples of correctness through your codebase. Consciously or not, libraries like Backbone end up encoding assumptions about how views work in their data classes. If we fundamentally changed how rendering happens, why wouldn’t that affect how we managed data?

If you’ve heard anything about React, it’s probably that it has a “virtual DOM” that makes its HTML fast using an efficient tree diff algorithm. If you’re like me, the first time you heard that you may have dismissed it. My HTML isn’t slow.

And maybe it’s not that slow, but only because we frontend developers learned not to push it. We joined together our template strings for one big innerHTML splat at the outset and then just modified individual elements going forward. We couldn’t conceive of being so callous as to re-render an entire dialog just because a group’s name changed. We were good programmers, we were precise. We were surgeons, jQuery was our scalpel, and when the “name changed” event came in we made only the tiniest incision in the page to bring it up-to-date.

There’s another reason for why we stepped lightly in the tree: DOM elements are stateful beyond how we created them. They have focus, or scroll positions, or in-progress edits. Some cavalier re-rendering wouldn’t just be slow, it would stomp user data at the same time. And that, at least, was unacceptable.

These constraints had a profound effect on our code. We couldn’t just write the state of what our UI should look like (“the button is disabled because a network request is in progress”). Instead, we were condemned to write the state transitions between those UIs. On network request start? Add class “disabled.” On complete? Remove class “disabled.” If we were lucky, we found all the ways that state tended to linger on our pages. On showing a form? Remove any error messages from the last time we showed this form.

Testing this style of code is both painful and approximate. On top of exercising your initial rendering, you need to test your transitions. They need plausible prior states just to run, but to have good coverage you need to test them against each important variation of prior state that your application is capable of getting itself into. A “finite” state machine perhaps, but only in theory.

Spared from Change

Enter React. The real benefit of that O(n) tree-diffing algorithm isn’t performance per se. It’s that it frees us from having to hand-write every state transition in our UI. Besides reducing drudgery, that actually eliminates the entire class of leaky-state bugs mentioned above. If you declare that your UI is a dialog with an active button and no error message, React will transition to exactly that, performing DOM manipulations that ensure that your button is active and no error message is seen. Any vestiges of previous state are cleansed with no extra effort on your part.

Fundamentally, your old state transition code was a function over your application data, but also over the previous state of the UI. That’s why you needed to consider varied “prior states” when testing. In contrast, your React rendering code is a function over just the application data. You can imagine how much more pleasant that makes your tests.

The real answer to how “just” a view library can affect your data handling is that React is a view library because that’s all that it needs to be. When I talked about the Backbone data classes having assumptions about the way you displayed your UI, I was thinking of mutation handling and attribute-level change events. If you’re writing minimal state transitions, that kind of information is important for doing precise DOM surgery. If you’re writing a React component, though, where declaring UI state is cheap and getting to it is fast, the only notification you really need is “something has changed, probably.”

Since all you need are coarse-grained change notifications, your data objects can be correspondingly simpler. One could argue that React even works best on just plain hashes and arrays. All you need is for a data source to hand your component hierarchy the latest values, and everything flows efficiently from there. No mutation-tracking, self-saving, collection-inhabiting model objects necessary.

Efficient coarse updating also enables what may be my favorite part of React: props and state.

In a correctly-written React component, the only inputs to the UI rendering method are its “props” and its “state.” These are exposed as a pair of hashes on the component object, and changes to either of them cause the component to re-render. (Something has changed, probably.)

The difference between the two is how they change. “props” can be thought of as the input from the outside world. It’s set from the parameters your component is called with, and its values should be treated as immutable. “State,” on the other hand, is the data that’s owned by your component. You update it via the “setState” method, and no one else should be changing it on you.

To give a concrete example, consider a component for editing a group. The props would include the group’s name, while the state might be whether it’s showing a “delete” link or the “confirm” / “cancel” buttons that appear instead when that link is clicked.

This may seem like just a helpful little pattern, but by calling out this distinction between props and state, React has bestowed an enormous understandability boon on your code. Gone is the catch-all “options” hash that contains everything, internal and external. Your data is going to naturally fall into one hash or the other, so there’s one fewer choice to make when structuring your component, and, more importantly, one more signal of your intent when your team comes back to your code months later to extend it.

In practice, the state of one component actually ends up trickling into its child components as props, and establishing your intention is even more valuable. When the same data is “state” here and “props” there it’s perfectly clear what level of your component hierarchy is responsible for coordinating its changes.

Finally, when you consider testability, you can, in almost every case, proceed in ignorance of changes to your component’s props. So, while you and I both know that group names can change, all the component that renders the list of groups in the sidebar needs to do is render the names it’s given. If they change, it’ll be given new names, and it’ll render them just the same. No need to waste time in your tests verifying that case.

Path to salvation

React is fascinating because it takes this rather clever little algorithm for fast tree diffing and follows it to its logical extreme, introducing an incredibly effective paradigm to web developers: If we can diff in O(n) time we can quickly convert one DOM tree to another. That means it’s efficient even if the difference is small. It also means we can keep that partially-filled <input> around. That means we can do coarse-grained updates for any change. That means that re-rendering can be triggered automatically by the framework. That means we can have a simple, standard pattern for state management. And so on.

As a library, React doesn’t really let you build anything that you couldn’t do before with any other UI framework. Maybe some things will be more performant out-of-the-box, but functionality-wise your product will be very much the same. What React gives you instead is much less, better code, sooner. Declarative UIs are faster to write, simpler to test, and far far far easier to reason about.

It feels like nothing short of giving you frontend engineering superpowers.

Hopefully this has whet your appetite for React. Maybe it will be as revelatory for you as it has been for me. Soon, I’ll follow this post up with some more specifics about how we’re using React on Crashlytics, why you don’t need JSX, and our take on a unidirectional data flow pattern :)

We're helping our customers build the best apps in the world. Want to be a part of the Crashlytics team and build awesome stuff? Ping us @ [email protected]. We look forward to chatting with you!

(Big thanks to Kevin Robinson, Sam Neubardt and Sam Phillips for contributing to this post.)