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.