Hacker News new | past | comments | ask | show | jobs | submit login
React Docs Beta – rewritten with hooks and interactive examples (reactjs.org)
329 points by jitl 41 days ago | hide | past | favorite | 96 comments



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/


Potentially controversial post on why we memo all the things. https://attardi.org/why-we-memo-all-the-things/


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.


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.


Same, I haven't seen a need for it for performance yet across a few companies and open source apps I've worked on.


Every single time I’ve needed to use memo the performance gains where obvious.


A: You'll know when you need it. Until that point one is firmly in the realm of premature optimization.


The post points out that given memoization in many cases avoids serious perf/functional issues not memoizing may be considered premature optimization.


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


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")


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.


Makes sense. How about making that the default behavior of React and providing a React.dontMemo(…) API to opt out?


Or even better, provide a top level configuration option, like:

ReactDOM.render(element, document.getElementById('root'), {memo: true});

Just dreaming...


This one is interesting, because React has a separation between the renderer and the library. There is a different renderer for e.g. react native, or even for the terminal (!!). It’s a little ambiguous where memoization falls (does it belong to the renderer, or to the core?). I totally agree that being able to switch on behavior for an entire tree or subtree would be ideal, but react tends to use components for that as well (e.g. <React.StrictMode>). Perhaps this should be a component, it could even be implemented via the context system.


This is great. And great explanation of the reasonings.

I wonder why React doesn't provide a configuration/flag/option to just do this by default if anybody wants to.


The problem with using useMemo & useCallback everywhere is that the dependency arrays are really easy to get wrong. Small changes can easily lead to stale data or render loops. I'd much rather people take the time to consider each case. The React profiler is your friend here.


I think if you use them 100% of the time alongside eslint dependency arrays are really hard to get wrong. If you rarely use them, you always get them wrong.


If you just blindly follow the eslint suggestions you can very easily wind up with render loops. You need to carefully consider and understand the dependencies in each case. And if you want to do something specific when only one of your dependencies changes you need even more gymnastics.


The reason you end up with render loops is usually because you didn’t memo something. If you memo everything you can avoid that issue.


All 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.


Congratulations I've been looking forward to starting reading this for some time!


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)


I'm clearly missing something with hooks. The main selling point seems to be that your code is more "functional" because you are typing the 'function' keyword more often, but the new functions you can write are not pure functions. They are "react functions" and have all kinds of global baggage, just like component classes.

Having more impure functions doesn't do anything for me aesthetically, it might as well be a class. At least classes force you to declare (in typescript) the type of your state, with hooks it's all hidden inside. That seems less functional rather than more.


The core of it is getting closer to true "reactive" programming. If you use hooks right™, you generally don't have to worry about how to handle values over time. React does all that plumbing for you (which is why we need all the dependency arrays).

This for me is the main advantage over class components. You don't need to worry about the various lifecycle methods (including having separate methods for componentDidMount and componentDidUpdate and making sure you do all the plumbing right when your parent changes props that you weren't expecting).

IMO, React really could have benefited from devoted language syntax for this (like Svelte does) to automagically and statically track all the dependencies. But React has an ethos of being "just JavaScript" (even JSX desugars to relatively straightforward React.createElement calls, and you can treat those nodes like regular JS objects, pass them around willy nilly, etc.), so it didn't happen (and instead we have lint rules like ESLint rules-of-hooks that are designed to enforce the invariants that really the programming language should enforce).

Edit: The other nice things about hooks is their composability (and this is in fact related to what I said above). With class components, a component can have one state object, so it's hard to compose with other "mixin" type behaviors that need their own dedicated state. You ended up with weird patterns like higher order components (à la Redux withStore) that have basically ceased to exist with hooks (replaced by a useStore hook which can opaquely manage its own state under the hood).


> IMO, React really could have benefited from devoted language syntax for this (like Svelte does) to automagically and statically track all the dependencies. But React has an ethos of being "just JavaScript" (even JSX desugars to relatively straightforward React.createElement calls, and you can treat those nodes like regular JS objects, pass them around willy nilly, etc.), so it didn't happen (and instead we have lint rules like ESLint rules-of-hooks that are designed to enforce the invariants that really the programming language should enforce).

You’re looking for solid.js

https://www.solidjs.com/

It’s “just JavaScript” like React, but with automatic dependency tracking. My understanding is that React hooks are the best React can do given backwards compatibility requirements. Reacts beast feature is it’s ecosystem.


> Edit: The other nice things about hooks is their composability (and this is in fact related to what I said above). With class components, a component can have one state object, so it's hard to compose with other "mixin" type behaviors that need their own dedicated state. You ended up with weird patterns like higher order components (à la Redux withStore) that have basically ceased to exist with hooks (replaced by a useStore hook which can opaquely manage its own state under the hood).

This is more because the React team didn't care to figure out proper mixins beyond "Object.assign all the things"[0]

[0]http://raganwald.com/2016/07/20/prefer-composition-to-inheri...


So imagine you have a class and you wan't to abstract away some stateful logic. You can use inheritance or mixins. You can use composition. You have to come up with some solution for reactivity, which means setting up observers and disposables. You might have to set up some variables for storing the emissions from those streams.

I currently have to use an Angular-like framework, and my classes usually have 10-50 lines just setting up calls to other abstractions.

Hooks simplify that: setup, teardown, state and reactivity all in a single function call.

I'm not saying they're perfect, I would probably prefer a compiled solution like in Svelte. But when has anything ever been perfect.


Hooks make logic composable in the same way components make rendering composable. That composability allows for organizing code by what it does, rather than when it runs.


It's less verbose. It makes it more readable, in my opinion. They could have implemented the very same thing with a class, but they didn't.

It's not about functional vs OOP. It's just about readability.


Hooks are truly the most hideous API I have ever encountered. The whole thing just feels so forced and unnecessary.


That’s just– like– your opinion, man.


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?


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.


It is weird, isn't it? I like class components but with complex functionality or rather a bigger codebase functional components are much easier to work with and adding hooks later on is much easier than updating class components.

But for some reason, picking someone else's class component and working on it feels much easier than someone's functional component.

I 100% agree with the last statement, most problems feel easier to write with hooks than with class components.


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.


When React introduced hooks they also massively expanded the library's API, so there's a complexity cost to that.

While I love working with hooks and do so daily, I definitely felt some remorse for those now having to figure out when and how to use memoization, dependency arrays, useCallback, etc, etc etc. React in its first formulation was utterly simple and beautiful.

In defense of hooks however, it's good to keep in mind that now you can do a lot more than you could, and being able to share business logic so easily across an application is an elegant abstraction.


This is exactly how I feel. I remember watching the hooks announcement video and being surprised that classes, 'this', and the lifecycle methods were considered so ... problematic. It seemed like hooks were solving problems that, for me at least, were totally and completely non-existent.

It didn't help that my first foray into hooks was trying to build a simple clock with `setInterval`:

https://overreacted.io/making-setinterval-declarative-with-r...

I really need to give Svelte a try.


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


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.


The general advice is to write your hooks without dependency arrays first, and then only add dependency arrays once you know what your hook body looks like. I find that that generally makes them much easier to debug. Also, yes, the exhaustive-hooks ESlint rule is a life-saver.


Do you use the exhaustive-hooks ESLint rule? I think without it hooks are unusable in a team setting.


It helps a lot, but it has gaps, because it reasons about syntax and not values. A complete solution is intractable without integrating this stuff at a language/type-system level (and I don't mean TypeScript; TypeScript can't represent hooks' relationships either).


> If you want to see really ugly code, read the docs about Higher Order Components

Never found HOC ugly, it's a normal function, not a magic one that hooks into React internals. Anyone familiar with OOP also regcognizes it as adapter. I think people tend to confuses syntactical simplicity with conceptual simplicity. But even syntactically, I don't find hooks simple once we pass the toy code examples.

> Hooks are better for building abstractions than HOCs

HOCs are more explicit, they change the props signature of the component. So if you like magic, you'd prefer hooks.

Hooks are not better abstraction, they are better building blocks because they compose more nicely.

A good abstraction is something you can pass around and use liberally without knowing the inner working. You can pass a HOC around and put it in conditional etc. Can't do that with hook because the inner working prohibits that and you are required to know such caveats.


Wouldn’t a purecomponent do this comparison built in


Yeah. The same type of thing needs to happen in componentDidUpdate for side effects (reload data from API) etc.


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...


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...


> 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.


> 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...


But why use a HOC? `useState` is a global function. I don't see a problem using some kind of static global state factory thing. Likewise, you could just call set() and get() without any of the fancy stuff.

Maybe I'll try implementing this to show what I mean/learn why it wouldn't work.


Are you talking about having some global store that you're calling `set()` and `get()` against?

If yes, the reason you can't just do that is because if that is done naively then components using `get()` won't know that they need to re-render when a `set()` is called somewhere else.

Not done naively and you do have global stores built for this, like Redux or MobX, which handle this gracefully and (at this point) use hooks under the hood and in the dev-facing API to accomplish this.

Tbh this is also now built-in to React with the `useContext()` hook, which allows you to do the same. `useState()` should really only be used for local-to-a-component level state (though technically you can obviously pass down the state/setter to any child components, but given the above I find it's frequently better to `useContext()`).


Yes. Global store with subscriptions. I barely know react, but I knocked one together in half an hour.

https://codepen.io/tomtheisen/pen/NWvdXyJ

I already like it better than hooks. Everything's out in the open. No magic or hidden dependencies.


Yep it's all out the open and there are many things wrong with it. Fix all the problems with it and you've re-invented the wheel and it's no longer super simple.


    // this could be made to track actual depencies with more granularity
    subscribe(() => this.forceUpdate())
You're well on your way to building a decent system here...

I guess if you don't pass your dependencies as an array to a function called useEffect, you aren't using hooks. Win!

And if you need a specialized function to only update 1 component instead of all of them, just make sure it isn't returned by a dastardly magical function called useState.


> I guess if you don't pass your dependencies as an array to a function called useEffect, you aren't using hooks. Win!

You joke, but yes. Also, you don't have to follow these. https://reactjs.org/docs/hooks-rules.html

And you don't have to rely on the diff remembering which state goes to which widget. To its credit, it seems to do it right at least 99% of the time.

I recognize I'm tilting at windmills here. React is a juggernaut, and many people love it. In fact, many people like the exact things that I don't. And that's ok.


You may not realize it but you're just rewriting hooks here. The example you give is too simple to show the problems with your initial approach. The main one is that if you're not extremely careful about when you're writing and when you're subscribing, you're going to end up with a race condition. Similar problems if you call "subscribe" in the wrong place. This is not a safe solution to the problem, and it does not circumvent the need for rules about usage.


I'm sure there are complexities that I hadn't considered yet, but I don't see how a race condition can be one of them. Outside of workers, there's really no way to simultaneous concurrency in js.

Order of dispatch to subscribers seems like it create similar problems, although it would be fully deterministic, rather than a race.

Anyway, thanks for your insight.


> Outside of workers, there's really no way to simultaneous concurrency in js.

You're largely right but this part is mostly wrong in practice because of async. You can create race-like conditions very easily with promises/async if you're not careful.

> Order of dispatch to subscribers seems like it create similar problems, although it would be fully deterministic, rather than a race.

Yes, that's closer to what I meant. Not a data race, but you could end up in a loop.


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...


But it's not really OO, it's some ugly mix with rules:

* don't put side-effect initialization code into the constructor * use state to render your components * don't set state directly, use setState, _unless_ in the constructor * if you want to use stores, declare a static field

You don't inherit classes, as there are many special methods, and overwriting them would mean calling super - before your method body? After? During?

Class based components only pay off if you have truly large and complex components, and that's an antipattern in react anyway. Hooks are concise, and super clear if you keep it simple (there are also additional rules not enforced by the compiler, like putting all side-effectful code into useEffect, but still).


The sense I get is that the original React model has some pretty significant complexities, especially around shouldRender and prop / state analysis, and hooks present a big improvement on that.

I don’t think that the class-vs-function divide is the fundamental reason for the problems with the old model or the improvements with the new model. Rather, I think the learnings from the original approach informed the system and resulted in a step forward.

I find that once I need to manage a nontrivial amount of state, the functional model really feels wrong — useContext, I’m looking at you! And I wouldn’t be surprised if we end up with another turn of the crank that introduces a class-based (or prototype-based) approach with a better set of abstractions at some point down the line.


These kids these days get better docs than we ever dreamed of. And that's a good thing.


I’ve found react to be an outlier in this regard. The React docs are phenomenal and in combination with create-react-app it’s super easy to start up a new project. I can’t say the same about the majority of other frameworks I’ve encountered.


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.


Does anyone know what UI components or style this documentation uses?, I have to say the UI style is really nice and modern.


The CSS is tailwind


who cares, they're asking about the design


Why respond with this tone if you have no idea what tailwind css is?

The "design" is the theme provided by, you guessed it, tailwind css.


> if you have no idea what tailwind css is

I didn't know that taiwind also includes a default theme

I'm not fond of the way it's getting shoved down everyone's throat. Why is it that people won't shut up about their crappy choice of software development tools. Who cares.


There isn't a single example of it being "shoved down throats" in this thread, not even close. One person liked the visuals of the documentation and asked what themed it, another person answered. Then you came along and complained about a bunch of stuff that wasn't even happening. Here you are defending outdated and clunky HoCs, which itself is more off-topic than what's styling the OP's documentation.


> Here you are defending outdated and clunky HoCs

I replied to someone who brough it up

> off-topic

You do realize this is a React discussion?

> There isn't a single example of it being "shoved down throats"

Hey sorry I replied with the wrong tone, but imagine you don't know that tailwind also comes with a style, someone asks about the style or specific component lib or whatever, you see a reply that "it's tailwind", which to you must be as helpful as answering with "it's css"


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.


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.


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.


Anyone know of any issues / blog posts / etc. on "lessons learned" from the overall docs refactoring project?


'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


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.


Well, indeed beta:

https://imgur.com/a/iIeoL5A


Doesn't seem like a bug indicative of being beta.

The bug could obviously be fixed by looping back to 0, but the correctness is not the important part.

Though, reporting such an issue does not seem to be possible, hmm :(


Nice find! One of the pages has an exercise where you need to fix this bug.


Looking to reacquaint myself with React. Should I skip over class components?


Yeah. Most use cases just need hooks and functions now!


I’d say so, unless you have a particular reason to learn them. I haven’t written a class component in well over 2 years.


Don't skip over class components. There is a ton of existing code and libraries that use it.


I’d say just don’t learn about class components until you run into them


hooks are yet to be added to new docs (only useState for now).


useState is a hook (arguably the main hook). Maybe you meant useEffect?


why is it not called useReactDocs?


It really should have Typescript as well (optionally, that is)


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.


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.


Yeah we’d like to add something (potentially even toggles) but out of scope for the first iteration.


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.


That would be amazing. I would love it if they put together a guide to proper typechecking around hooks.


Well, this is Typescript, isn't it?


It flow since it's from FB as well




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: