amirho/react.dev
1
0
Fork 0
mirror of https://github.com/reactjs/react.dev.git synced 2026-02-24 12:43:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix typos (#4938)

Browse Source
This commit is contained in:
Strek
2022-08-28 11:45:58 +05:30
committed by GitHub
parent c5a1acd165
commit ea9e9ab281
2 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
beta/src/pages/learn/removing-effect-dependencies.md
View File

@@ -354,7 +354,7 @@ There's always a better solution than ignoring the linter! To fix this code, you
</DeepDive>
## Removing unnecesary dependencies {/*removing-unnecesary-dependencies*/}
## Removing unnecessary dependencies {/*removing-unnecessary-dependencies*/}
Every time you adjust the Effect's dependencies to reflect the code, look at the dependency list. Does it make sense for the Effect to re-run when any of these dependencies change? Sometimes, the answer is "no":
@@ -388,7 +388,7 @@ function Form() {
}
```
Later, you want to style the notification message according to the current theme, so you read the current theme. Since `theme` is declared in the component body, it is a reactive value, and you must declare it as a depedency:
Later, you want to style the notification message according to the current theme, so you read the current theme. Since `theme` is declared in the component body, it is a reactive value, and you must declare it as a dependency:
```js {3,9,11}
function Form() {

4
beta/src/pages/learn/separating-events-from-effects.md
View File

@@ -210,7 +210,7 @@ Now let's return to these lines:
// ...
```
From the user's prespective, **a change to the `roomId` *does* mean that they want to connect to a different room.** In other words, the logic for connecting to the room should be reactive. You *want* these lines of code to "keep up" with the <CodeStep step={2}>reactive value</CodeStep>, and to run again if that value is different. That's why you put this logic inside an Effect:
From the user's perspective, **a change to the `roomId` *does* mean that they want to connect to a different room.** In other words, the logic for connecting to the room should be reactive. You *want* these lines of code to "keep up" with the <CodeStep step={2}>reactive value</CodeStep>, and to run again if that value is different. That's why you put this logic inside an Effect:
```js {2-3}
useEffect(() => {
@@ -805,7 +805,7 @@ body {
</Sandpack>
The problem with the this code is in suppressing the dependency linter. If you remove the suppression, you'll see that this Effect should depend on the `handleMove` function. This makes sense: `handleMove` is declared inside the component body, which makes it a reactive value. Every reactive value must be specified as a depedency, or it can potentially get stale over time!
The problem with the this code is in suppressing the dependency linter. If you remove the suppression, you'll see that this Effect should depend on the `handleMove` function. This makes sense: `handleMove` is declared inside the component body, which makes it a reactive value. Every reactive value must be specified as a dependency, or it can potentially get stale over time!
The author of the original code has "lied" to React by saying that the Effect does not depend (`[]`) on any reactive values. This is why React did not re-synchronize the Effect after `canMove` has changed (and `handleMove` with it). Because React did not re-synchronize the Effect, the `handleMove` attached as a listener is the `handleMove` function created during the initial render. During the initial render, `canMove` was `true`, which is why `handleMove` from the initial render will forever see that value.