Closed rachelnabors closed 1 year ago
Hi! I noticed that the new documentation lacks explanation on how some form HTML elements like
Re: https://github.com/reactjs/reactjs.org/issues/3308#issuecomment-1249376097
Yeah that will be added.
Re: https://github.com/reactjs/reactjs.org/issues/3308#issuecomment-1243907408
Agree, I'll simplify it.
Currently, the search bar in the sidebar vanishes on scrolling down. Keeping it always in view would be nice for UX.
Similar to TailwindCSS docs: https://tailwindcss.com/docs/installation
In the lesson Lifecycle of Reactive effects of escape Hatches, What an Effect with empty dependencies means section's code sandbox has a small mistake. The roomId props is still being passed in the ChatRoom component even though it is not being used there.
Re: https://github.com/reactjs/reactjs.org/issues/3308#issuecomment-1250101477
Thanks, fixed in https://github.com/reactjs/reactjs.org/commit/a6c164d66a25821fa56928de303f657d3cffcc1b.
Re: https://github.com/reactjs/reactjs.org/issues/3308#issuecomment-1249932907
Is this reproducible on built-in Android browser, or Kiwi browser specifically? I'm not sure what engine/version Kiwi is.
Something I see people try to do is define a component as a closure inside another component (usually in order to use some value in the parent scope). I think this is not usually a good pattern and can lead to bugs.
const ParentComponent = (props) => {
const ChildComponent = () => {
return (<span>hello, {props.name}</span>);
}
return (<div><ChildComponent /></div>);
}
Is my understanding correct that this should be avoided? Would it be worthwhile to include a note about it somewhere in maybe "/learn/your-first-component" or "/learn/keeping-components-pure"?
As someone who wants to learn React and has stumbled across the 'original' docs, and this new beta docs, which one is it recommended for me to go through? I'm hesitating on beta because it's not yet fully finished (~95%, right?) and based on this Issues page lacks a few things. Not sure if they're minor things, though. I'm having trouble evaluating this trade-off.
Also, is there an estimate as to when the original docs will have a banner saying to move to the new beta docs (i.e. the official 'move-to-the-new-docs' date?)? Thanks :)
@olliequ absolutely 100% go with the new beta docs. The API ref isn't 100% done, but it is absolutely the right place to start learning:
(per earlier in the thread, I've been begging for the beta docs to be at least visibly linked from the new ones for months now, but the concern was that they were too incomplete and people might get confused. 🤷♂️ seems like the primary tutorial content is done and the API ref is being filled out now, so hopefully soon-ish?)
Hear, hear. After https://github.com/reactjs/reactjs.org/pull/5103 is finished and merged, we will link to the beta site prominently from the main one.
One thing I'm trying to wrap my head around in the Queuing a Series of State Updates lesson is...early in the lesson it says
"The UI won’t be updated until after your event handler, and any code in it, completes. This behavior, also known as batching..."
but in the first challenge ("Fix a request counter") if you click the "Buy" button 1x, you can see the Pending count switch from 0 to 1 to -1. Based on the earlier statement about batching I thought that those updates would be batched, meaning it would go straight from 0 to -1? Not sure if this is something obvious that I'm not understanding, or maybe it's worth explaining this behavior in the solution to the challenge?
@lhendriks1
I did that lesson today actually and had same problem of wrapping my head around it lol. I believe it's because you have await before second setter function, so second setter function is waiting for this await to finish. But as you said the way docs explained it, it should probably wait for await to finish, second setter function to run and then and only then rerender. But it rerenders after first setter function. I guess, but idk why.
Oh yeah that's a good catch. Batching, indeed, won't work across the await
calls. I'll add to a TODO list of edits.
Noticed there is no mention of the jsx file extension (.jsx) in the Exporting and importing a component section. Curious why, as I recently joined a project where .js
is used which causes my editor to not highlight the JSX inside. Using the jsx extension seems more appropriate, right?
@Siilwyn No. *.jsx
has long been considered legacy. See this and this. You should configure your editor so that it understands JSX in *.js
files. (On the other hand, *.tsx
is still widely used because it tells the TypeScript compiler to parse code differently.)
@smikitky ah thanks for your reply. I have to say I find that very backwards as a file extension should indicate what syntax a file contains, that's me being a purist, but good to know jsx is still supported.
It's kind of tricky. Early on there were a lot of competing syntaxes. So .jsx
wouldn't give you the full idea anyway — it could've had Flow syntax, or some experimental stage-0
proposal, or something else. It's weird if you're using non-standard syntax like Flow in a .js
file but then JSX is out of question. Now that JS extensions have mostly settled, and TypeScript chose .ts
/ .tsx
distinction, maybe there's an argument that we should follow. In practice, in my opinion, the mental burden of renaming the files there and back whenever you need to add a bit of JSX makes it too annoying.
The banner is up.
Great to see new docs with the most modern practices!
However, why are we still using the className
attribute everywhere if class
is supported for a while now?
If I understand correctly, .tsx
was introduced many years ago not because it had a practical merit, nor because it was "ethically" correct, but simply because it was impossible to extend .ts
without breaking compatibility. Technically, .tsx
is not a superset of .ts
. For example, const a = <Foo>b;
is a valid type-cast syntax in .ts
but is an error in .tsx
. .js(x)
has had no such problem. Besides, one of the big recent changes is that people have started to use file extensions to distinguish module types (.mjs
and .cjs
). Although we need to keep using .tsx
for historical reasons, I think it's best to forget x
everywhere else. There is no good reason to revive .jsx
today and also introduce .cjsx
, .mjsx
, .mtsx
and .ctsx
.
In any case, it would be desirable to discuss file extension on a FAQ page or in a deep-dive section.
Docs say I can do this in render(although in many cases not recommended):
function Video() {
const playerRef = useRef(null);
if (playerRef.current === null) {
playerRef.current = new VideoPlayer();
}
...
Can I also do this?
function MyComp() {
const flag = useRef(false);
if (flag.current === false) {
flag.current = true;
SomeExternalObj.sideeffect(); // I want this to run once
}
...
I want the sideeffect
to run once. Motivation could be like this, registering interceptor instead of calling sideeffect
.
its not clear from new docs if I can do this, @gaearon can you clarify?
Ps. Using effect for this won't work as effects of child components may run first. Pps. In strict mode even this version will run twice, but apart from that, is it ok?
Hey in lesson "Importing and Exporting Components" challenge 1 of 1, when I write code I run into this error everytime:
Warning: React.jsx: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports. Check the render method of App. at App
It shows even though the code is the same as in solution and it only goes away when you remove everything and copy and paste same code. I think it's something worth checking or at least giving a note about it, people can spend significant amount of time trying to get this error go away, even though their solution is perfect.
On the /learn
page, in the final code sample, I think it would be clearer for the new user if, the first time you show passing in props to a component function, you don't dereference and instead use props
(or something similar) as a parameter e.g.
function MyButton(props) {
return (
<button onClick={props.onClick}>
Clicked {props.count} times
</button>
);
}
https://beta.reactjs.org/learn/sharing-state-between-components#step-3-add-state-to-the-common-parent presents the terms "Controlled and uncontrolled components" to indicate components with local state vs state-less, whereas the original docs use these terms to mean form components which either rely either on react state or the DOM as the "source of truth".
I would think overloading these terms in this way might cause confusion.
In a "Keeping Components Pure" in Describing the UI, in 3rd challange (Fix a broken story tray), once I solve the challange, the screen is still showing all previous "Create Story" and console is having 100 warnings about keys of previous elements in stories array.
I tried copying solution right after I reset the challange few times but its still doing the same thing.
Can formal or proper terminology be provided as well where appropriate? For example the section "Describing the UI " starts off by mentioning JSX and doesn't actually define it until you get to "Writing Markup with JSX"
Other than that great docs, love all the examples.
On the
/learn
page, in the final code sample, I think it would be clearer for the new user if, the first time you show passing in props to a component function, you don't dereference and instead useprops
(or something similar) as a parameter e.g.function MyButton(props) { return ( <button onClick={props.onClick}> Clicked {props.count} times </button> ); }
Agree with this, most of the code online uses props, new devs might be confused as to what is going on.
one of my minor complaints with the existing docs is that the search functionality isn't accessible directly by url, like /docs/search?q=usestate
.
i use a tool called alfred to define custom shortcuts to search documentation i use often, so i can search, for example, the redux docs in one step with https://redux.js.org/search?q=reducer
.
without being able to search by url, it takes me an extra step to open the react docs and then search them. not a huge deal, but it's a little time saver. 🙂 i'd love it if the new docs supported search queries. (i think i've seen algolia offer this out-of-the-box with its "see all results" functionality.)
The new docs seem biased in favor of using a boolean flag to avoid race conditions with data fetching in useEffect
, as opposed to using AbortController
.
Examples:
Is there any particular reason why these pages don't prioritize and give examples of AbortController
instead?
I am new to learning react. How is the beta react docs created? What technologies/frameworks were used?
@lizzthabet that's a cool idea, would you be interested in exploring a PR to implement this?
Is there any particular reason why these pages don't prioritize and give examples of AbortController instead?
AbortController wouldn't be sufficient unless you use it very, very carefully. Remember that there could be a few async steps between the fetch and setting the state, but aborting would only cancel the initial fetch callback. If aborting happens after, it's on you to make sure the code doesn't do anything. So effectively you have to write logic that's very similar to a flag anyway.
Would be nice to have links for "Deep Dive" sections. Sometimes I want to refer someone to it, but can't get a direct link to it.
AbortController wouldn't be sufficient unless you use it very, very carefully. Remember that there could be a few async steps between the fetch and setting the state, but aborting would only cancel the initial fetch callback. If aborting happens after, it's on you to make sure the code doesn't do anything. So effectively you have to write logic that's very similar to a flag anyway.
Thanks for the explanation! It might be worth adding a note with a similar point where AbortController
is mentioned on the "Synchronizing With Effects" page to make it clear that AbortController
isn't a simple substitution for a boolean flag.
Hello! New contributor here. I noticed some typos in the new beta docs that lead to the "Not Found" page and would like to open a PR to fix them. I followed the instructions per the Getting Started section and am able to open the reactjs.org site locally. However, I'm not sure how to access the beta docs on the browser locally, as the only link to it goes to the production beta.reactjs.org site.
To clarify, I can make the code changes to the beta docs locally, but I'm unsure how to test them. Any guidance would be greatly appreciated!
@melissapthai Are you CDed into beta
? The instructions are slightly different for running the beta docs server.
Ah ok I didn't realize there is another readme in the beta folder, wasn't clear from the root folder. Thanks, it works now :)
I am new to learning react. How is the beta react docs created? What technologies/frameworks were used?
Follow the new beta docs: Classes were exchanged with Hooks. (my favorite part) Interactive examples and visual diagrams were added. (beginners friendly)
Thanks, @gaearon
I think, I have found a minor issue in the beta docs. The first solution to "Fix a broken story tray" challenge in "Keeping Components Pure" section should have a key prop for the list item like below.
<li key={'create'}>Create Story</li>
instead of
<li>Create Story</li>
If there are simple fixes, PRs are very appreciated. It is difficult to track each individual comment in the thread.
@gaearon
that's a cool idea, would you be interested in exploring a PR to implement this?
I'd be willing to take this on if you haven't already, @lizzthabet?
I think the Redux docs are a great example of this functionality with docsearch. The global search bar opens a modal with a link at the bottom to "See all x results". This navigates to a dedicated search page accessible at /search?q=term
.
The old and beta React docs only offer the search modal displaying the top 5 results. Is it intentional that there isn't a standalone search page? If so, could go with a simpler implementation to detect a ?search=term
query string from any page (or maybe just the homepage) and open the search modal with the initial query. But I'd think the full search page with all results is more useful.
I think for now opening a modal from URL sounds fine.
There is some overlapping of sidebar on the main content.
that's a cool idea, would you be interested in exploring a PR to implement this?
I'd be willing to take this on if you haven't already, @lizzthabet?
go for it, @kylegundrum!
Hello everyone. I would like to know the process of how to raise an issue for the bug founded on the https://beta.reactjs.org/ (beta react docs). I think I have founded a potential issue on the beta docs and would like to know the procedure to raise the issue.
@zelfroster Feel free to raise a bug and send a PR in case you found the root cause. The same bug is not reproducible on my device 😞
@Ramjonchhen You can raise an issue in the issues tab (https://github.com/reactjs/reactjs.org/issues/new) and we can track it from there.
Thank You @harish-sethuraman for answering the query and helping out.
Is there any way to disable the political advertisements on the header of the react page? They are obnoxious and I'd like to remove political arguments from docs explaining programming syntax.
API Reference section seems very unstructured in the beta version, while it was simpler to understand in the current docs.
Also, the font size in previous docs was better!!
@Shivam-Dhyani Can you please be more concrete about what you mean by "unstructured" and "simpler to understand"? These are somewhat vague terms, and it would help if you listed some concrete comparisons.
Updated September 29, 2022! We're close to completing the remaining pages, and there is now a link to the Beta site from the main site.
Updated October 22, 2021! We have released React Docs Beta. See more details in the announcement and leave feedback on this issue!
Updated June 10, 2021! Full details in this comment.
Over the next months, we're planning to rebuild our website with fresh content!
Since Hooks have become increasingly popular in the React community, we have heard from confused learners as well as industry trainers asking why the docs are still so class component-centric. Additionally, while more and more educational materials for React are being created every day, there are still things not being taught because we have failed to explain them well.
We want to make reactjs.org the best place to grok React. We want to be there with you from the moment you make your first component, to well into your career as your React knowledge deepens and advances.
The plan
The new docs will teach React Hooks-first, with a focus on “how to think in React” and deeply grok React over building an app in React. (There are many amazing frameworks with full stacks, tutorials, and learning paths we will point people to for a holistic kickstart.) We’ll have a section on React’s core concepts as well as an expanded and concise API reference.
Anyone can learn React
We want React to be accessible to learners of all backgrounds, so we’re going to expand our coverage to include:
Because so much of this is going to be new content with a different structure, most of the existing documentation will be archived rather than edited. (Don’t worry: you’ll still be able to access our “class”-ic docs for legacy and migration work and we’ll set up redirects where appropriate!)
To ensure consistent voice and narrative, Dan and Rachel will start by writing the core of the new content, but later on we will be accepting community contributions as usual when everything is in place.
We’re also surveying the community to learn how you use reactjs.org so we can see what’s working and what isn’t. If you have five minutes to spare, we’d love if you could take our 2020 community survey!
Translations
With the help of our wonderful translators, more people than ever before have access to React. We want to thank our translation community so much for their hard work and commitment to React's v1 docs. Their efforts have allowed people all over the world to learn, teach, and build with React, and we will need their help more than ever when v2 launches. We’ll reach out to start coordinating as soon as we have content ready to translate.
What to expect
We’re aiming to launch the new docs in early 2021. We've got the initial structure in place and are working on a new site we're wrangling design resources for. We've sharing early stage outlines with individual teachers and learners to gather feedback, and as we have more and more content prepared, we will start publishing previews to gather even more feedback. This is an iterative process, and we want to get this right! In the meantime, if you’re looking for the React docs with Hooks, check out this community-maintained version of the docs where all examples use Hooks.
Help us help you! Take the survey!
Want to help? We’re running a survey to help better understand and measure the React community, your needs, and where we can do better. If you have a moment, you’ll be helping us a lot! Please take our survey—and share it with your team, classmates, other people who use and learn React.