
Thinking in React - AJAlabs
https://facebook.github.io/react/docs/thinking-in-react.html
======
danso
FWIW, this has been in the React documents from near the beginning:

[https://github.com/facebook/react/commit/a0ecf472421937545ff...](https://github.com/facebook/react/commit/a0ecf472421937545ff5843b5fee6ba5e6991685#diff-388df072689cb3c458ca3ef0d0cac717)

I've frequently referred to it when I need to refresh my memory on how to
start in React from scratch.

~~~
AJAlabs
Yeah, surprised that is just getting posted for the first time here.

~~~
roryokane
No, this is the second time this page was posted, according to
[https://hn.algolia.com/?q=Thinking+in+React](https://hn.algolia.com/?q=Thinking+in+React).
The page was first posted 2 years and 1 month ago in
[https://news.ycombinator.com/item?id=7672379](https://news.ycombinator.com/item?id=7672379),
though that submission had only 6 points and no comments.

------
firasd
This is a very useful walkthrough.

Some links for those who are also interested in "Thinking in React" in a more
conceptual way (#4 is a presentation from the same person who wrote the
walkthrough):

1) React — Basic Theoretical Concepts: “A description of the conceptual model
of React without implementation burden.” [https://github.com/reactjs/react-
basic](https://github.com/reactjs/react-basic)

2) Pure UI: “A lot has been written about the merits of React as a framework.
Today I’m compelled to write about the benefits of a programming model it
enables and its implications to the design and creation workflow."
[http://rauchg.com/2015/pure-ui/](http://rauchg.com/2015/pure-ui/)

3) Removing User Interface Complexity, or Why React is Awesome: “I’m mostly
concerned with the core problems of data binding and componentizing UIs. After
much research and usage of the technologies mentioned above, I found React to
provide the best solution.” [http://jlongster.com/Removing-User-Interface-
Complexity,-or-...](http://jlongster.com/Removing-User-Interface-
Complexity,-or-Why-React-is-Awesome)

4) Pete Hunt: React: Rethinking best practices (youtube): “building views with
JavaScript, ‘re-​rendering’ your entire application when your data changes,
and a lightweight implementation of the DOM and events.”
[https://www.youtube.com/watch?v=x7cQ3mrcKaY](https://www.youtube.com/watch?v=x7cQ3mrcKaY)

5) Nothing new in React and Flux except one thing: “What is it that makes
React so innovative and compelling?… The Virtual DOM allows us to convert a
mutable retained mode graphics API to an immutable functional immediate mode
API.” [http://staltz.com/nothing-new-in-react-and-flux-except-
one-t...](http://staltz.com/nothing-new-in-react-and-flux-except-one-
thing.html)

(I collected them to go along with something I wrote in the same vein:
[https://medium.com/@firasd/interface-from-data-using-
react-t...](https://medium.com/@firasd/interface-from-data-using-react-to-
sync-updates-and-offline-activity-across-devices-f672b213701c))

~~~
clessg
#4 is really my favorite. I know a lot of people who were hardcore opposed to
React until they watched that presentation.

> React — Basic Theoretical Concepts

"Basic"

Let's just say, save this one for last.

~~~
firasd
Yeah. When looking for videos I saw he updated his presentation and gave it
again, but there’s raw appeal in that first ‘Rethinking best practices’ talk.
Just something coming in out of left field. (Another early presentation: “Tom
Occhino and Jordan Walke: JS Apps at Facebook”
[https://www.youtube.com/watch?v=GW0rj4sNH2w](https://www.youtube.com/watch?v=GW0rj4sNH2w))

Re: basic concepts, I admit my eyes glaze over by the time I read the heading
“Memoization”. Opens with this great sentence though—I like to say ‘view as a
function of state’, but he breaks it down even simpler—“The core premise for
React is that UIs are simply a projection of data into a different form of
data.”

------
pbreit
I'm just amazed at how something that would appear to be so simple could be so
complicated.

~~~
spicyj
What do you mean?

~~~
pbreit
I have little trouble building decent, dynamic web sites in python. When went
through the article I was mostly befuddled.

~~~
spicyj
Sorry about that. Anything in particular we could improve?

~~~
fit2rule
Add a glossary/dictionary for all the new React terms, at the end of the
article ..

------
chris_st
For folks just a little further into React, there's a great project called
Storybook[1] which lets you put your JSON and React components, individually,
into a really nice UI to try them out. Earlier HN discussion[2].

[1] [https://github.com/kadirahq/react-
storybook](https://github.com/kadirahq/react-storybook)

[2]
[https://news.ycombinator.com/item?id=11411020](https://news.ycombinator.com/item?id=11411020)

------
carsongross
I know it's just a demo and I'm sure it scales very well, but I can't help but
think that's a lot of code for a such simple UI. The intercoolerjs equivalent
is pretty simple:

[http://intercoolerjs.org/examples/activesearch.html](http://intercoolerjs.org/examples/activesearch.html)

Don't misunderstand me, there are a lot of places where react is appropriate
and intercooler isn't, but for something like this...

~~~
BigJono
This is one thing I find a little bit frustrating with the tutorials of
various JS tools. They fail to accurately describe a problem that they solve.

Usually you just get a quick paragraph going on about what you can do with the
tool, then a quick example of something you could have easily done without the
tool, then straight into the full API documentation.

And after I've read all that I'm still saying "Ok, that's kind of cool. But
why would I add another dependency to my project when I can code your example
up in clean, vanilla JS (or more often in these days, plain old React)".

I'd love to start seeing tutorial documentation address this more. Having a
basic example is great, but it shouldn't be the only example. You should
follow it up with a more complex example that really captures the reason you
built the tool in the first place.

~~~
bromuro
> This is one thing I find a little bit frustrating with the tutorials of
> various JS tools. They fail to accurately describe a problem that they
> solve.

Yes, this is valid for anything. It's harder to understand the solution if we
haven't met the problem. For example, I realized the need of React after my
template-based app was becoming a huge mess.

------
smegel
Is React worth it? How complex does your site need to be before it becomes
worthwhile?

~~~
cgag
React is pretty easy to start with, for me the question is when does redux and
the madness in redux starter kit become worth it.

~~~
danenania
Yeah, I can see the value in redux for a big app with lots of complex state to
manage (eg Facebook), but it seems like major overkill in a lot of smaller
apps where people seem to be reaching for it by default for some reason. Plain
React components and a few helper modules can get you a surprisingly long way
--there's really no need for more framework until deeply nested components
make simple argument passing unweildy.

~~~
firasd
I saw this from Redux's creator that aligns with my take: "When people say
setState() is an anti-pattern, they mean 500-line components with a complex
setState() soup scattered across event handlers. When you spend your days
looking for bugs in those handlers and moving them up and down component
hierarchy, consider extracting it."
[https://twitter.com/dan_abramov/status/725090047557558272](https://twitter.com/dan_abramov/status/725090047557558272)

I had that whole 'moving values and events up and down the component
hierarchy, driving me nuts' thing going on when I tried to make an editor page
for a two-level list. I added Redux and now I just directly read/update the
list in the store from every component in the editor.

------
k__
[https://github.com/kay-is/react-from-zero](https://github.com/kay-is/react-
from-zero)

for people who want to look into react itself without webpack, es2015 etc.

------
peteretep
I'm a dab jQuery hand and I absolutely love the idea of React - reminds me of
the best parts of XSLT. I'm struggling a bit with the pre-required tooling -
not that it's there, but I'm just out of date with what a Babel is, what ESX
is, how do I get Javascript 1.7 rendering in the browser, etc etc etc.

Is there a simple guide to _that_?

~~~
firasd
You would need some familiarity with npm first but after that the current
practice is to use webpack with 'loaders' to transform JSX, ES6 etc.

This is intermediate: webpack-howto [https://github.com/petehunt/webpack-
howto](https://github.com/petehunt/webpack-howto)

~~~
travmatt
A simple starter for webpack: [https://github.com/HenrikJoreteg/hjs-
webpack](https://github.com/HenrikJoreteg/hjs-webpack)

------
ausjke
Not an experienced frontend developer per se, each time trying to study React
it seems daunting, will things like vue.js a better method for 90% of the
problems?

Angularjs is also complicated, if not more than React, especially it's now
more like C# (typescript etc) which I don't like.

Maybe I'm just too dumb, or things move so fast and getting so complicated and
I just can not catch up.

I will try to use jQuery and possibly vue.js for now, for the sake of KISS.

------
mrkgnao
The Yelp clone was scary, yes, but this is pleasant. I'll try this when I get
back home today.

------
d0m
It this very old or this is a re-write? I remember reading that a year or two
ago.

~~~
thebyrdman
Source[1] hasn't been updated in over a month, so it's just a repost.

[1]
[https://github.com/facebook/react/blob/master/docs/docs/thin...](https://github.com/facebook/react/blob/master/docs/docs/thinking-
in-react.md)

------
jrochkind1
The problem I've had developing with React (I've just done a little, I'm still
a beginner), is it sometimes seems like a minor change to the UI can require a
major change to the source, cascading through multiple components.

I think maybe this is reflected in this guide, such as the advice in the
"Identify where your state should live" section (which they say is "often the
most challenging part for newcomers to understand", which matches my
experience), which suggests you should be looking at every single component
involved and how they all relate to determine where the state should live.

This is very different from my previous (mostly OO, lately ruby) experience,
where you really want to look at a component (in the broad sense, not
neccesarily a view-layer, I just mean any object or 'piece') in strict
isolation, identify what it's inputs and outputs need to be, and from that
alone, in isolation, you know what it's API should be. And from this
technique, you hope to wind up with components that that do not assume or
depend on too much about their context of use and can be re-used and re-mixed
in different ways without a rewrite.

I've found I've had to change my whole approach designing React -- when using
my previous time-tested techniques, I would wind up putting props/state in the
wrong place. I found that indeed I had to consider the entire graph when
determining props/state. But that this has led me to situations where what my
intuition would say would be relatively small changes to the UI create a
cascading waterfall of changes I have to make to lots of and lots of
components in the existing graph, as where state (including props) is kept
needs to change, requiring cascading changes to many components in the
previous graph.

Examples of such UI changes would be taking a UI widget/component that
previously was only one one page and realizing it had to be re-used on
another(s); moving a UI widget from one part of the page to another; taking a
UI widget that previously just displayed something and realizing it needs to
have an 'edit' capability too; taking something that showed up just once on
the page and changing it to be say at both top and bottom of page. All things
that my usual techniques and approaches from OO experience would have been
able to accomodate no problem if I had designed the components well from the
start, but that in React I'm finding result in needing to change where state
is kept (or what things are state and what things are props), requiring
cascading changes to many components.

Which is frustrating. I hoped I'd get better at avoiding this as I got better
with React, and I'm sure that's true, but if even the advice from those most
experienced says you can only determine state/props architecture by looking at
the entire object graph possibly involved in that state....

I dunno. Comments from people more experienced with react very welcome.

~~~
zxcvcxz
>it sometimes seems like a minor change to the UI can require a major change
to the source, cascading through multiple components.

>in React I'm finding result in needing to change where state is kept (or what
things are state and what things are props), requiring cascading changes to
many components.

It sounds like you don't have a good understanding of state vs props. You
should use state as little as possible and try to do as much as possible
through props, passing them down from the parent components as necessary.

When I create a react app I use the flux architecture, define a state on the
top parent component and then add most of the other components as children to
this parent component, passing down state as props, and adding listeners to
update the components when the state of the parent changes.

As far as moving elements around I mostly do that through CSS and wasn't aware
react had much to do with positioning elements

>taking a UI widget/component that previously was only one one page and
realizing it had to be re-used on another(s)

Import it into the component that renders the other page and use different
props. If you define a lot of stuff in the state of the component then the
component isn't as portable.

>moving a UI widget from one part of the page to another;

This just sounds like CSS and possibly markup to me.

>taking a UI widget that previously just displayed something and realizing it
needs to have an 'edit' capability too

Not sure what you mean by this.

Sounds like you could use more practice.

[https://github.com/uberVU/react-guide/blob/master/props-
vs-s...](https://github.com/uberVU/react-guide/blob/master/props-vs-state.md)

~~~
jrochkind1
> It sounds like you don't have a good understanding of state vs props.

I think I've got a decent understanding, but I'm sure it could be better, and
am heartened to think as it gets better these problems will go away.

> You should use state as little as possible and try to do as much as possible
> through props, passing them down from the parent components as necessary.

But yes, I've arrived at as little state and as many props as possible. The
challenge for me here is that this ends up resulting in components that look
to me (based on previous OO experience) like they have TERRIBLE API's,
requiring way too many props. My instinct from OO is that a _smaller_ exposed
API makes things more portable, but you suggest that "If you define a lot of
stuff in the state of the component then the component isn't as portable."
Nonetheless, I have moved toward more-props less-state, but....

ALSO this has meant for me that when I need to move or re-use a component from
one part of the hieararchy to another, I often end up needing to completely
rework the props of a BUNCH of other components, so the right prop can be
passed down to my now-moved component -- that's what I mean by 'requiring
cascading changes'.

~~~
TheCoelacanth
> ALSO this has meant for me that when I need to move or re-use a component
> from one part of the hieararchy to another, I often end up needing to
> completely rework the props of a BUNCH of other components, so the right
> prop can be passed down to my now-moved component -- that's what I mean by
> 'requiring cascading changes'.

This sounds like the problem that is solved by redux et al. Instead of passing
props into a component just so that it can pass those props down to its
children, the child components can just connect to redux and get the data.
That way you are accessing the data at the point in the component hierarchy
where it makes sense for the component to know about that data, instead of in
whatever component happens to be the common ancestor of all of the places that
need the data.

~~~
jrochkind1
Thanks for the feedback!

I had somehow gotten the idea that the common advice was to not use redux/flux
until you really need it, and even then only use connect to it in 'top level'
components, and pass things down from 'top level' component to children view
props. Rather than have every component get things from the reactor itself,
even deeply nested children.

Have I gotten the wrong idea? Is the advice I thought was common not actually
common?

