From 26d4e2066352ffd9edc3014fa32134de7d0ac962 Mon Sep 17 00:00:00 2001 From: lee-eojin Date: Sat, 6 Jun 2026 19:56:30 +0900 Subject: [PATCH] =?UTF-8?q?docs:=20fix=20typo=20(=EB=A9=94=EC=84=B8?= =?UTF-8?q?=EC=A7=80=20=E2=86=92=20=EB=A9=94=EC=8B=9C=EC=A7=80)=20in=20ref?= =?UTF-8?q?erence?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/content/reference/react/Component.md | 2 +- src/content/reference/react/useEffect.md | 2 +- src/content/reference/react/useReducer.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/content/reference/react/Component.md b/src/content/reference/react/Component.md index 2aeba522f..3481e474f 100644 --- a/src/content/reference/react/Component.md +++ b/src/content/reference/react/Component.md @@ -222,7 +222,7 @@ constructor는 부수 효과 또는 구독을 포함하면 안 됩니다. #### 주의 사항 {/*componentdidcatch-caveats*/} -* 과거에는 UI를 업데이트하고 대체 에러 메세지를 표시하기 위해 `setState`를 `componentDidCatch` 안에서 호출하는 것이 일반적이었습니다. 이는 [`static getDerivedStateFromError`](#static-getderivedstatefromerror)를 정의하기 위해 더 이상 사용되지 않습니다. +* 과거에는 UI를 업데이트하고 대체 에러 메시지를 표시하기 위해 `setState`를 `componentDidCatch` 안에서 호출하는 것이 일반적이었습니다. 이는 [`static getDerivedStateFromError`](#static-getderivedstatefromerror)를 정의하기 위해 더 이상 사용되지 않습니다. * React의 프로덕션과 개발 빌드는 `componentDidCatch`가 에러를 처리하는 방식이 약간 다릅니다. 개발에서는, 에러는 `window`까지 버블링될 것이며, 이는 `window.onerror` 또는 `window.addEventListener('error', callback)`가 `componentDidCatch`에 의해 탐지된 에러를 가로챈다는 것을 의미합니다. 대신 프로덕션에서, 에러는 버블링되지 않을 것이며, 이는 어떤 상위의 에러 핸들러가 `componentDidCatch`에 의해 명시적으로 탐지되지 않은 에러만을 수신하는 것을 의미합니다. diff --git a/src/content/reference/react/useEffect.md b/src/content/reference/react/useEffect.md index aee2f1e70..d24dddbd4 100644 --- a/src/content/reference/react/useEffect.md +++ b/src/content/reference/react/useEffect.md @@ -1154,7 +1154,7 @@ useEffect(() => { }, [a, b]); // a나 b가 다르면 다시 실행됨 ``` -아래 예시에서는 `serverUrl`와 `roomId`은 [반응형 값](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values)이므로 둘 다 의존성으로 지정해야 합니다. 결과적으로 드롭다운에서 다른 방을 선택하거나 서버 URL 입력을 편집하면 채팅이 다시 연결됩니다. 그러나 `message`는 Effect에서 사용되지 않으므로(의존성이 아니므로), 메세지를 편집해도 대화가 다시 연결되지 않습니다. +아래 예시에서는 `serverUrl`와 `roomId`은 [반응형 값](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values)이므로 둘 다 의존성으로 지정해야 합니다. 결과적으로 드롭다운에서 다른 방을 선택하거나 서버 URL 입력을 편집하면 채팅이 다시 연결됩니다. 그러나 `message`는 Effect에서 사용되지 않으므로(의존성이 아니므로), 메시지를 편집해도 대화가 다시 연결되지 않습니다. diff --git a/src/content/reference/react/useReducer.md b/src/content/reference/react/useReducer.md index e99177082..83ba7b5e9 100644 --- a/src/content/reference/react/useReducer.md +++ b/src/content/reference/react/useReducer.md @@ -1064,7 +1064,7 @@ function reducer(state, action) { ### "Too many re-renders" 오류가 발생합니다. {/*im-getting-an-error-too-many-re-renders*/} -`Too many re-renders. React limits the number of renders to prevent an infinite loop.`라는 에러 메세지를 받을 수 있습니다. 일반적으로는 렌더링 과정에서 dispatch가 실행될 때 이러한 일이 일어납니다. 렌더링은 dispatch를 야기하고, dispatch는 렌더링을 야기하므로 렌더링 무한 루프가 일어납니다. 이러한 상황은 이벤트 핸들러를 잘못 호출할 때 종종 발생합니다. +`Too many re-renders. React limits the number of renders to prevent an infinite loop.`라는 에러 메시지를 받을 수 있습니다. 일반적으로는 렌더링 과정에서 dispatch가 실행될 때 이러한 일이 일어납니다. 렌더링은 dispatch를 야기하고, dispatch는 렌더링을 야기하므로 렌더링 무한 루프가 일어납니다. 이러한 상황은 이벤트 핸들러를 잘못 호출할 때 종종 발생합니다. ```js {1-2} // 🚩 Wrong: calls the handler during render