5 ms·
I am _so_ very excited about this! This is going to be a huge help for the community. These new docs are an incredible improvement over the old docs. In-dept
by acemarke 5y ago
I am _so_ very excited about this! This is going to be a huge help for the community. These new docs are an incredible improvement over the old docs. In-depth tutorial and concept explanations, live editable sandboxes, coverage of key concepts and common gotchas, and much more!
See the docs repo PR [0] for background on what content is currently included, plans for further content and site improvements, and feedback on the new docs.
For why this is a big deal: the old docs were good in some ways, but very weak in others.
By far the biggest issue is that hooks were announced in Oct 2018 and released live in early 2019, but the tutorials and explanations were all still written with class components and showed older patterns, well after the community had fully adopted hooks as the standard approach. The hooks info was a totally separate section of the docs. That section was _good_, but it made it really hard to continue recommending the React docs as a good starting point for someone new to React.
The docs have also skimmed past a lot of important information, usage concepts, and info on how React itself actually works. For example:
- React's batching behavior is something that frequently trips people up, but the current docs just have a note that says "updates may be async"
- Using the hook dependency arrays correctly is vital, but the current hook docs describe it as sort of an after-thought
- There's no information on what a "reducer function" is or how to use one correctly.
That's part of why I ended up writing a 9K-word "Guide to React Rendering Behavior" post [1], and Dan wrote a similar "Guide to `useEffect`" [2] article.
Fortunately, the new docs address a lot of those concepts directly, which should really help people who are getting started.
[0] https://github.com/reactjs/reactjs.org/pull/3965 https://github.com/reactjs/reactjs.org/pull/3965
[1] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
[2] https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/
- seedboot 5y agoCongratulations I've been looking forward to starting reading this for some time!
- acemarke 5y agoheh, to be clear, _I_ didn't work on this at all :) It was primarily Rachel Nabors and Dan Abramov from the React team doing the writing: https://beta.reactjs.org/community/acknowledgements#react-docs https://beta.reactjs.org/community/acknowledgements#react-do... (I did get to see an early alpha preview version and gave some feedback - other than that I've just been very eagerly awaiting this coming out)
- tbezman 5y agoPotentially controversial post on why we memo all the things. https://attardi.org/why-we-memo-all-the-things/ https://attardi.org/why-we-memo-all-the-things/
- aszen 5y agoInteresting post, makes u wonder why the hell doesn't react do it by default. I'm really surprised to see that i have to think about performance in react apps so much, coming from elm i expected it to be all faster by default
- dham 5y agoI wonder every day why React doesn't do a lot of things by default. Imagine specifying memoization dependencies by hand. Most of the stuff is named or put in the framework to raise engineering salaries for making CRUD applications or to make them feel smarter about doing basic web work. React will go the way of JQuery in 5 years. We'll kindly thank it for it's contribution to the framework space and move on. No one in their right mind would pick it up for new apps over Vue, Svelte, Angular hell even Ember. Then you have the new wave of frameworks coming out. Only way that React is usable is only for the view layer with Mobx holding any other state.
- brundolf 5y agoBecause Elm has language-level support, while hooks try to do things that should be language-level but aren't, which is why they have so many footguns in general. To get concrete, there's no possible way this function could be automatically memoized at a library/framework level: const myCallback = () => setFoo("bar")
- catlifeonmars 5y agoMakes sense. How about making that the default behavior of React and providing a React.dontMemo(…) API to opt out?
- midrus 5y ago
- cageface 5y agoAll the elegance of React & hooks falls apart once you have to start worrying about performance. Managing dependency arrays is tedious and error prone and the source of many subtle bugs. Code stuffed full of memo calls is not pleasant to read. It really feels like you're doing the work that a language or complier should be doing for you.