diff --git a/src/content/blog/2022/03/29/react-v18.md b/src/content/blog/2022/03/29/react-v18.md index 0e2a9e5ea..5c4a3a30c 100644 --- a/src/content/blog/2022/03/29/react-v18.md +++ b/src/content/blog/2022/03/29/react-v18.md @@ -195,7 +195,7 @@ React 18의 Suspense는 transition API와 함께 사용할 때 가장 잘 작동 ### 새로운 Strict 모드 동작들 {/*new-strict-mode-behaviors*/} -앞으로는 리액트가 state를 유지하면서 UI의 섹션을 추가하고 제거할 수 있는 기능을 추가하고 싶습니다. 예를 들어 사용자가 화면에서 벗어나 뒤로 탭 할 때 React는 이전 화면을 즉시 표시할 수 있어야 합니다. 이를 위해 리액트는 이전과 동일한 컴포넌트 state를 사용하여 트리를 마운트 해제하고 다시 마운트합니다. +앞으로는 React가 state를 유지하면서 UI의 섹션을 추가하고 제거할 수 있는 기능을 추가하고 싶습니다. 예를 들어 사용자가 화면에서 벗어나 뒤로 탭 할 때 React는 이전 화면을 즉시 표시할 수 있어야 합니다. 이를 위해 React는 이전과 동일한 컴포넌트 state를 사용하여 트리를 마운트 해제하고 다시 마운트합니다. 이 기능을 사용하면 React 앱의 성능이 즉시 향상되지만, 컴포넌트가 effect가 여러 번 마운트 및 소멸하는 것에 대해 탄력적이어야 합니다. 대부분의 effect는 변경 없이 작동하지만 일부 effect는 한 번만 마운트되거나 소멸한다고 가정합니다. diff --git a/src/content/community/acknowledgements.md b/src/content/community/acknowledgements.md index 34a7a0e9f..b18b666cb 100644 --- a/src/content/community/acknowledgements.md +++ b/src/content/community/acknowledgements.md @@ -59,7 +59,7 @@ React는 원래 [Jordan Walke](https://github.com/jordwalke)에 의해 만들어 이 목록이 전체 목록은 아닙니다. -수년간 지도와 지원을 주신 [Tom Occhino](https://github.com/tomocchino)와 [Adam Wolff](https://github.com/wolffiex)에게 특별한 감사를 드립니다. [리액트를 다른 언어로 번역한](https://translations.reactjs.org/) 모든 자원봉사자에게도 감사합니다. +수년간 지도와 지원을 주신 [Tom Occhino](https://github.com/tomocchino)와 [Adam Wolff](https://github.com/wolffiex)에게 특별한 감사를 드립니다. [React를 다른 언어로 번역한](https://translations.reactjs.org/) 모든 자원봉사자에게도 감사합니다. ## 특별한 감사 인사 {/*additional-thanks*/} diff --git a/src/content/learn/conditional-rendering.md b/src/content/learn/conditional-rendering.md index 44c5f688d..aaacc4d57 100644 --- a/src/content/learn/conditional-rendering.md +++ b/src/content/learn/conditional-rendering.md @@ -4,7 +4,7 @@ title: 조건부 렌더링 -컴포넌트는 조건에 따라 다른 항목을 표시해야 하는 경우가 많습니다. 리액트는 `if` 문, `&&` 및 `? :` 연산자와 같은 자바스크립트 문법을 사용하여 조건부로 JSX를 렌더링할 수 있습니다. +컴포넌트는 조건에 따라 다른 항목을 표시해야 하는 경우가 많습니다. React는 `if` 문, `&&` 및 `? :` 연산자와 같은 자바스크립트 문법을 사용하여 조건부로 JSX를 렌더링할 수 있습니다. @@ -317,7 +317,7 @@ export default function PackingList() { **`&&`의 왼쪽에 숫자를 두지 마세요.** -조건을 테스트하기 위해 JavaScript는 자동으로 왼쪽을 부울로 변환합니다. 그러나 왼쪽이 `0`이면 전체 식이 (`0`)을 얻게 되고, 리액트는 아무것도 아닌 `0`을 렌더링할 것입니다. +조건을 테스트하기 위해 JavaScript는 자동으로 왼쪽을 부울로 변환합니다. 그러나 왼쪽이 `0`이면 전체 식이 (`0`)을 얻게 되고, React는 아무것도 아닌 `0`을 렌더링할 것입니다. 예를 들어, 흔하게 하는 실수로 `messageCount &&

New messages

`와 같은 코드를 작성하는 것입니다. 메시지 카운트가 `0`일 때 아무것도 렌더링하지 않는다고 쉽게 추측할 수 있지만, 실제로는 `0` 자체를 렌더링합니다! diff --git a/src/content/learn/describing-the-ui.md b/src/content/learn/describing-the-ui.md index 03b2ba520..330000877 100644 --- a/src/content/learn/describing-the-ui.md +++ b/src/content/learn/describing-the-ui.md @@ -546,7 +546,7 @@ React 렌더 트리 예시 -의존성 트리는 종종 빌드 도구에 의해 클라이언트가 다운로드하고 렌더링하는 데 필요한 모든 관련 자바스크립트 코드를 bundle 하는 데에 사용됩니다. 큰 bundle 크기는 리액트 앱의 사용자 경험을 저하합니다. 모듈 의존성 트리를 이해하는 것은 이러한 문제를 디버깅하는 데 도움이 됩니다. +의존성 트리는 종종 빌드 도구에 의해 클라이언트가 다운로드하고 렌더링하는 데 필요한 모든 관련 자바스크립트 코드를 bundle 하는 데에 사용됩니다. 큰 bundle 크기는 React 앱의 사용자 경험을 저하합니다. 모듈 의존성 트리를 이해하는 것은 이러한 문제를 디버깅하는 데 도움이 됩니다. diff --git a/src/content/learn/keeping-components-pure.md b/src/content/learn/keeping-components-pure.md index 428d35804..216ed577f 100644 --- a/src/content/learn/keeping-components-pure.md +++ b/src/content/learn/keeping-components-pure.md @@ -193,15 +193,15 @@ export default function TeaGathering() { 함수형 프로그래밍은 순수성에 크게 의존하지만, 언젠가는, 어딘가에서, _무언가가_ 바뀌어야 합니다. 그것이 프로그래밍의 요점입니다! 이러한 변화들-화면을 업데이트하고, 애니메이션을 시작하고, 데이터를 변경하는 것을 **사이드 이펙트**라고 합니다. 렌더링중에 발생하는 것이 아니라 _"사이드에서,"_ 발생하는 현상입니다. -리액트에선, **사이드 이펙트는 보통 [이벤트 핸들러](/learn/responding-to-events)에 포함됩니다.** 이벤트 핸들러는 리액트가 일부 작업을 수행할 때 반응하는 기능입니다-예를 들면 버튼을 클릭할 때처럼 말이죠. 이벤트 핸들러가 컴포넌트 _내부에_ 정의되었다 하더라도 렌더링 _중에는_ 실행되지 않습니다! **그래서 이벤트 핸들러는 순수할 필요가 없습니다.** +React에선, **사이드 이펙트는 보통 [이벤트 핸들러](/learn/responding-to-events)에 포함됩니다.** 이벤트 핸들러는 React가 일부 작업을 수행할 때 반응하는 기능입니다-예를 들면 버튼을 클릭할 때처럼 말이죠. 이벤트 핸들러가 컴포넌트 _내부에_ 정의되었다 하더라도 렌더링 _중에는_ 실행되지 않습니다! **그래서 이벤트 핸들러는 순수할 필요가 없습니다.** -다른 옵션을 모두 사용했지만 사이드 이펙트에 적합한 이벤트 핸들러를 찾을 수 없는 경우에도, 컴포넌트에서 [`useEffect`](/reference/react/useEffect) 호출을 사용하여 반환된 JSX에 해당 이벤트 핸들러를 연결할 수 있습니다. 이것은 리액트에게 사이드 이펙트가 허용될 때 렌더링 후 나중에 실행하도록 지시합니다. **그러나 이 접근 방식이 마지막 수단이 되어야 합니다.** +다른 옵션을 모두 사용했지만 사이드 이펙트에 적합한 이벤트 핸들러를 찾을 수 없는 경우에도, 컴포넌트에서 [`useEffect`](/reference/react/useEffect) 호출을 사용하여 반환된 JSX에 해당 이벤트 핸들러를 연결할 수 있습니다. 이것은 React에게 사이드 이펙트가 허용될 때 렌더링 후 나중에 실행하도록 지시합니다. **그러나 이 접근 방식이 마지막 수단이 되어야 합니다.** 가능하면 렌더링만으로 로직을 표현해 보세요. 이것이 당신을 얼마나 더 나아가게 할 수 있는지 알면 놀라게 될겁니다! -#### 리액트는 왜 순수함을 신경쓸까요? {/*why-does-react-care-about-purity*/} +#### React는 왜 순수함을 신경쓸까요? {/*why-does-react-care-about-purity*/} 순수 함수를 작성하려면 약간의 습관과 훈련이 필요합니다. 그러나 이건 또한 놀라운 기회를 열어줍니다. @@ -209,7 +209,7 @@ export default function TeaGathering() { * 입력이 변경되지 않은 컴포넌트 [렌더링을 건너뛰어](/reference/react/memo) 성능을 향상시킬 수 있습니다. 순수 함수는 항상 동일한 결과를 반환하므로 캐시하기에 안전합니다. * 깊은 컴포넌트 트리를 렌더링하는 도중에 일부 데이터가 변경되는 경우 React는 오래된 렌더링을 완료하는 데 시간을 낭비하지 않고 렌더링을 다시 시작할 수 있습니다. 순수함은 언제든지 연산을 중단하는 것을 안전하게 합니다. -우리가 구축하고 있는 모든 새로운 리액트 기능은 순수성을 활용합니다. 데이터 가져오기에서 애니메이션, 성능에 이르기까지 컴포넌트를 순수하게 유지하면 리액트 패러다임의 힘이 발휘됩니다. +우리가 구축하고 있는 모든 새로운 React 기능은 순수성을 활용합니다. 데이터 가져오기에서 애니메이션, 성능에 이르기까지 컴포넌트를 순수하게 유지하면 React 패러다임의 힘이 발휘됩니다. @@ -571,7 +571,7 @@ h1 { margin: 5px; font-size: 18px; } -리액트는 컴포넌트 함수가 특정 순서로 실행된다는 것을 보장하지 않기 때문에 변수를 설정해서 컴포넌트 함수간에 통신할 수 없습니다. 모든 커뮤니케이션은 프로퍼티를 통해 이루어져야 합니다. +React는 컴포넌트 함수가 특정 순서로 실행된다는 것을 보장하지 않기 때문에 변수를 설정해서 컴포넌트 함수간에 통신할 수 없습니다. 모든 커뮤니케이션은 프로퍼티를 통해 이루어져야 합니다. diff --git a/src/content/learn/reacting-to-input-with-state.md b/src/content/learn/reacting-to-input-with-state.md index b2c818373..644aefaee 100644 --- a/src/content/learn/reacting-to-input-with-state.md +++ b/src/content/learn/reacting-to-input-with-state.md @@ -4,7 +4,7 @@ title: State를 사용해 Input 다루기 -리액트는 선언적인 방식으로 UI를 조작합니다. 개별적인 UI를 직접 조작하는 것 대신에 컴포넌트 내부에 여러 state를 묘사하고 사용자의 입력에 따라 state를 변경합니다. 이는 디자이너가 UI를 바라보는 방식과 비슷합니다. +React는 선언적인 방식으로 UI를 조작합니다. 개별적인 UI를 직접 조작하는 것 대신에 컴포넌트 내부에 여러 state를 묘사하고 사용자의 입력에 따라 state를 변경합니다. 이는 디자이너가 UI를 바라보는 방식과 비슷합니다. @@ -31,7 +31,7 @@ UI 상호작용을 디자인할 때 사용자가 액션을 하면 어떻게 UI 옆에 탄 운전기사는 당신이 어디를 가고싶어 하는지 모릅니다. 그저 명령에 따를 뿐이죠. (잘못된 지시를 하면 잘못된 곳에 도착하고 말겁니다.) 우리가 이것을 *명령형*이라 부르는 이유입니다. 왜냐하면 컴퓨터에게 스피너부터 버튼까지 각각의 요소에 UI를 *어떻게* 업데이트 해야할지 "명령"을 내려야하기 때문이죠. -아래의 명령형 UI 프로그래밍 예시는 리액트 *없이* 만들어진 폼입니다. 브라우저에 내장된 [DOM](https://developer.mozilla.org/ko/docs/Web/API/Document_Object_Model)을 사용했습니다. +아래의 명령형 UI 프로그래밍 예시는 React *없이* 만들어진 폼입니다. 브라우저에 내장된 [DOM](https://developer.mozilla.org/ko/docs/Web/API/Document_Object_Model)을 사용했습니다. @@ -133,15 +133,15 @@ body { font-family: sans-serif; margin: 20px; padding: 0; } 위의 예시에서는 문제가 없겠지만 위와 같이 UI를 조작하면 더 복잡한 시스템에서는 난이도가 기하급수적으로 올라갑니다. 여러 다른 폼으로 가득 찬 페이지를 업데이트해야 한다고 생각해보세요. 새로운 UI 요소나 새로운 상호작용을 추가하려면 버그의 발생을 막기 위해 기존의 모든 코드를 주의 깊게 살펴봐야만 할 겁니다. (예를 들면 어떤 것을 보여주거나 숨기거나 하는 것을 잊을지도 모릅니다). -리액트는 이러한 문제점을 해결하기 위해 만들어졌습니다. +React는 이러한 문제점을 해결하기 위해 만들어졌습니다. -리액트에서는 직접 UI를 조작할 필요가 없습니다. 컴포넌트를 직접 활성화하거나 비활성화하거나 보여주거나 숨길 필요가 없습니다. 대신에 **무엇을 보여주고 싶은지 선언**하기만 하면 됩니다. 그러면 리액트는 어떻게 UI를 업데이트 해야 할지 이해할 것입니다. 택시를 탄다고 생각해 봅시다. 운전기사에게 어디서 꺾어야 할지 알려주는게 아니라 가고 싶은 곳을 말한다고 생각해 보세요. 당신을 거기까지 데려다주는 것은 운전기사의 일이고 운전기사는 어쩌면 당신이 몰랐던 지름길을 알고 있을지도 모릅니다! +React에서는 직접 UI를 조작할 필요가 없습니다. 컴포넌트를 직접 활성화하거나 비활성화하거나 보여주거나 숨길 필요가 없습니다. 대신에 **무엇을 보여주고 싶은지 선언**하기만 하면 됩니다. 그러면 React는 어떻게 UI를 업데이트 해야 할지 이해할 것입니다. 택시를 탄다고 생각해 봅시다. 운전기사에게 어디서 꺾어야 할지 알려주는게 아니라 가고 싶은 곳을 말한다고 생각해 보세요. 당신을 거기까지 데려다주는 것은 운전기사의 일이고 운전기사는 어쩌면 당신이 몰랐던 지름길을 알고 있을지도 모릅니다! ## UI를 선언적인 방식으로 생각하기 {/*thinking-about-ui-declaratively*/} -지금까지 폼을 선언적인 방식으로 구현하는 방법을 살펴보았습니다. 리액트처럼 생각하는 방법을 더 잘 이해하기 위해 UI를 리액트에서 다시 구현하는 과정을 아래에서 살펴봅시다. +지금까지 폼을 선언적인 방식으로 구현하는 방법을 살펴보았습니다. React처럼 생각하는 방법을 더 잘 이해하기 위해 UI를 React에서 다시 구현하는 과정을 아래에서 살펴봅시다. 1. 컴포넌트의 다양한 시각적 state를 **확인하세요.** 2. 무엇이 state 변화를 트리거하는지 **알아내세요.** @@ -151,7 +151,7 @@ body { font-family: sans-serif; margin: 20px; padding: 0; } ## 첫 번째: 컴포넌트의 다양한 시각적 state 확인하기 {/*step-1-identify-your-components-different-visual-states*/} -여러가지 "state"를 가지고 있는 ["상태 기계"](https://ko.wikipedia.org/wiki/유한_상태_기계)라는 것을 컴퓨터 과학에서 들어본 적이 있을 것입니다. 그리고 디자이너와 일한다면 다양한 "시각적 state"에 관한 모형을 본 적이 있을 것입니다. 리액트는 디자인과 컴퓨터 과학의 사이에 있기 때문에 두 아이디어 모두에서 영감을 받았습니다. +여러가지 "state"를 가지고 있는 ["상태 기계"](https://ko.wikipedia.org/wiki/유한_상태_기계)라는 것을 컴퓨터 과학에서 들어본 적이 있을 것입니다. 그리고 디자이너와 일한다면 다양한 "시각적 state"에 관한 모형을 본 적이 있을 것입니다. React는 디자인과 컴퓨터 과학의 사이에 있기 때문에 두 아이디어 모두에서 영감을 받았습니다. 먼저 사용자가 볼 수 있는 UI의 모든 "state"를 시각화해야 합니다. @@ -558,7 +558,7 @@ body { margin: 0; padding: 0; height: 250px; } * 이미지가 활성화되었을 때 CSS 클래스는 `background`와 `picture picture--active`가 됩니다. * 이미지가 비활성화되었을 때 CSS 클래스는 `background background--active`와 `picture`가 됩니다. -이미지의 활성화 state를 기억하기 위해서는 하나의 boolean state 변수로 충분합니다. 원래 하려고 했던 것은 CSS 클래스를 제거하거나 추가하는 것이었습니다. 하지만 리액트에서는 UI 요소를 *조작하는 것* 보다는 무엇을 보여주길 원하는지 *묘사하는 것*이 필요합니다. 그렇기 때문에 현재 state를 기반으로 두 CSS 클래스 모두를 계산해야 합니다. 그리고 이미지를 클릭했을 때 배경이 클릭되지 않도록 이벤트의 [전파를 막을](/learn/responding-to-events#stopping-propagation) 필요가 있습니다. +이미지의 활성화 state를 기억하기 위해서는 하나의 boolean state 변수로 충분합니다. 원래 하려고 했던 것은 CSS 클래스를 제거하거나 추가하는 것이었습니다. 하지만 React에서는 UI 요소를 *조작하는 것* 보다는 무엇을 보여주길 원하는지 *묘사하는 것*이 필요합니다. 그렇기 때문에 현재 state를 기반으로 두 CSS 클래스 모두를 계산해야 합니다. 그리고 이미지를 클릭했을 때 배경이 클릭되지 않도록 이벤트의 [전파를 막을](/learn/responding-to-events#stopping-propagation) 필요가 있습니다. 이미지를 클릭한 다음 이미지 외부도 클릭해 잘 작동하는지 확인해봅시다. @@ -799,7 +799,7 @@ label { display: block; margin-bottom: 20px; } 이 폼은 두 가지 모드를 가지고 있습니다. 하나는 편집 모드이고 이때 인풋들을 볼 수 있습니다. 또 다른 하나는 보기 모드이고 이때는 오직 결과만 볼 수 있습니다. 버튼의 라벨은 속한 모드에 따라 "Edit"과 "Save"로 변경됩니다. 또한 인풋들의 내용을 변경할 때 환영 메시지를 실시간으로 확인할 수 있습니다. -당신의 목적은 아래 샌드박스에서 리액트로 다시 구현하는 것입니다. 편의를 위해 마크업은 이미 JSX로 변환되어 있습니다. 하지만 원래 구현돼있던 것처럼 인풋들을 보여주고 숨기는 것은 직접 구현해야 합니다. +당신의 목적은 아래 샌드박스에서 React로 다시 구현하는 것입니다. 편의를 위해 마크업은 이미 JSX로 변환되어 있습니다. 하지만 원래 구현돼있던 것처럼 인풋들을 보여주고 숨기는 것은 직접 구현해야 합니다. 마찬가지로 아래에 있는 텍스트도 업데이트시켜야 합니다! @@ -900,9 +900,9 @@ label { display: block; margin-bottom: 20px; } -#### 명령형 코드를 리액트 없이 리팩토링하기 {/*refactor-the-imperative-solution-without-react*/} +#### 명령형 코드를 React 없이 리팩토링하기 {/*refactor-the-imperative-solution-without-react*/} -여기 리액트 없이 명령형으로 작성된 챌린지 이전의 코드가 있습니다. +여기 React 없이 명령형으로 작성된 챌린지 이전의 코드가 있습니다. @@ -999,7 +999,7 @@ label { display: block; margin-bottom: 20px; } -리액트가 없다고 상상해보세요. 이 로직을 조금 더 견고하고 리액트와 비슷하게 리팩토링할 수 있을까요? 리액트에서처럼 state를 명시적으로 표현하면 어떻게 보일까요? +React가 없다고 상상해보세요. 이 로직을 조금 더 견고하고 React와 비슷하게 리팩토링할 수 있을까요? React에서처럼 state를 명시적으로 표현하면 어떻게 보일까요? 어디서부터 시작해야할지 고민 중이라면 아래에 구조를 미리 만들어 두었습니다. 아래 구조에서 시작한다면 비어있는 `updateDOM` 함수 로직을 작성해보세요. (필요에 따라 원래 코드를 참조하시면 됩니다.) @@ -1225,7 +1225,7 @@ label { display: block; margin-bottom: 20px; } -작성된 `updateDOM` 함수는 리액트가 state를 설정할 때 어떤 작업을 수행하는지 보여줍니다. (하지만 리액트는 마지막으로 state가 설정된 이후 변경되지 않은 속성에 대해서는 DOM을 건드리지 않습니다.) +작성된 `updateDOM` 함수는 React가 state를 설정할 때 어떤 작업을 수행하는지 보여줍니다. (하지만 React는 마지막으로 state가 설정된 이후 변경되지 않은 속성에 대해서는 DOM을 건드리지 않습니다.) diff --git a/src/content/learn/render-and-commit.md b/src/content/learn/render-and-commit.md index 1362a4385..263585390 100644 --- a/src/content/learn/render-and-commit.md +++ b/src/content/learn/render-and-commit.md @@ -4,7 +4,7 @@ title: 렌더링 그리고 커밋 -컴포넌트를 화면에 표시하기 이전에 React에서 렌더링을 해야 합니다. 해당 과정의 단계를 이해하면 코드가 어떻게 실행되는지 이해할 수 있고 리액트 렌더링 동작에 관해 설명하는데 도움이 됩니다. +컴포넌트를 화면에 표시하기 이전에 React에서 렌더링을 해야 합니다. 해당 과정의 단계를 이해하면 코드가 어떻게 실행되는지 이해할 수 있고 React 렌더링 동작에 관해 설명하는데 도움이 됩니다. diff --git a/src/content/learn/sharing-state-between-components.md b/src/content/learn/sharing-state-between-components.md index effdb2954..35f77247e 100644 --- a/src/content/learn/sharing-state-between-components.md +++ b/src/content/learn/sharing-state-between-components.md @@ -302,7 +302,7 @@ h3, p { margin: 5px 0px; } ## 각 state의 단일 진리의 원천 {/*a-single-source-of-truth-for-each-state*/} -리액트 애플리케이션에서 많은 컴포넌트는 자체 state를 가집니다. 일부 상태는 입력처럼 리프 컴포넌트(트리 맨 아래에 있는 컴포넌트)와 가깝게 "생존"합니다. 다른 상태는 앱의 상단에 더 가깝게 "생존"할 수 있습니다. 예를 들면 클라이언트 측 라우팅 라이브러리도 현재 경로를 리액트 state로 저장하고 props로 전달하도록 구현되어 있습니다! +React 애플리케이션에서 많은 컴포넌트는 자체 state를 가집니다. 일부 상태는 입력처럼 리프 컴포넌트(트리 맨 아래에 있는 컴포넌트)와 가깝게 "생존"합니다. 다른 상태는 앱의 상단에 더 가깝게 "생존"할 수 있습니다. 예를 들면 클라이언트 측 라우팅 라이브러리도 현재 경로를 React state로 저장하고 props로 전달하도록 구현되어 있습니다! **각각의 고유한 state에 대해 어떤 컴포넌트가 "소유"할지 고를 수 있습니다.** 이 원칙은 또한 ["단일 진리의 원천"](https://en.wikipedia.org/wiki/Single_source_of_truth) 을 갖는 것으로 알려져 있습니다. 이는 모든 state가 한 곳에 존재한다는 의미가 아니라 그 정보를 가지고 있는 _특정_ 컴포넌트가 있다는 것을 말합니다. 컴포넌트 간의 공유된 state를 중복하는 대신 그들의 공통 부모로 *끌어올리고* 필요한 자식에게 *전달*하세요. diff --git a/src/content/learn/state-a-components-memory.md b/src/content/learn/state-a-components-memory.md index b857bb140..ea755af83 100644 --- a/src/content/learn/state-a-components-memory.md +++ b/src/content/learn/state-a-components-memory.md @@ -530,7 +530,7 @@ button { 대신 간결한 구문을 구현하기 위해 훅은 **동일한 컴포넌트의 모든 렌더링에서 안정적인 호출 순서에 의존합니다.** 위의 규칙("최상위 수준에서만 훅 호출")을 따르면, 훅은 항상 같은 순서로 호출되기 때문에 실제로 잘 작동합니다. 또한, [린터 플러그인](https://www.npmjs.com/package/eslint-plugin-react-hooks)은 대부분의 실수를 잡아줍니다. -내부적으로 React는 모든 컴포넌트에 대해 한 쌍의 state 배열을 가집니다. 또한 렌더링 전에 `0`으로 설정된 현재 인덱스 쌍을 유지합니다. `useState`를 호출할 때마다, React는 다음 state 쌍을 제공하고 인덱스를 증가시킵니다. 이 메커니즘에 대한 자세한 내용은 [리액트 훅: 마법이 아닌 배열](https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e)에서 확인할 수 있습니다. +내부적으로 React는 모든 컴포넌트에 대해 한 쌍의 state 배열을 가집니다. 또한 렌더링 전에 `0`으로 설정된 현재 인덱스 쌍을 유지합니다. `useState`를 호출할 때마다, React는 다음 state 쌍을 제공하고 인덱스를 증가시킵니다. 이 메커니즘에 대한 자세한 내용은 [React 훅: 마법이 아닌 배열](https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e)에서 확인할 수 있습니다. 이 예시에서는 **React를 사용하지 않지만,** 내부적으로 `useState`가 어떻게 작동하는지에 대한 아이디어를 제공합니다. diff --git a/src/content/learn/updating-objects-in-state.md b/src/content/learn/updating-objects-in-state.md index 6bfdacb46..3886b63ee 100644 --- a/src/content/learn/updating-objects-in-state.md +++ b/src/content/learn/updating-objects-in-state.md @@ -4,13 +4,13 @@ title: 객체 State 업데이트하기 -State는 객체를 포함한 모든 종류의 자바스크립트 값을 가질 수 있습니다. 하지만 리액트 state가 가진 객체를 직접 변경해서는 안 됩니다. 객체를 업데이트하고 싶을 때는 새로운 객체를 생성하여 (또는 기존 객체의 복사본을 만들어), state가 복사본을 사용하도록 하세요. +State는 객체를 포함한 모든 종류의 자바스크립트 값을 가질 수 있습니다. 하지만 React state가 가진 객체를 직접 변경해서는 안 됩니다. 객체를 업데이트하고 싶을 때는 새로운 객체를 생성하여 (또는 기존 객체의 복사본을 만들어), state가 복사본을 사용하도록 하세요. -- 리액트 state에서 객체를 올바르게 업데이트하는 방법 +- React state에서 객체를 올바르게 업데이트하는 방법 - 중첩된 객체를 변경하지 않고 업데이트하는 방법 - 불변성이란 무엇인지, 그리고 불변성을 지키는 방법 - Immer로 반복을 줄여 객체를 복사하는 방법 @@ -45,7 +45,7 @@ const [position, setPosition] = useState({ x: 0, y: 0 }); position.x = 5; ``` -하지만 리액트 state의 객체들이 기술적으로 변경 가능할지라도, 숫자, 불리언, 문자열과 같이 불변성을 가진 것처럼 다루어야 합니다. 객체를 변경하는 대신 교체해야 합니다. +하지만 React state의 객체들이 기술적으로 변경 가능할지라도, 숫자, 불리언, 문자열과 같이 불변성을 가진 것처럼 다루어야 합니다. 객체를 변경하는 대신 교체해야 합니다. ## State를 읽기 전용인 것처럼 다루세요 {/*treat-state-as-read-only*/} @@ -103,7 +103,7 @@ onPointerMove={e => { }} ``` -이 코드는 `position`에 할당된 객체를 [이전 렌더링](/learn/state-as-a-snapshot#rendering-takes-a-snapshot-in-time)에서 수정합니다. 그러나 리액트는 state 설정 함수가 없으면 객체가 변경되었는지 알 수 없습니다. 따라서 리액트는 아무것도 하지 않습니다. 이는 식사를 한 뒤에 주문을 바꾸려는 것과 같습니다. state를 변경하는 것이 어떤 경우에는 동작할 수 있지만, 권장하지 않습니다. 렌더링 시에 접근하려는 state 값은 읽기 전용처럼 다루어야 합니다. +이 코드는 `position`에 할당된 객체를 [이전 렌더링](/learn/state-as-a-snapshot#rendering-takes-a-snapshot-in-time)에서 수정합니다. 그러나 React는 state 설정 함수가 없으면 객체가 변경되었는지 알 수 없습니다. 따라서 React는 아무것도 하지 않습니다. 이는 식사를 한 뒤에 주문을 바꾸려는 것과 같습니다. state를 변경하는 것이 어떤 경우에는 동작할 수 있지만, 권장하지 않습니다. 렌더링 시에 접근하려는 state 값은 읽기 전용처럼 다루어야 합니다. 이러한 경우에 [리렌더링을 발생시키려면](/learn/state-as-a-snapshot#setting-state-triggers-renders), ***새* 객체를 생성하여 state 설정 함수로 전달하세요** @@ -466,7 +466,7 @@ const [person, setPerson] = useState({ person.artwork.city = 'New Delhi'; ``` -하지만 리액트에서는 state를 변경할 수 없는 것으로 다루어야 합니다! `city`를 바꾸기 위해서는 먼저 (이전 객체의 데이터로 생성된) 새로운 `artwork` 객체를 생성한 뒤, 그것을 가리키는 새로운 `person` 객체를 만들어야 합니다. +하지만 React에서는 state를 변경할 수 없는 것으로 다루어야 합니다! `city`를 바꾸기 위해서는 먼저 (이전 객체의 데이터로 생성된) 새로운 `artwork` 객체를 생성한 뒤, 그것을 가리키는 새로운 `person` 객체를 만들어야 합니다. ```js const nextArtwork = { ...person.artwork, city: 'New Delhi' }; @@ -793,23 +793,23 @@ img { width: 200px; height: 200px; } -#### 왜 리액트에서 state 변경은 권장되지 않나요? {/*why-is-mutating-state-not-recommended-in-react*/} +#### 왜 React에서 state 변경은 권장되지 않나요? {/*why-is-mutating-state-not-recommended-in-react*/} 몇 가지 이유가 있습니다. * **디버깅:** 만약 `console.log`를 사용하고 state를 변경하지 않는다면, 과거 로그들은 가장 최근 state 변경 사항들에 의해 지워지지 않습니다. 따라서 state가 렌더링 사이에 어떻게 바뀌었는지 명확하게 알 수 있습니다. -* **최적화:** 보편적인 리액트 [최적화 전략](/reference/react/memo)은 이전 props 또는 state가 다음 것과 동일할 때 일을 건너뛰는 것에 의존합니다. state를 절대 변경하지 않는다면 변경사항이 있었는지 확인하는 작업이 매우 빨라집니다. `prevObj === obj`를 통해 내부적으로 아무것도 바뀌지 않았음을 확인할 수 있습니다. -* **새로운 기능:** 우리가 만드는 새로운 리액트 기능들은 [스냅샷처럼 다루어지는 것](/learn/state-as-a-snapshot)에 의존합니다. 만약 state의 과거 버전을 변경한다면, 새로운 기능을 사용하지 못할 수 있습니다. +* **최적화:** 보편적인 React [최적화 전략](/reference/react/memo)은 이전 props 또는 state가 다음 것과 동일할 때 일을 건너뛰는 것에 의존합니다. state를 절대 변경하지 않는다면 변경사항이 있었는지 확인하는 작업이 매우 빨라집니다. `prevObj === obj`를 통해 내부적으로 아무것도 바뀌지 않았음을 확인할 수 있습니다. +* **새로운 기능:** 우리가 만드는 새로운 React 기능들은 [스냅샷처럼 다루어지는 것](/learn/state-as-a-snapshot)에 의존합니다. 만약 state의 과거 버전을 변경한다면, 새로운 기능을 사용하지 못할 수 있습니다. * **요구사항 변화:** 취소/복원 구현, 변화 내역 조회, 사용자가 이전 값으로 폼을 재설정하기 등의 기능은 아무것도 변경되지 않았을 때 더 쉽습니다. 왜냐하면 당신은 메모리에 state의 이전 복사본을 저장하여 적절한 상황에 다시 사용할 수 있기 때문입니다. 변경하는 것으로 시작하게 되면 이러한 기능들은 나중에 추가하기 어려울 수 있습니다. -* **더 간단한 구현:** 리액트는 변경에 의존하지 않기 때문에 객체로 뭔가 특별한 것을 할 필요가 없습니다. 프로퍼티를 가져오거나, 항상 프록시로 감싸거나, 다른 많은 "반응형" 솔루션이 그러듯 초기화 시에 다른 작업을 하지 않아도 됩니다. 이것은 리액트가 state에 --얼마나 크던-- 추가적인 성능 또는 정확성 함정 없이 아무 객체나 넣을 수 있게 해주는 이유이기도 합니다. +* **더 간단한 구현:** React는 변경에 의존하지 않기 때문에 객체로 뭔가 특별한 것을 할 필요가 없습니다. 프로퍼티를 가져오거나, 항상 프록시로 감싸거나, 다른 많은 "반응형" 솔루션이 그러듯 초기화 시에 다른 작업을 하지 않아도 됩니다. 이것은 React가 state에 --얼마나 크던-- 추가적인 성능 또는 정확성 함정 없이 아무 객체나 넣을 수 있게 해주는 이유이기도 합니다. -실제로, 리액트에서 state를 변경하는 것으로 "도망"쳐버릴수도 있지만, 우리는 그렇게 하지 않기를 강하게 권장함으로써 당신이 이러한 접근법을 바탕으로 개발된 새로운 리액트 기능들을 사용할 수 있기를 바랍니다. 미래의 기여자들과 어쩌면 미래의 당신 스스로까지 고마워할 것입니다! +실제로, React에서 state를 변경하는 것으로 "도망"쳐버릴수도 있지만, 우리는 그렇게 하지 않기를 강하게 권장함으로써 당신이 이러한 접근법을 바탕으로 개발된 새로운 React 기능들을 사용할 수 있기를 바랍니다. 미래의 기여자들과 어쩌면 미래의 당신 스스로까지 고마워할 것입니다! -* 리액트의 모든 state를 불변한 것으로 대하세요. +* React의 모든 state를 불변한 것으로 대하세요. * state에 객체를 저장할 때, 객체를 변경하는 것은 렌더링을 발생시키지 않으며 이전 렌더 "스냅샷"의 state를 바꿀 것입니다. * 객체를 변경하는 대신 *새로운* 객체를 생성하여 state를 설정함으로써 리렌더링을 일으키세요. * 객체의 복사본을 만들기 위해 `{...obj, something: 'newValue'}` 객체 전개 구문을 사용할 수 있습니다. @@ -965,7 +965,7 @@ input { margin-left: 5px; margin-bottom: 5px; } -`handlePlusClick`의 문제는 `player` 객체를 변경했다는 점입니다. 결과적으로 리액트는 리렌더링을 할 필요성을 몰랐으며, 스코어를 업데이트하지 않았습니다. 이것이 fist name을 변경했을 때 state가 업데이트되었으며, 리렌더링을 야기하여 스코어 _또한_ 업데이트된 이유입니다. +`handlePlusClick`의 문제는 `player` 객체를 변경했다는 점입니다. 결과적으로 React는 리렌더링을 할 필요성을 몰랐으며, 스코어를 업데이트하지 않았습니다. 이것이 fist name을 변경했을 때 state가 업데이트되었으며, 리렌더링을 야기하여 스코어 _또한_ 업데이트된 이유입니다. `handleLastNameChange`의 문제는 그것이 이미 존재하는 `...player` 필드를 새 객체로 복사하지 않았다는 점입니다. 이것이 last name을 수정한 후에 스코어가 없어진 이유입니다. diff --git a/src/content/reference/react-dom/components/common.md b/src/content/reference/react-dom/components/common.md index 630fafb54..590b7735f 100644 --- a/src/content/reference/react-dom/components/common.md +++ b/src/content/reference/react-dom/components/common.md @@ -761,7 +761,7 @@ CSS 전환 이벤트에 대한 이벤트 핸들러 유형입니다. ### CSS 스타일 적용하기 {/*applying-css-styles*/} -리액트는 [`className`](https://developer.mozilla.org/ko/docs/Web/API/Element/className)을 사용하여 CSS 클래스를 지정합니다. 이것은 HTML의 클래스 속성처럼 작동합니다. +React는 [`className`](https://developer.mozilla.org/ko/docs/Web/API/Element/className)을 사용하여 CSS 클래스를 지정합니다. 이것은 HTML의 클래스 속성처럼 작동합니다. ```js diff --git a/src/content/reference/react/PureComponent.md b/src/content/reference/react/PureComponent.md index a00e70b15..39b1c6806 100644 --- a/src/content/reference/react/PureComponent.md +++ b/src/content/reference/react/PureComponent.md @@ -52,7 +52,7 @@ class Greeting extends PureComponent { ### 클래스 컴포넌트에서 불필요한 재 렌더링 건너뛰기 {/*skipping-unnecessary-re-renders-for-class-components*/} -리액트는 일반적으로 부모가 다시 렌더링 될 때마다 자식 컴포넌트도 다시 렌더링 합니다. 하지만 `PureComponent`를 extend 하여 새 props 및 state가 이전 props 및 state와 같다면 부모가 다시 렌더링 되더라도 자식 컴포넌트는 다시 렌더링 되지 않도록 [Class component](/reference/react/Component)를 최적화할 수 있습니다. +React는 일반적으로 부모가 다시 렌더링 될 때마다 자식 컴포넌트도 다시 렌더링 합니다. 하지만 `PureComponent`를 extend 하여 새 props 및 state가 이전 props 및 state와 같다면 부모가 다시 렌더링 되더라도 자식 컴포넌트는 다시 렌더링 되지 않도록 [Class component](/reference/react/Component)를 최적화할 수 있습니다. ```js {1} class Greeting extends PureComponent { @@ -62,7 +62,7 @@ class Greeting extends PureComponent { } ``` -리액트 컴포넌트에는 항상 [순수한 렌더링 로직](/learn/keeping-components-pure)이 있어야 합니다. 즉, props, state 및 context가 변경되지 않은 경우 같은 출력을 반환해야 합니다. `PureComponent`를 사용하면 컴포넌트가 이 요구 사항을 준수한다고 리액트에게 알리므로 props 및 state가 변경되지 않는 한 React는 다시 렌더링하지 않습니다. 그러나 사용 중인 context가 변경된다면 컴포넌트는 다시 렌더링 됩니다. +React 컴포넌트에는 항상 [순수한 렌더링 로직](/learn/keeping-components-pure)이 있어야 합니다. 즉, props, state 및 context가 변경되지 않은 경우 같은 출력을 반환해야 합니다. `PureComponent`를 사용하면 컴포넌트가 이 요구 사항을 준수한다고 React에게 알리므로 props 및 state가 변경되지 않는 한 React는 다시 렌더링하지 않습니다. 그러나 사용 중인 context가 변경된다면 컴포넌트는 다시 렌더링 됩니다. 이 예시에서 `Greeting` 컴포넌트는 `name`이 변경될 때마다 다시 렌더링 되지만 (props 중 하나이기 때문에) `address`가 변경될 때에는 다시 렌더링 되지 않습니다 (`Greeting`에 prop으로 전달되지 않기 때문에). diff --git a/src/content/reference/react/experimental_taintUniqueValue.md b/src/content/reference/react/experimental_taintUniqueValue.md index 43cc9eefd..4aebd4d28 100644 --- a/src/content/reference/react/experimental_taintUniqueValue.md +++ b/src/content/reference/react/experimental_taintUniqueValue.md @@ -131,7 +131,7 @@ const uppercasePassword = password.toUpperCase() // `uppercasePassword`는 오 오염되지 않은 새로운 값이 만들어지는 다른 유사한 방법에는 오염된 값을 다른 문자열과 연결하거나, base64로 변환하거나, 잘라내는 것이 있습니다. -오염은 비밀 값을 클라이언트에 전달하는 것과 같이 단순한 실수만 방지합니다. lifetime 객체 없이 리액트 외부의 글로벌 스토어를 사용하는 것과 같이 `taintUniqueValue`를 호출하는 실수는 오염된 값을 오염되지 않은 값으로 만들 수 있습니다. 오염은 보호 레이어이며 안전한 앱에는 여러 개의 보호 레이어와 잘 설계된 API, 격리 패턴이 있습니다. +오염은 비밀 값을 클라이언트에 전달하는 것과 같이 단순한 실수만 방지합니다. lifetime 객체 없이 React 외부의 글로벌 스토어를 사용하는 것과 같이 `taintUniqueValue`를 호출하는 실수는 오염된 값을 오염되지 않은 값으로 만들 수 있습니다. 오염은 보호 레이어이며 안전한 앱에는 여러 개의 보호 레이어와 잘 설계된 API, 격리 패턴이 있습니다. diff --git a/src/content/reference/react/experimental_useEffectEvent.md b/src/content/reference/react/experimental_useEffectEvent.md index 91eb1ffc4..bd19a35b8 100644 --- a/src/content/reference/react/experimental_useEffectEvent.md +++ b/src/content/reference/react/experimental_useEffectEvent.md @@ -4,22 +4,22 @@ title: experimental_useEffectEvent -**이 API는 실험 단계이므로 아직 안정된 버전의 리액트에는 사용할 수 없습니다.** +**이 API는 실험 단계이므로 아직 안정된 버전의 React에는 사용할 수 없습니다.** -리액트 패키지를 최신 실험 버전으로 업그레이드하여 API를 사용해 볼 수 있습니다. +React 패키지를 최신 실험 버전으로 업그레이드하여 API를 사용해 볼 수 있습니다. - `react@experimental` - `react-dom@experimental` - `eslint-plugin-react-hooks@experimental` -실험 버전의 리액트에는 버그가 있을 수 있습니다. 프로덕션 환경에서는 이 버전을 사용하지 마세요. +실험 버전의 React에는 버그가 있을 수 있습니다. 프로덕션 환경에서는 이 버전을 사용하지 마세요. -`useEffectEvent`는 [Effect Event.](/learn/separating-events-from-effects#declaring-an-effect-event) 에 반응하지 않는 로직을 추출하는 리액트 훅입니다. +`useEffectEvent`는 [Effect Event.](/learn/separating-events-from-effects#declaring-an-effect-event) 에 반응하지 않는 로직을 추출하는 React 훅입니다. ```js const onSomething = useEffectEvent(callback) diff --git a/src/content/reference/react/hooks.md b/src/content/reference/react/hooks.md index e0063dc47..aa6b231b3 100644 --- a/src/content/reference/react/hooks.md +++ b/src/content/reference/react/hooks.md @@ -4,7 +4,7 @@ title: "내장된 React Hook" -*Hook*을 사용하면 컴포넌트에서 다양한 React 기능을 사용할 수 있습니다. 내장된 Hook을 이용하거나 이를 결합하여 자신만의 Hook을 만들 수 있습니다. 이 페이지에는 리액트에 내장된 모든 Hook이 나열되어 있습니다. +*Hook*을 사용하면 컴포넌트에서 다양한 React 기능을 사용할 수 있습니다. 내장된 Hook을 이용하거나 이를 결합하여 자신만의 Hook을 만들 수 있습니다. 이 페이지에는 React에 내장된 모든 Hook이 나열되어 있습니다. diff --git a/src/content/reference/react/useEffect.md b/src/content/reference/react/useEffect.md index 224fc0f44..d1888ead7 100644 --- a/src/content/reference/react/useEffect.md +++ b/src/content/reference/react/useEffect.md @@ -46,7 +46,7 @@ function ChatRoom({ roomId }) { + `setup(설정)`: Effect의 로직이 포함된 함수입니다. 설정 함수는 선택적으로 *clean up(정리)* 함수를 반환할 수 있습니다. React는 컴포넌트가 DOM에 추가된 이후에 설정 함수를 실행합니다. 의존성의 변화에 따라 컴포넌트가 리렌더링이 되었을 경우, (설정 함수에 정리 함수를 추가했었다면) React는 이전 렌더링에 사용된 값으로 정리 함수를 실행한 후 새로운 값으로 설정 함수를 실행합니다. 컴포넌트가 DOM에서 제거된 경우에도 정리 함수를 실행합니다. -+ `dependencies` **선택사항** : `설정` 함수의 코드 내부에서 참조되는 모든 반응형 값들이 포함된 배열로 구성됩니다. 반응형 값에는 props와 state, 모든 변수 및 컴포넌트 body에 직접적으로 선언된 함수들이 포함됩니다. 린터가 [리액트 환경에 맞게 설정되어 있을 경우](/learn/editor-setup#linting), 린터는 모든 반응형 값들이 의존성에 제대로 명시되어 있는지 검증할 것입니다. 의존성 배열은 항상 일정한 수의 항목을 가지고 있어야 하며 `[dep1, dep2, dep3]`과 같이 작성되어야 합니다. React는 각각의 의존성들을 [`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is) 비교법을 통해 이전 값과 비교합니다. 의존성을 생략할 경우, Effect는 컴포넌트가 리렌더링될 때마다 실행됩니다. [인수에 의존성 배열을 추가했을 때, 빈 배열을 추가했을 때, 의존성을 추가하지 않았을 때의 차이를 확인해 보세요.](#examples-dependencies) ++ `dependencies` **선택사항** : `설정` 함수의 코드 내부에서 참조되는 모든 반응형 값들이 포함된 배열로 구성됩니다. 반응형 값에는 props와 state, 모든 변수 및 컴포넌트 body에 직접적으로 선언된 함수들이 포함됩니다. 린터가 [React 환경에 맞게 설정되어 있을 경우](/learn/editor-setup#linting), 린터는 모든 반응형 값들이 의존성에 제대로 명시되어 있는지 검증할 것입니다. 의존성 배열은 항상 일정한 수의 항목을 가지고 있어야 하며 `[dep1, dep2, dep3]`과 같이 작성되어야 합니다. React는 각각의 의존성들을 [`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is) 비교법을 통해 이전 값과 비교합니다. 의존성을 생략할 경우, Effect는 컴포넌트가 리렌더링될 때마다 실행됩니다. [인수에 의존성 배열을 추가했을 때, 빈 배열을 추가했을 때, 의존성을 추가하지 않았을 때의 차이를 확인해 보세요.](#examples-dependencies) #### 반환값 {/*returns*/} @@ -114,7 +114,7 @@ function ChatRoom({ roomId }) { 위의 `ChatRoom` 컴포넌트가 화면에 추가되면 초기 `serverUrl`과 `roomId`를 이용해 채팅방과 연결될 것입니다. 리렌더링에 의해 `serverUrl` 또는 `roomId`가 변경된다면 (예를 들어 사용자가 드롭다운 메뉴를 이용해 다른 채팅방을 선택할 경우) *Effect는 이전 채팅방과의 연결을 해제하고 다음 채팅방과 연결합니다.* `ChatRoom` 컴포넌트가 화면에서 제거된다면 Effect는 마지막 채팅방과 이뤄진 연결을 해제할 것입니다. -리액트는 **[버그를 발견하기 위해](/learn/synchronizing-with-effects#step-3-add-cleanup-if-needed) 개발모드에서 설정이 실행되기 전에 설정과 정리를 한 번 더 실행시킵니다.** 이는 스트레스 테스트의 하나로써 Effect의 로직이 정확하게 수행되고 있는지를 검증합니다. 만약 가시적인 이슈가 보인다면 정리 함수의 로직에 놓친 부분이 있는 것입니다. 정리 함수는 설정 함수의 어떠한 동작이라도 중지하거나 실행 취소를 할 수 있어야 하며, 사용자는 *설정* 함수가 한 번 호출될 때와 *설정* → *정리* → *설정* 순서로 호출될 때의 차이를 느낄 수 없어야 합니다. +React는 **[버그를 발견하기 위해](/learn/synchronizing-with-effects#step-3-add-cleanup-if-needed) 개발모드에서 설정이 실행되기 전에 설정과 정리를 한 번 더 실행시킵니다.** 이는 스트레스 테스트의 하나로써 Effect의 로직이 정확하게 수행되고 있는지를 검증합니다. 만약 가시적인 이슈가 보인다면 정리 함수의 로직에 놓친 부분이 있는 것입니다. 정리 함수는 설정 함수의 어떠한 동작이라도 중지하거나 실행 취소를 할 수 있어야 하며, 사용자는 *설정* 함수가 한 번 호출될 때와 *설정* → *정리* → *설정* 순서로 호출될 때의 차이를 느낄 수 없어야 합니다. **[각각의 Effect를 독립적인 프로세스로 작성](/learn/lifecycle-of-reactive-effects#each-effect-represents-a-separate-synchronization-process)하고 [정확한 설정/정리 사이클을 고려하세요.](/learn/lifecycle-of-reactive-effects#thinking-from-the-effects-perspective)** 컴포넌트의 마운트, 업데이트, 마운트 해제 여부는 중요하지 않아야 합니다. 정리 로직이 설정 로직과 정확하게 "미러링"될 때, Effect는 설정과 정리를 필요한 만큼 견고하게 처리합니다. @@ -127,7 +127,7 @@ An Effect lets you [keep your component synchronized](/learn/synchronizing-with- * [`window.addEventListener()`](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener)을 이용한 이벤트 구독 또는 [`window.removeEventListener()`](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/removeEventListener). * `animation.start()`와 같은 서드 파티 애니메이션 라이브러리 API 또는 `animation.reset()`. -**만약 외부 시스템과 리액트를 연결할 필요가 없다면 [Effect를 사용할 필요가 없을 수 있습니다.](/learn/you-might-not-need-an-effect)** +**만약 외부 시스템과 React를 연결할 필요가 없다면 [Effect를 사용할 필요가 없을 수 있습니다.](/learn/you-might-not-need-an-effect)** @@ -786,7 +786,7 @@ export function useIntersectionObserver(ref) { --- -### 리액트로 작성되지 않은 위젯 제어하기 {/*controlling-a-non-react-widget*/} +### React로 작성되지 않은 위젯 제어하기 {/*controlling-a-non-react-widget*/} 가끔은 컴포넌트의 prop 또는 state를 외부 시스템과 동기화해야할 때가 있습니다. @@ -1046,9 +1046,9 @@ Effect 내부에서 `fetch` 호출을 작성하는 것은 클라이언트 사이 - **Effect 내부에서 직접 데이터를 페칭하는 것은 일반적으로 데이터를 미리 로드하거나 캐싱하지 않는다는 것을 의미합니다.** 예를 들어 컴포넌트가 마운트 해제되고 다시 마운트되었을 때 데이터를 다시 가져와야 합니다. - **사용하기 매우 불편한 방법입니다.** [경쟁 조건](https://maxrozen.com/race-conditions-fetching-data-react-with-useeffect)과 같은 버그를 발생시키지 않도록 fetch 호출을 작성할 때 상당한 양의 보일러 플레이트 코드가 필요합니다. -이러한 단점은 리액트만 해당되는 것이 아닙니다. 다른 라이브러리를 사용하여 데이터를 페칭할 때도 해당됩니다. 라우팅과 마찬가지로 데이터 페칭은 세부적인 사항이 많으므로 다음과 같은 접근 방식을 권장합니다. +이러한 단점은 React만 해당되는 것이 아닙니다. 다른 라이브러리를 사용하여 데이터를 페칭할 때도 해당됩니다. 라우팅과 마찬가지로 데이터 페칭은 세부적인 사항이 많으므로 다음과 같은 접근 방식을 권장합니다. -- **[프레임워크](/learn/start-a-new-react-project#production-grade-react-frameworks)를 사용하는 경우, 해당 프레임워크에 내장된 데이터 페칭 메커니즘을 활용하세요.** 현대 리액트 프레임워크는 매우 효율적이며 위에서 언급한 문제점이 없는 통합된 데이터 페칭 기능을 가지고 있습니다. +- **[프레임워크](/learn/start-a-new-react-project#production-grade-react-frameworks)를 사용하는 경우, 해당 프레임워크에 내장된 데이터 페칭 메커니즘을 활용하세요.** 현대 React 프레임워크는 매우 효율적이며 위에서 언급한 문제점이 없는 통합된 데이터 페칭 기능을 가지고 있습니다. - **그렇지 않은 경우, 클라이언트 측 캐시를 사용하거나 직접 개발을 고려해 보세요.** 인기 있는 오픈소스 솔루션으로는 [React Query](https://tanstack.com/query/latest/), [useSWR](https://swr.vercel.app/), 그리고 [React Router 6.4+.](https://beta.reactrouter.com/en/main/start/overview)가 있습니다. 물론 직접 솔루션을 개발할수도 있으며 이 경우에는 이펙트를 내부적으로 사용하면서도 데이터 사전로드 또는 데이터 요구사항을 라우트로 호이스팅하는 방법을 통해 중복 요청 방지, 응답 캐싱 및 네트워크 폭포 효과 방지를 구현할 수 있습니다. 만약 이러한 접근 방식이 적합하지 않다면 Effect 내부에서 데이터를 페칭하는 것을 계속 진행할 수 있습니다. @@ -1076,7 +1076,7 @@ function ChatRoom({ roomId }) { // 이것은 반응형 값입니다 `serverUrl` 또는 `roomId`가 변경될 때마다 Effect는 새로운 값을 이용해 채팅을 다시 연결할 것입니다. -**[반응형 값](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values)** 에는 props와 컴포넌트 내부에 선언된 모든 변수나 함수들이 포함됩니다. `roomId`와 `serverUrl`은 반응형 값이므로 이들을 의존성에서 제거하면 안 됩니다. 이들을 누락했을 때 [린터가 리액트 환경에 맞게 설정되어 있었다면](/learn/editor-setup#linting) 린터는 이것을 수정해야 하는 실수로 표시합니다. +**[반응형 값](/learn/lifecycle-of-reactive-effects#effects-react-to-reactive-values)** 에는 props와 컴포넌트 내부에 선언된 모든 변수나 함수들이 포함됩니다. `roomId`와 `serverUrl`은 반응형 값이므로 이들을 의존성에서 제거하면 안 됩니다. 이들을 누락했을 때 [린터가 React 환경에 맞게 설정되어 있었다면](/learn/editor-setup#linting) 린터는 이것을 수정해야 하는 실수로 표시합니다. ```js {8} function ChatRoom({ roomId }) { @@ -1691,7 +1691,7 @@ button { margin-left: 10px; } -이 섹션은 안정 버전의 리액트에 **반영되지 않은 실험적 API**에 대해 설명합니다. +이 섹션은 안정 버전의 React에 **반영되지 않은 실험적 API**에 대해 설명합니다. diff --git a/src/sidebarHome.json b/src/sidebarHome.json index 99fbe065c..5fb212184 100644 --- a/src/sidebarHome.json +++ b/src/sidebarHome.json @@ -1,5 +1,5 @@ { - "title": "리액트 문서", + "title": "React 문서", "path": "/", "routes": [ { @@ -79,7 +79,7 @@ "sectionHeader": "GET INVOLVED" }, { - "title": "리액트 커뮤니티", + "title": "React 커뮤니티", "path": "/community" }, { @@ -87,7 +87,7 @@ "sectionHeader": "STAY INFORMED" }, { - "title": "리액트 블로그", + "title": "React 블로그", "path": "/blog" } ]