Sheets). We strongly discourage the average product engineer from writing much CSS. Instead, we suggest that they take these components off the shelf, drop them into whatever it is they’re doing, and then maybe tweak the layout a little. That has worked really well for us.

PO: That way we end up writing good code pretty much across the board since there are fewer people going off into crazy land writing CSS. Basically, this just gives us a way at the top level to control all that.

 

For all the ways in which React sim-plifies the creation of user interfaces, it also poses a learning curve for developers new to the environment. In particular, those who have worked primarily on monolithic systems in the past may find it challenging to adopt more of a component-oriented mindset. They will also soon find that React is opinionated about how state should be handled, which can lead to some hard lessons and harsh reminders whenever people stray.

 

TC: There’s a lot about React that’s appealing, but where are the sharp edges that people ought to look out for before diving in? What kinds of mistakes are likely to make their lives more painful?

PH: Most of the pain points are almost certain to be about state. State is the hardest part of building applications anyway, and React just makes that super explicit. If you don’t think about state in the right way, React is going to highlight those bugs for you very early in the process.

TC: Give me a concrete example of how people might think about state in the wrong way.

PH: OK, I’m looking at a site powered by React that was launched earlier today. It looks like the page has four main components: side navigation, a search-results list, a search bar, and a content area containing both the search bar and the search-results list.

When you type in the search bar, it
filters the results to be shown in the
results grid. If I were to ask you where
that filter state should live, there’s a
good chance you would think, “Well,
We emphasize it because it’s com-
posable, which is the one thing that
most separates React components
from Angular directives and Web com-
ponents like partials and templates.
This focus on composability—which I
see as the ability to build nested com-
ponents on multiple layers—not only
makes it easier to see what’s actually
going on, but also gives you flexibility
in terms of how to structure and dis-
play data, while also letting you over-
ride behaviors and pass data around in
a more scalable and sensible way.

PAUL O’SHANNESSY: This also has a lot to do with how we build applications on the server, where we have a core library of components that any product team can use as the basis for building their own components. This idea of using components is really just a natural extension of the core way we build things in PHP and XHP, with the idea simply being to compose larger and larger components out of smaller components.

PH: Those product teams tend to be made up of generalists who work in all kinds of different languages, which is to say they’re not necessarily experts in JavaScript or CSS (Cascading Style

DAVE SMITH
When I started out
with React,
one of the hardest
things for me
to grasp was
this idea that
everything is
a component ...
I found myself
getting lost in
relationships
between
components.