[HN Gopher] React Docs Beta - rewritten with hooks and interacti...
___________________________________________________________________
React Docs Beta - rewritten with hooks and interactive examples
Author : jitl
Score : 176 points
Date : 2021-10-23 15:06 UTC (7 hours ago)
(HTM) web link (beta.reactjs.org)
(TXT) w3m dump (beta.reactjs.org)
| wheybags wrote:
| As someone who's new to react, and basically started with hooks:
| am I missing something? The old class based code looks so much
| better than the hooks magic. Is this just js people hating OO or
| is there something deeper?
| jitl wrote:
| The hooks approach is all about making the UI more
| _incremental_. I have an easier time reducing the work the
| computer has to do by using hooks like useMemo and useEffect
| compared to custom prop diffing. For example, building complex
| query forms over large amounts of in-memory data that do
| minimal async requests and re-computations when props change is
| much easier with hooks. useEffect /useLayoutEffect also makes
| behavior lifecycle for weird DOM stuff like MutationObserver
| easier to manage since you don't need to spread it out in like
| 6 different lifecycle callbacks.
|
| On the other hand, class components have a better developer
| experience for components that are mostly dumb renderers that
| bind a lot of event handlers - `private handleFooClick = () = >
| { ... }` is a lot nicer than `const handleFooClick =
| useCallback(() = > { ... }, [...])` and you don't have to worry
| about ordering between your methods definitions in classes.
| Declaration ordering between hooks is annoying, but what you
| get in return is incremental computation. If you don't need
| that stuff, sure - use a class!
|
| I do find more and more frequently as I'm working with class
| components thinking "dang, this would be much easier with
| hooks", especially for tricky problems. I don't find the
| opposite to be true in hook components.
| srcreigh wrote:
| If you want to see really ugly code, read the docs about Higher
| Order Components [0].
|
| Hooks are better for building component abstractions than HOCs.
| Code which can hook into mount/unmount, can trigger re-renders
| via state updates, etc.
|
| Also, dependency arrays in useEffect and useCallback are better
| than this kinda stuff in shouldComponentUpdate lifecycle
| method: if (prevProps.commentId !==
| this.props.commentId) { return true; }
| return false;
|
| [0]: https://reactjs.org/docs/higher-order-components.html
| debaserab2 wrote:
| I find dependency arrays to be neither intuitive or easy to
| debug. When you're missing a parameter or use the wrong one
| React can emit some pretty weird side effects that are hard
| to track down back to the dependency array.
|
| I generally like shaping my components as functions first and
| use hooks because I have to in order to do this but
| definitely not because I find them easier to understand than
| component lifecycle methods (even if they may be less
| verbose).
|
| To me, hooks are the ugly part, writing component as a single
| function is the part that makes it worth it.
| jitl wrote:
| Do you use the exhaustive-hooks ESLint rule? I think
| without it hooks are unusable in a team setting.
| jolux wrote:
| For one thing they currently plan to maintain classes
| indefinitely, so if you really wanted to get started with
| classes you can just do that, and learn hooks later.
|
| That said, the React docs are pretty clear about the motivation
| for hooks and I think that is a good place to start:
| https://reactjs.org/docs/hooks-intro.html#motivation.
|
| After that, this post explains roughly how hooks actually work
| (in a simplified way), and why they're a more natural fit for
| what's happening under the hood:
| https://www.netlify.com/blog/2019/03/11/deep-dive-how-do-rea...
| recursive wrote:
| > That said, the React docs are pretty clear about the
| motivation for hooks and I think that is a good place to
| start: https://reactjs.org/docs/hooks-intro.html#motivation.
|
| I've read this a number of times, and none of the point make
| sense to me.
|
| > It's hard to reuse stateful logic between components
|
| Is there some reason you can't use a `get(key)` and
| `set(key,value)` between class components. I don't really
| grok react, despite trying, so maybe there's a reason that
| doesn't work.
|
| > Complex components become hard to understand
|
| I don't understand what the hard part is supposed to be here.
| If you have a method that's dealing with too many concerns,
| you can just add methods, and then call those.
|
| > Classes confuse both people and machines
|
| `this` is pretty confusing in javascript, but yet that's the
| language react is targeting. And it's no less confusing in
| prototype-based objects. And after having tried to learn both
| hooks and `this`, it certainly doesn't seem like hooks are
| conceptually easier than `this`.
|
| Probably my fundamental problem with hooks is trying to
| understand which state goes with which component-function
| invocation. It just seems like dark magic that _usually_
| works. I 've tried to read the implementation to figure it
| out. It seems to depend on the famous DOM diff feature. It
| was about at that point that I lost the plot.
|
| So, I know I'm an outlier, but class-based components just
| make sense to me. They can be complex, but fundamentally
| comprehensible. Function components seem like a fake
| simplicity that's masking a complexity that I've yet to
| figure out.
| srcreigh wrote:
| > Is there some reason you can't use a `get(key)` and
| `set(key,value)` between class components. I don't really
| grok react, despite trying, so maybe there's a reason that
| doesn't work.
|
| You can and the hooks way is better.
|
| The class based components way is to wrap component in a
| HOC. The common state is stored in the HOC. The HOC passes
| the state to the component via props. This can include
| functions, so maybe your component can call
| `this.props.reloadApi()`, which changes HOC state, which
| results in new props sent to your component.
|
| The hooks way is described here. [0]
|
| What's wrong with Higher-Order Components?
|
| One answer is that it's weird to call something a
| "component" which doesn't render any UI. In other words,
| why is an interface to access remote data a "component"?
|
| Another answer is that HOCs break the diff algorithm
| without special care see. [1]
|
| [0]: https://reactjs.org/docs/hooks-custom.html
|
| [1]: https://reactjs.org/docs/higher-order-
| components.html#dont-u...
| imbnwa wrote:
| To better understand the move away from OO interfaces, and
| mixins for behavior sharing, first read 'Mixins Considered
| Harmful'[0], then for a counter point read 'Why are Mixins
| Considered Harmful?'[1], then the follow-up that POCs a
| mixin implementation that responds to the issues raised
| about mixins[2]
|
| [0]https://reactjs.org/blog/2016/07/13/mixins-considered-
| harmfu... [1]http://raganwald.com/2016/07/16/why-are-
| mixins-considered-ha...
| [2]http://raganwald.com/2016/07/20/prefer-composition-to-
| inheri...
| acemarke wrote:
| The post "Why React Hooks?" helps explain the historical
| context and reason for their creation:
|
| https://ui.dev/why-react-hooks/
|
| I also discussed some of the tradeoffs in a conference talk and
| blog post:
|
| https://blog.isquaredsoftware.com/2019/07/blogged-answers-th...
|
| https://blog.isquaredsoftware.com/2019/09/presentation-hooks...
| afavour wrote:
| It's a better representation of what's going on underneath but
| FWIW I agree with you, there are very few instances where I
| find hooks code that's as readable as class-based code.
|
| I know I'm not typical at all but hooks kind of marked the
| point where I lost interest in keeping up with the changes in
| React. I'm lucky that my job doesn't require me to and I've had
| a great time exploring options like Vue and Svelte. Svelte in
| particular feels like it takes the opposite approach to hooks-
| based React: rather than force you to think about the way React
| is processing things it lets you write code the way _you_ think
| about things and transpiles it into working JS.
|
| Beyond "everyone uses it" I can find few reasons to prefer
| React these days.
| moneywoes wrote:
| Looking to reacquaint myself with React. Should I skip over class
| components?
| adzm wrote:
| Don't skip over class components. There is a ton of existing
| code and libraries that use it.
| evantahler wrote:
| Yeah. Most use cases just need hooks and functions now!
| anarchy8 wrote:
| It really should have Typescript as well (optionally, that is)
| kall wrote:
| I think the way the docs introduce functional components
| (destructure the props argument right away) sets you up for
| success with TypeScript. The main ways to get started that they
| recommend (CodeSandbox, CRA, next.js) let you add typescript
| down the line with no hassle, so you don't loose out by
| starting without it. Seems better to teach people one thing at
| a time. React with TypeScript really doesn't look all that
| different and if you just drop what they teach you into an
| existing TS project, it will work ok.
|
| An official "Using React with Typescript" doc that shows good
| patterns for typing props and state would be nice though.
| acemarke wrote:
| The de-facto standard resource on React + TS is the
| community-maintained React TypeScript Cheatsheet site:
|
| https://react-typescript-cheatsheet.netlify.app/
|
| But yes, I'd love to have some of this info added to the
| official docs as well.
| danabramov wrote:
| Yeah we'd like to add something (potentially even toggles)
| but out of scope for the first iteration.
| acemarke wrote:
| Sweet!
|
| As an FYI for later reference, Lenz Weber has a Remark
| plugin that compiles TS to JS in code samples - we use
| that in the Redux Toolkit docs. I think Orta Therox may
| have something similar going on with his "Shiki Twoslash"
| tooling, but not entirely sure.
| TameAntelope wrote:
| Well, this _is_ Typescript, isn 't it?
| _fat_santa wrote:
| That would be amazing. I would love it if they put together a
| guide to proper typechecking around hooks.
| colesantiago wrote:
| Does anyone know what UI components or style this documentation
| uses?, I have to say the UI style is really nice and modern.
| fortydegrees wrote:
| The CSS is tailwind
| 999900000999 wrote:
| With all the Facebook bad posts, React JS is much better with FB
| funding then without.
|
| You can legitimately learn programing just from reading though
| the React JS tutorials. Many other frameworks lack such good
| documentation.
| kaycebasques wrote:
| Anyone know of any issues / blog posts / etc. on "lessons
| learned" from the overall docs refactoring project?
| acemarke wrote:
| I had asked Rachel Nabors about that a few weeks ago, and she
| said she had a post drafted and would put it up post-beta
| launch.
| warpech wrote:
| 'New React Docs' GitHub Issue is interesting and shines some
| light on the changes.
|
| Significantly, note that it took a litle bit more than a year
| from the formulation of this issue to the Beta version. Knowing
| that there were some holy wars to be fought on the way, I don't
| think it's too long. Congrats to the team who worked on it!
|
| [1] https://github.com/reactjs/reactjs.org/issues/3308
| h1fra wrote:
| Very excited about this release, the website is so much better
| and easier to read. Congrats!
|
| (Disclaimer I work at Algolia in the Crawler team) Not to hijack
| this thread, but the search is now powered by Algolia custom
| crawler (still Docsearch but used to be a custom scrappy implem),
| it should match previous high level of expectation, but we'll
| appreciate any feedback on the relevancy.
| yepthatsreality wrote:
| Glad to see these improvements. My previous favorite part of the
| older React docs was the several times looking up a lifecycle
| method I was partially familiar with only to see it had been
| deprecated for a new similar method.
| [deleted]
| ramesh31 wrote:
| Very nice. I have to admit I was highly skeptical of hooks at
| first, but at this point I'll never go back to writing classes.
| Functional components are the truth.
| chadlavi wrote:
| These kids these days get better docs than we ever dreamed of.
| And that's a good thing.
| [deleted]
| jerrygoyal wrote:
| hooks are yet to be added to new docs (only useState for now).
| brundolf wrote:
| useState is a hook (arguably the main hook). Maybe you meant
| useEffect?
| rapfaria wrote:
| Well, indeed beta:
|
| https://imgur.com/a/iIeoL5A
| acemarke wrote:
| 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
|
| [1] https://blog.isquaredsoftware.com/2020/05/blogged-
| answers-a-...
|
| [2] https://overreacted.io/a-complete-guide-to-useeffect/
| tbezman wrote:
| Potentially controversial post on why we memo all the things.
| https://attardi.org/why-we-memo-all-the-things/
| aszen wrote:
| Interesting 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 wrote:
| I 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 wrote:
| Because 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 wrote:
| Makes sense. How about making that the default behavior of
| React and providing a React.dontMemo(...) API to opt out?
| lewisl9029 wrote:
| I also generally fall on the side of useMemo'ing everything
| pre-emptively, and this is a good argument for its effects on
| performance. However I think a more important effect is that
| preserving references between renders (and lack thereof) now
| has a direct effect on behavior due to useEffect's dependency
| list.
|
| If a downstream component's useEffect depends on a prop that
| hasn't been useMemo'd, their effect will be executed on every
| render due to the changing reference, and there is nothing
| that can be done at the downstream component to alter that
| behavior. This means they'd have to trace the prop back to
| its source and refactor it to useMemo, which can be a very
| painful exercise as I'm sure anyone who has done it can
| attest to. For props that come from third party libraries,
| this might not even be an option, which is why pre-emptively
| useMemo'ing is even more crucial for reusable abstractions
| like shared hooks and components.
|
| And yes, I realize that the React docs currently recommend
| using useMemo only as a performance optimization, not as a
| semantic guarantee, but I believe that ship has sailed. There
| is so much code in the wild today that useMemo and then pass
| the result to some useEffect downstream, that they can't
| really afford to break in practice. I think the only
| practical option at this point is to strengthen the original
| useMemo with a semantic guarantee, and then introduce a
| separate useMemoForPerformanceOnly (with a better name) hook
| that can be used to opt-out of the semantic guarantee to
| allow React to evict memoized results to optimize for memory
| usage.
| mattwad wrote:
| I feel like you could go more into depth to defend your
| assertion "no memo is not an option." As someone who has
| spent hours on jsperf back in the day -- my apps feel blazing
| fast already. Many devs I know also don't use memo or
| useCallback at all. It sounds like you're adding an entire
| layer of extra abstraction "just in case." But then again,
| maybe your use case makes it warranted.
| eatonphil wrote:
| Same, I haven't seen a need for it for performance yet
| across a few companies and open source apps I've worked on.
| seedboot wrote:
| Congratulations I've been looking forward to starting reading
| this for some time!
| acemarke wrote:
| heh, 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-
| 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)
___________________________________________________________________
(page generated 2021-10-23 23:00 UTC)