jects or scope variables. Any changes
there effectively become visible at
multiple locations throughout your
code at much the same time, meaning
the composability issues surface since
different locations in your code are
made aware almost simultaneously
of changes that propagate backwards
from the UI.
PH: Another problem is that you
might have multiple bindings to the
same data source. So then which piece
of code is going to be treated as the
authoritative source for determining
what the value ought to be?
This is why, with React, we emphasize one-way data flow. As I said earlier,
data in our model first goes into this
application black box, which in turn
emits a virtual DOM representation.
Then we close the loop with simple
browser events. We’ll capture a KeyUp
event and command, “Update the
data model in this place based on that
KeyUp event.” We’ve also architected
the system in such a way as to encourage you to keep the least possible mutable state in your application. In fact,
because React is such a functional
system, rather than computing a value
and then storing it somewhere, we just
recompute the value on demand with
each new render.
The problem is that people sometimes want to have a big form that
includes something like 20,000 fields
that then bind to some simple keys
and data objects. The good news is
that it’s actually very easy for us to
build an abstraction on top of a simple event loop that basically captures
all the events that might possibly update the value of this field, and then
sets up an automatic handler to pass
the value down from the data model
into the form field. The form and the
data model essentially get updated at
the same time. This means you end
up with a system that looks a lot like
data binding, but if you were to peel it
back, you would see that it’s actually
only simple syntactic sugar on top of
an event loop.
TC: One of the things I’ve observed
about React is that it seems to be what
people would call fairly opinionated.
That is, there’s a certain way of doing
things with React. This is in contrast to
Angular, which I’d say is not opinionat-
ed since it generally lets you do things
in several different ways. Do you think
that is an accurate portrayal?
PH: It depends. There are certain
places where React is very opinionated
and others where it’s quite unopinionated. For example, React is unopinionated in terms of how you express your
view logic since it treats your UI as a
black box and looks only at the output.
But it’s opinionated in the sense that
we really encourage idempotent functions, a minimal set of mutable state,
and very clear state transitions.
I’ve built a lot of stuff with React,
and I have a team that’s run a lot of
stuff with it. From all that experience,
I can tell you that whenever you run
into a bug in a React application, nine
times out of 10 you’re going to find it’s
because you have too much state in
there. We try to push as much mutable
state as possible out of applications to
get to what I like to call a fully normalized application state. In that respect,
yes, we’re very opinionated, but that’s
just because a lot of React abstractions
don’t work as well if you have too much
I think Angular is actually less
opinionated in that regard, but it certainly has opinions about how you
need to compose your application.
It’s very much a model-view-present-er type of architecture. If you want to
create reasonable widgets, you’re going to have to use directives, which
are very opinionated.
TC: Another thing I noticed right
away about React is that it’s very component-oriented. What was the reason
for going in that direction?
We end up writing
good code pretty
much across the
board since there
are fewer people
going off into
crazy land writing
this just gives us a
way at the top level
to control all that.