
Understanding the React Source Code, Part 1 - adamnemecek
https://hackernoon.com/understanding-the-react-source-code-initial-rendering-simple-component-i-80263fe46cf1
======
spicyj
(I work on React.)

Note that this is based on React 15.6.2, an older version of React. In React
16 we rewrote almost the entire codebase so that one may be more interesting
to look at, depending on your goals. I guess – just don't blame us for some of
the strange code patterns in 15 (like that random TopLevelWrapper) that we've
since gotten rid of. :)

~~~
ricardobeat
Out of curiosity, who should we blame? Team change?

~~~
felipellrocha
Blaming is the least productive thing when it comes to these things. Maybe the
developer wrote that at midnight after a long day of work, and at that time it
sounded like a good solution...

~~~
Klathmon
I've found most times it's not even that, but that the "bad code" was in most
cases the best possible code that could have been written within the needed
constraints.

You need a fix for problem "x". You can either write the ugly hack by next
weekend knowing that it's going to be replaced by the big rewrite you have
coming up in 6 months, or you can spend 1 month refactoring code to make a
"proper fix" that will last another 5 months until the code is rewritten...

Of course when you have an audience, they get to read into this however they
feel. Some will point to the hack as an example of how awful the codebase is
and how bad the developers are, others will point to it and proclaim (wrongly)
how dirty hacks are never a bad thing if they work, still others will talk
about how much better their idea their idea would have been even though it
didn't fit your exact constraints.

In my experience, very very few successful developers are "dumb" or "bad at
programming" or whatever insults you see thrown around all the time. Most of
the time it's just someone making the best of a shitty situation weighing
several constraints while still keeping the product working.

~~~
hinkley
You don’t identify the party to shame them, you identify the party as part of
the Five Why’s. And then additionally to reassess your trust level when
someone says they are “done” or offers you advice. Developers bank a lot on
this kind of trust and shutting down these so-called “blame” exercises blinds
the team. Don’t.

People who don’t at least try to write better code every chance they get have
a pretty poor understanding of “best” in a given situation. They will grow
very slowly if at all, and their best isn’t good enough. And if it turns out
you were the negligent party, don’t you want to know that? Don’t you want to
recollect how you rationalized that piece of work and adjust your behaviors?

Above all else, don’t count on a rewrite. It is a Once in a Blue Moon affair
and if often goes wrong. It’s the worst kind of crap shoot. The worse things
are the less likely the rewrite will work. Rewrites require you to recall the
entire featureset and if the project is off the rails then nobody knows all of
them, so any part you touch is likely to miss something important.

Edit: the rest of a thought

------
city41
If React internals is interesting to you, I did a similar write up, but with a
different approach. I start with nothing and build a tiny React clone:

[http://www.mattgreer.org/articles/react-internals-part-
one-b...](http://www.mattgreer.org/articles/react-internals-part-one-basic-
rendering/)

------
linkmotif
I’m sure this is really good, but one of the best things about React is that I
don’t know anything at all about its source. Maybe it explains the build
system? I was thrown by the import rewrites.

~~~
spicyj
We did away with those recently because people found them confusing.
[https://reactjs.org/blog/2017/12/15/improving-the-
repository...](https://reactjs.org/blog/2017/12/15/improving-the-repository-
infrastructure.html) details that change and some other recent ones.

~~~
linkmotif
Thank you! Glad to know more about it after all this time.

Thank you for React! The other day I was tired of working and decided to
engage in some “recreation” by upgrading 15.4->16.2. It was really smooth.
Warnings introduced in 15.6 made it even easier. Ran some code mods, updated
some dependencies. Done. The new excellent error handling jumps out at you
right and away.

------
ramzyo
>> In compiling time, components defined in JSX is translated by Babel to
React.createElement() called with appropriate parameters.

Does he mean transpiling time? Honest question, don't have any experience with
web frameworks.

~~~
yorwba
Transpiling is a form of compiling. So, yes.

~~~
ramzyo
Thanks.

------
paulcole
> be able to take difficult feedback with grace.

Shouldn't it be more important for senior team members be able to provide
difficult feedback with grace?

~~~
scrollaway
Did you comment on the wrong article? That quote is from
[https://technology.cloverhealth.com/how-to-interview-
entry-l...](https://technology.cloverhealth.com/how-to-interview-entry-level-
software-engineers-daaecf9db97)

~~~
paulcole
yeah thats what i did. too late to delete

------
Bizarro
_It never hurts to have a deeper understanding down the stack..._

I have an issue with these kind of memes that are similar to the "it doesn't
hurt to know Lisp or Haskell"....whatever.

It might hurt your goals. There's an opportunity cost involved. So you're
either learning a new language or digging into the source code of React at the
expense of something else.

It's not a zero-sum game, but closer to zero-sum then what these memes would
have you believe.

~~~
allover
You'll always find a counterexample for 'it never hurts', it's a turn of
phrase.

~~~
pc86
How do you turn a phrase? :)

~~~
dentemple
very carefully

