ought to live there.” That’s what intuitively makes sense.

But actually the state should live in the common ancestor between the search box and the search-results list, sort of like a view controller. That’s because the search box has the state of the search filter as well as the search results. Still, the search-results list needs access to that data as well. React will quickly let you know, “Hey, you actually need to put that in a common ancestor.”

PO: If you were building that same UI with Angular and used a directive for the search box and then another directive for the search results, you would be encouraged in that case as well to put your state in a common ancestor. This would mean having a controller hold the scope variable, since that’s where you’ll find the search text to which both of those directives would then bind. I think you’re actually looking at a pretty similar paradigm there.

PH: Good catch. But I think there’s still a distinction to be made in that React components are building blocks that can be used to construct a number of conceptually different components or objects. You could use a React component to implement a view controller or some pure view-only thing—whereas with Angular, the controller is distinct from a directive, which in turn is distinct from the “service,” which is how Angular describes those things you shove all the other logic into. Sometimes it makes sense just to make all those things React components.

DS: In this case, if you were building the UI with React, what would be the common ancestor? A React component?

PH: Yes. I would use React components for everything.

DS: When I was starting out with React, I think one of the hardest things for me to grasp was this idea that everything is a component. Even when I walked through an example on the React website that included a comment box and a comment list, I was surprised to learn that even those were treated as components. I also found myself getting lost in the relationships between those components. I wonder if you find that to be a common problem for other new React developers.

PO: For people who are used to build-
ing more monolithic things, that often
proves to be a problem. At Facebook,
where we’ve always coded in PHP,
we’re accustomed to building micro-
components and then composing
them, so that hasn’t proved to be such
a huge problem here. Anyway, what I
think we’ve always encouraged is that,
whenever you’re thinking about reus-
ing something, break it down into its
smallest elements. That’s why, in the
example you cited, you would want to
separate the comment box from the
comment list, since you can reuse both
of those things in other parts of your
application. We really do encourage
people to think that way.

PH: We also encourage that you make stuff stateless. Basically, I like to think people are going to feel really bad about using state. I know there are times when it’s a necessary evil, but you should still feel dirty whenever you have to resort to doing that. That’s because then you’ll start thinking, “OK, so I really want to put this search state in only one place in my app.” Generally, that means you’ll find the right spot for it since you’re not going to want to deal with having to synchronize states throughout your application. And you won’t have to if it lives in only one canonical place.

DS: What other major differentiators set React apart from other JavaScript frameworks?

PH: We haven’t yet talked about the idea that React, as a general way of expressing user interface or view hierarchies, treats the DOM as just one of many potential rendering back ends. It also renders to Canvas and SVG (Scalable Vector Graphics), for example. Among other things, this means

TERRY COATTA
React is in some
sense a highly
functional
environment
that takes some
arbitrary input,
renders an output,
and then computes
the difference
between the two
to determine what
it ought to be
displaying on
the screen.