
How Does setState Know What to Do? - danabramov
https://overreacted.io/how-does-setstate-know-what-to-do/
======
sfvisser
> But as we have seen today, the base class setState() implementation has been
> an illusion all along. It doesn’t do anything except forwarding the call to
> the current renderer. And useState Hook does exactly the same thing.

This is worded a bit weirdly. The fact that there is some indirection and the
meat of the `setState` is in the renderer and not in the component doesn't
really make `setState` an illusion. A call to `setState` still does exactly
what we thought it did.

~~~
danabramov
Maybe I need to rephrase. I meant that many people imagine Component class as
being the meat of the codebase, heavily operating on `this` and updating
things on it.

Similarly folks often imagine `this.state` being the source of truth (and thus
Hooks seem too ephemeral).

But both of them are indirections to the same place elsewhere. And state for
both of them is kept in the renderer. For classes it’s synced to `this.state`
at the last moment so you can read it but `this` is not the source of truth.

~~~
sfvisser
> I meant that many people imagine Component class as being the meat of the
> codebase, heavily operating on `this` and updating things on it.

Yeah maybe. Even when it's not true it is still a valid way of looking at it I
think. In the abstract sense that's what's being modelled here with the API,
right? The fact that the internals are different is an implementation detail.
Of course, it might be an interesting detail, hence your blogpost.

> Similarly folks often imagine `this.state` being the source of truth (and
> thus Hooks seem too ephemeral).

I still don't understand why this is though. In some of my projects I actually
manage my own local state on the component class (without this.state/setState)
and auto `forceRender` when something changes. In those cases my state is
super sync and everything works fine. With the additional benefit of my local
domain logic being modular: I can read my state after having updated it and it
works like expected. So know I can write multiple methods dealing with my
local state and compose them freely — like actual OO.

I understand the hooks world is a different story, but in the compat component
world it all seemed just fine. Why doesn't react use `this.state` as the
source of truth, or update it more aggressively so it at least looks like the
source of truth to me? Perf reasons? Is it worth it?

------
TheAceOfHearts
FYI, this is Dan Abramov's blog. He's one of the developers working on the
React team. I'd highly suggest checking out his other posts if you use React,
they're all superb.

~~~
kaycebasques
I do the DevRel* for Chrome DevTools. Dan is remarkably good at DevRel. I've
pinged him on a few occasions, and to my recollection he's always replied very
promptly, always with a helpful answer. My impression is that he's like that
with anyone who has a reasonably well-thought-out question. Which, if true, is
amazing considering the size of the React community. Aside from React's own
merits, I would wager that Dan's DevRel superpowers have been a non-trivial
factor in React's success.

* Developer relations, on the off chance anyone is unfamiliar with the term. A DevRel team for a developer product like React would be in charge of communicating new features, changes, best practices, etc. to the React developer community, answering technical questions on how to use React, and relaying community feedback to the React team.

~~~
franciscop
I just learned that DevRel is a thing, I just thought it is a non-trivial part
of a normal project but not that it was categorized separately (or I'd call it
tech advocate). Not only that, I think that DevRel is the best indicator of
success of any project! Basic design, documentation, etc are _needed_ , but
once those are covered it's DevRel what sets projects success apart.

Famous DevRel I know and what they've been promoting to great success:

\- Dan Abramov, Redux and React.

\- Evan You, Vue.js

\- Lea Verou, Prism, Bliss and CSS in general.

\- "@dhh", Ruby on Rails.

\- Sindre Sorhus, npm and indie JS.

Note: I just say they have _greatly helped_ to the success, no that these are
their projects.

On the other hand, we all know some projects that succeed _despite_ their
founders being really bad at DevRel... but those are _so rare_ and basically
just put a lot of efforts in something related but not the same (marketing,
first to the market, 10x better technically, etc).

My main focus right now is learning how to get better at this since I'd love
to do OSS fulltime. Any tip on how to get there would be greatly appreciated.
I'm trying to learn mainly from Dan and Evan since IMHO they _are_ next-level
in this specific area :)

PS, since you work for Chrome DevTools, I imagine you are in Google. I think,
besides the issues of Angular 1->2, the real reason Angular stayed behind is
that there were no highly visible DevRels.

~~~
danabramov
FWIW my job role is just software developer. I try to help people because I
like being a part of the community and like explaining things to others that
somebody explained to me. But I’m not officially a DevRel. Although I guess I
fit the shoes.

~~~
kaycebasques
Right, didn’t mean to imply that you only did DevRel. I think most React users
know that you’re on the core team. Just wanted to suggest to the general HN
community that your consistent efforts around helping the React community
might be a factor of React’s success. Whenever there’s a post here on HN about
why framework A is a success whereas framework B is a flop, the focus is
usually on technical factors or developer ergonomics.

------
Raed667
I love these posts but despite the warning I'm sure some of the things here
will end-up in React junior positions interviews.

------
inglor
״However, this has always led to obscure bugs so Hooks force you to solve the
package duplication before it costs you."

So basically the fact hooks doesn't support multiple react instances isn't a
but but a feature :D?

~~~
jcutrell
More like "this tool wasn't designed to work that way, so to use this part of
the tool, you'll have to conform to the way it was intended to be used."

------
InGodsName
Those working on projects. What do you prefer? Should i choose React or Vue?

~~~
sametmax
Try both, and see which one you prefer.

Vue first though, as it's easier to get started with it and it will get a
sense of what minimal setup you should expect. Then try to match that with
react.

If you start by following most react tutorials, they will make you begin with
something way more complicated that it needs to be and you will get
discouragedd.

Both have a "cli" tool. Everybody tell you to start with it. I strongly advise
against it, as it's the best way to not understand a thing about what you are
doing and make bad decisions.

Find a tutorial that starts with the bare lib (no webpack, no transpilation,
nothing but a script tag), for both vue and react. Then when you know how this
work, find a minimal webpack based tutorial.

Then when you know those basics, use the cli tool, but immediatly use the
eject feature. Read the result to understand the whole shebang.

Once you have done that, you can start any project using the cli without
eject, and be confident you know what's going on. It will make you not only
very productive, but also will let you take decision based on what you know,
and not what other people wants you to know.

Now, I personnaly prefer Vue as I find the lib easier to work with, the
community saner and the documentation is one of the best I've read, even
including non JS projects. But again, make an educated choice.

~~~
parhamn
> If you start by following most react tutorials, they will make you begin
> with something way more complicated that it needs to be and you will get
> discouraged.

Can't agree more with this. There are quite a few reasons I think those
starter-kits and tutorials are very harmful especially to new developers.
Figuring out how your tsconfig/webpack/babelrcs/state-handlers/etc all fit
together should be something that should certainly be done and learned
incrementally.

Perhaps the issue is the amount of boilerplate you need to start a simple app.
There should be a flask[1] like starter for react/vue apps. Parcel seems like
the closest thing but its still not obvious to me why they demo 4 files to get
started [2] -- we already dynamically transforming and compiling everything
why not just have a single `index.js` with a Index/Main entrypoint?

Is there anything out there to do something as simple as:

    
    
        import * as React from "react"
        import {Html, Body, Title} from "parcel"
    
        const Index = () => {
            return (
                <Html>
                <Title>MySite</Title>
                <Body>
                    <h1>Hello world!</h1>
                </Body>
                </Html>
            )
        }
    

with a `cmd {run,build} index.{jsx,tsx}`

[1] [https://github.com/pallets/flask/#a-simple-
example](https://github.com/pallets/flask/#a-simple-example)

[2] [https://parceljs.org](https://parceljs.org)

~~~
petetnt
Create React App does pretty much with all the complexity hidden behind
’react-scripts’ you can optionally eject out of if needed sometime in the
future.

The steps are pretty much

npx create-react-app && yarn start and finally yarn build for a production
ready build.

~~~
sametmax
Using "Create React App" as a beginer is the best way to have no idea of what
you are doing, and make terrible decisions for what follows next.

~~~
petetnt
I'd love if you would elaborate on that so the Create React App
documentation[0] and the official recommended tutorial[1] could be improved on

[0]: [https://facebook.github.io/create-react-
app/](https://facebook.github.io/create-react-app/) [1]:
[https://reactjs.org/tutorial/tutorial.html](https://reactjs.org/tutorial/tutorial.html)

edit: Saw your points above and while I do not agree I can understand your
point of view.

~~~
sametmax
I already contribute to the python community. No time for another one, sorry.

------
Jasmine97
Great Stuff

------
larkinrichards
Doesn’t answer the question.

------
HugoDaniel
These posts are cool. I'm planning on writing a set of react interview
questions based on them.

~~~
vanderZwan
Given this disclaimer at the top of every article, that sounds a bit
inappropriate:

> _Disclaimer: Just like most other posts on this blog, you don’t actually
> need to know any of that to be productive with React. This post is for those
> who like to see what’s behind the curtain. Completely optional!_

~~~
HugoDaniel
I only want my team to be composed of those who like to see what's behind the
curtain.

~~~
aerovistae
Everyone knows the best teams are homogeneous, and everyone knows that if a
candidate hasn't looked behind the curtain of React, then they probably don't
look behind the curtains of _anything._

------
flowerlad
React is a bit less hot today than it was a few weeks ago. What changed is
that FireFox released support for Shadow DOM. Also Microsoft is moving to
Chromium. Which means Shadow DOM is suddenly hot and technologies that don’t
support Shadow DOM, including React, became a bit cold.

~~~
gbear605
No technology becomes more/less hot in a period of a couple weeks, not even JS
frameworks.

~~~
taeric
I want to believe this. However, I also feel bewildered when I check the news
of what all has happened in js frameworks in the past 3 years. Especially
true, if I consider how different the big frameworks of today are, compared to
the same frameworks 2 years ago.

~~~
Vinnl
Really, if you're talking three years ago, React was already widespread. The
main change is that Angular.js back then was still widespread as well, and
that Vue wasn't really.

Sure, things have changed (e.g. TypeScript is far more accessible today), but
if you've been doing React for the past few years, the changes haven't been
that drastic, and primarily for the better (e.g. Create React App, that mainly
allowed you to forget things, rather than having to learn new things).

