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.