diff --git a/content/docs/hooks-faq.md b/content/docs/hooks-faq.md index 2de3ef6b9..6f2dec373 100644 --- a/content/docs/hooks-faq.md +++ b/content/docs/hooks-faq.md @@ -1,13 +1,13 @@ --- id: hooks-faq -title: Hooks FAQ +title: Hook 자주 묻는 질문 permalink: docs/hooks-faq.html prev: hooks-reference.html --- -*Hooks* are a new addition in React 16.8. They let you use state and other React features without writing a class. +*Hook*은 React 16.8에 새로 추가되었습니다. Class를 작성하지 않고 state 및 기타 React 기능을 사용할 수 있습니다. -This page answers some of the frequently asked questions about [Hooks](/docs/hooks-overview.html). +이 페이지는 [Hook](/docs/hooks-overview.html) 자주 묻는 질문에 대한 답변입니다. -* **[Adoption Strategy](#adoption-strategy)** - * [Which versions of React include Hooks?](#which-versions-of-react-include-hooks) - * [Do I need to rewrite all my class components?](#do-i-need-to-rewrite-all-my-class-components) - * [What can I do with Hooks that I couldn't with classes?](#what-can-i-do-with-hooks-that-i-couldnt-with-classes) - * [How much of my React knowledge stays relevant?](#how-much-of-my-react-knowledge-stays-relevant) - * [Should I use Hooks, classes, or a mix of both?](#should-i-use-hooks-classes-or-a-mix-of-both) - * [Do Hooks cover all use cases for classes?](#do-hooks-cover-all-use-cases-for-classes) - * [Do Hooks replace render props and higher-order components?](#do-hooks-replace-render-props-and-higher-order-components) - * [What do Hooks mean for popular APIs like Redux connect() and React Router?](#what-do-hooks-mean-for-popular-apis-like-redux-connect-and-react-router) - * [Do Hooks work with static typing?](#do-hooks-work-with-static-typing) - * [How to test components that use Hooks?](#how-to-test-components-that-use-hooks) - * [What exactly do the lint rules enforce?](#what-exactly-do-the-lint-rules-enforce) -* **[From Classes to Hooks](#from-classes-to-hooks)** - * [How do lifecycle methods correspond to Hooks?](#how-do-lifecycle-methods-correspond-to-hooks) - * [How can I do data fetching with Hooks?](#how-can-i-do-data-fetching-with-hooks) - * [Is there something like instance variables?](#is-there-something-like-instance-variables) - * [Should I use one or many state variables?](#should-i-use-one-or-many-state-variables) - * [Can I run an effect only on updates?](#can-i-run-an-effect-only-on-updates) - * [How to get the previous props or state?](#how-to-get-the-previous-props-or-state) - * [Why am I seeing stale props or state inside my function?](#why-am-i-seeing-stale-props-or-state-inside-my-function) - * [How do I implement getDerivedStateFromProps?](#how-do-i-implement-getderivedstatefromprops) - * [Is there something like forceUpdate?](#is-there-something-like-forceupdate) - * [Can I make a ref to a function component?](#can-i-make-a-ref-to-a-function-component) - * [How can I measure a DOM node?](#how-can-i-measure-a-dom-node) - * [What does const [thing, setThing] = useState() mean?](#what-does-const-thing-setthing--usestate-mean) -* **[Performance Optimizations](#performance-optimizations)** - * [Can I skip an effect on updates?](#can-i-skip-an-effect-on-updates) - * [Is it safe to omit functions from the list of dependencies?](#is-it-safe-to-omit-functions-from-the-list-of-dependencies) - * [What can I do if my effect dependencies change too often?](#what-can-i-do-if-my-effect-dependencies-change-too-often) - * [How do I implement shouldComponentUpdate?](#how-do-i-implement-shouldcomponentupdate) - * [How to memoize calculations?](#how-to-memoize-calculations) - * [How to create expensive objects lazily?](#how-to-create-expensive-objects-lazily) - * [Are Hooks slow because of creating functions in render?](#are-hooks-slow-because-of-creating-functions-in-render) - * [How to avoid passing callbacks down?](#how-to-avoid-passing-callbacks-down) - * [How to read an often-changing value from useCallback?](#how-to-read-an-often-changing-value-from-usecallback) -* **[Under the Hood](#under-the-hood)** - * [How does React associate Hook calls with components?](#how-does-react-associate-hook-calls-with-components) - * [What is the prior art for Hooks?](#what-is-the-prior-art-for-hooks) - -## Adoption Strategy {#adoption-strategy} - -### Which versions of React include Hooks? {#which-versions-of-react-include-hooks} - -Starting with 16.8.0, React includes a stable implementation of React Hooks for: +* **[적용 전략](#adoption-strategy)** + * [어떤 버전의 React가 Hook을 포함합니까?](#which-versions-of-react-include-hooks) + * [모든 class 컴포넌트를 다시 작성해야 합니까?](#do-i-need-to-rewrite-all-my-class-components) + * [Class로 하지 못하는 것 중에 Hook으로 가능한 것이 무엇인가요?](#what-can-i-do-with-hooks-that-i-couldnt-with-classes) + * [React 지식은 얼마나 관련이 있습니까?](#how-much-of-my-react-knowledge-stays-relevant) + * [Hook이나 class 또는 두 가지를 모두 사용해야 합니까?](#should-i-use-hooks-classes-or-a-mix-of-both) + * [Hook이 class의 모든 사용 사례를 커버합니까?](#do-hooks-cover-all-use-cases-for-classes) + * [Hook이 render props 및 고차 컴포넌트를 대체합니까?](#do-hooks-replace-render-props-and-higher-order-components) + * [Redux connect()와 React Router와 같은 인기 있는 API에 대해 Hook은 무엇을 의미합니까?](#what-do-hooks-mean-for-popular-apis-like-redux-connect-and-react-router) + * [Hook은 정적 타이핑과 함께 작동합니까?](#do-hooks-work-with-static-typing) + * [Hook을 사용하는 컴포넌트 테스트하는 방법?](#how-to-test-components-that-use-hooks) + * [Lint 규칙은 정확히 무엇을 시행합니까?](#what-exactly-do-the-lint-rules-enforce) +* **[Class에서 Hook으로](#from-classes-to-hooks)** + * [생명주기 메서드가 Hook에 어떻게 대응합니까?](#how-do-lifecycle-methods-correspond-to-hooks) + * [Hook을 사용하여 데이터 가져오기를 수행하려면 어떻게 해야 합니까?](#how-can-i-do-data-fetching-with-hooks) + * [인스턴스 변수와 같은 것이 있습니까?](#is-there-something-like-instance-variables) + * [하나 또는 여러 state 변수를 사용해야 합니까?](#should-i-use-one-or-many-state-variables) + * [업데이트에만 effect를 실행할 수 있습니까?](#can-i-run-an-effect-only-on-updates) + * [이전 props 또는 state를 얻는 방법?](#how-to-get-the-previous-props-or-state) + * [함수 컴포넌트 안에 오래된 props나 state가 보이는 이유는 무엇입니까?](#why-am-i-seeing-stale-props-or-state-inside-my-function) + * [getDerivedStateFromProps를 어떻게 구현합니까?](#how-do-i-implement-getderivedstatefromprops) + * [forceUpdate와 같은 것이 있습니까?](#is-there-something-like-forceupdate) + * [함수 컴포넌트에 ref를 만들 수 있습니까?](#can-i-make-a-ref-to-a-function-component) + * [DOM 노드를 측정하려면 어떻게 해야 합니까?](#how-can-i-measure-a-dom-node) + * [const [thing, setThing] = useState()는 무엇을 의미합니까?](#what-does-const-thing-setthing--usestate-mean) +* **[성능 최적화](#performance-optimizations)** + * [업데이트 시 effect를 건너뛸 수 있습니까?](#can-i-skip-an-effect-on-updates) + * [종속성 목록에서 함수 컴포넌트를 생략하는 것이 안전합니까?](#is-it-safe-to-omit-functions-from-the-list-of-dependencies) + * [effect 종속성이 너무 자주 변경되면 어떻게 해야 합니까?](#what-can-i-do-if-my-effect-dependencies-change-too-often) + * [shouldComponentUpdate는 어떻게 구현합니까?](#how-do-i-implement-shouldcomponentupdate) + * [계산을 메모이제이션 하는 법?](#how-to-memoize-calculations) + * [고비용의 객체를 지연해서 생성하는 법?](#how-to-create-expensive-objects-lazily) + * [렌더링에서 함수 컴포넌트를 만들기 때문에 Hook이 느려집니까?](#are-hooks-slow-because-of-creating-functions-in-render) + * [콜백 전달을 피하는 법?](#how-to-avoid-passing-callbacks-down) + * [useCallback에서 자주 변경되는 값을 읽는 방법?](#how-to-read-an-often-changing-value-from-usecallback) +* **[Hook의 이면](#under-the-hood)** + * [React는 Hook 호출을 컴포넌트와 어떻게 연관시키는가?](#how-does-react-associate-hook-calls-with-components) + * [Hook에 대한 선행 기술은 무엇입니까?](#what-is-the-prior-art-for-hooks) + +## 적용 전략 {#adoption-strategy} + +### 어떤 버전의 React가 Hook을 포함합니까? {#which-versions-of-react-include-hooks} + +16.8.0부터 React에는 React Hook의 안정적인 구현이 포함됩니다. * React DOM * React Native * React DOM Server -* React Test Renderer -* React Shallow Renderer +* React 테스트 렌더러 +* React 얕은 렌더러 -Note that **to enable Hooks, all React packages need to be 16.8.0 or higher**. Hooks won't work if you forget to update, for example, React DOM. +**Hook을 사용하려면 모든 React 패키지가 16.8.0 이상이어야합니다**. 업데이트하는 것을 (예: React DOM) 잊어버리면 Hook이 작동하지 않습니다. -[React Native 0.59](https://reactnative.dev/blog/2019/03/12/releasing-react-native-059) and above support Hooks. +[React Native 0.59](https://reactnative.dev/blog/2019/03/12/releasing-react-native-059) 이상은 Hook을 지원합니다. -### Do I need to rewrite all my class components? {#do-i-need-to-rewrite-all-my-class-components} +### 모든 class 컴포넌트를 다시 작성해야 합니까? {#do-i-need-to-rewrite-all-my-class-components} -No. There are [no plans](/docs/hooks-intro.html#gradual-adoption-strategy) to remove classes from React -- we all need to keep shipping products and can't afford rewrites. We recommend trying Hooks in new code. +아닙니다. React에서 class를 삭제할 [계획은 없습니다](/docs/hooks-intro.html#gradual-adoption-strategy). 우리는 제품을 출시할 때마다 재작성을 할 여유가 없습니다. 새 코드에서 Hook을 사용하는 것이 좋습니다. -### What can I do with Hooks that I couldn't with classes? {#what-can-i-do-with-hooks-that-i-couldnt-with-classes} +### Class로 하지 못하는 것 중에 Hook으로 가능한 것이 무엇인가요? {#what-can-i-do-with-hooks-that-i-couldnt-with-classes} -Hooks offer a powerful and expressive new way to reuse functionality between components. ["Building Your Own Hooks"](/docs/hooks-custom.html) provides a glimpse of what's possible. [This article](https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889) by a React core team member dives deeper into the new capabilities unlocked by Hooks. +Hook은 컴포넌트 간에 기능을 재사용할 수 있는 강력하고 표현적인 새로운 방법을 제공합니다. ["자신만의 Hook 만들기"](/docs/hooks-custom.html)는 가능한 것을 엿볼 수 있게 해줍니다. React 핵심 팀 구성원이 작성한 [이 기사](https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889)에서는 Hook이 제공할 새로운 기능에 대해 자세히 설명합니다. -### How much of my React knowledge stays relevant? {#how-much-of-my-react-knowledge-stays-relevant} +### React 지식은 얼마나 관련이 있습니까? {#how-much-of-my-react-knowledge-stays-relevant} -Hooks are a more direct way to use the React features you already know -- such as state, lifecycle, context, and refs. They don't fundamentally change how React works, and your knowledge of components, props, and top-down data flow is just as relevant. +Hook은 state, 생명주기, context 및 ref와 같은 이미 알고 있는 React 기능을 사용하는 보다 직접적인 방법입니다. React가 어떻게 작동하는지 근본적으로 바꿀 수 없으며 컴포넌트, props 및 하향식 데이터 흐름에 대한 지식도 마찬가지로 중요합니다. -Hooks do have a learning curve of their own. If there's something missing in this documentation, [raise an issue](https://github.com/reactjs/reactjs.org/issues/new) and we'll try to help. +Hook에는 독자적인 학습 곡선이 있습니다. 이 문서에 누락된 것이 있으면 [문제를 제기](https://github.com/reactjs/reactjs.org/issues/new)하면 도움을 제공해 드리겠습니다. -### Should I use Hooks, classes, or a mix of both? {#should-i-use-hooks-classes-or-a-mix-of-both} +### Hook이나 class 또는 두 가지를 모두 사용해야 합니까? {#should-i-use-hooks-classes-or-a-mix-of-both} -When you're ready, we'd encourage you to start trying Hooks in new components you write. Make sure everyone on your team is on board with using them and familiar with this documentation. We don't recommend rewriting your existing classes to Hooks unless you planned to rewrite them anyway (e.g. to fix bugs). +준비가 되면 작성하는 새 컴포넌트에서 Hook을 시도해 보는 것이 좋습니다. 팀의 모든 구성원이 사용하고 이 문서에 익숙해 지도록 하십시오. 일부러 다시 작성하지 않는 이상 (예: 버그 수정) 기존 class를 Hook으로 고쳐 쓰는 것은 추천하지 않습니다. -You can't use Hooks *inside* a class component, but you can definitely mix classes and function components with Hooks in a single tree. Whether a component is a class or a function that uses Hooks is an implementation detail of that component. In the longer term, we expect Hooks to be the primary way people write React components. +Class 컴포넌트 *내부에서* Hook을 사용할 수는 없지만, class와 함수 컴포넌트를 단일 트리에서 Hook과 섞어서 사용할 수 있습니다. 컴포넌트가 class인지 Hook을 사용하는 함수 컴포넌트인지 여부는 해당 컴포넌트의 구현 세부 사항입니다. 장기적으로 우리는 Hook이 사람들이 React 컴포넌트를 작성하는 주요 방법이 될 것으로 기대합니다. -### Do Hooks cover all use cases for classes? {#do-hooks-cover-all-use-cases-for-classes} +### Hook이 class의 모든 사용 사례를 커버합니까? {#do-hooks-cover-all-use-cases-for-classes} -Our goal is for Hooks to cover all use cases for classes as soon as possible. There are no Hook equivalents to the uncommon `getSnapshotBeforeUpdate`, `getDerivedStateFromError` and `componentDidCatch` lifecycles yet, but we plan to add them soon. +우리의 목표는 Hook이 class의 모든 사용 사례를 가능한 한 빨리 커버하게 하는 것입니다. 드문 `getSnapshotBeforeUpdate`, `getDerivedStateFromError` 및 `componentDidCatch` 생명주기에 해당하는 Hook은 아직 없지만, 곧 추가할 계획입니다. -It is an early time for Hooks, and some third-party libraries might not be compatible with Hooks at the moment. +Hook의 초기 단계이며 일부 타사 라이브러리는 현재 Hook과 호환되지 않을 수 있습니다. -### Do Hooks replace render props and higher-order components? {#do-hooks-replace-render-props-and-higher-order-components} +### Hook이 render props 및 고차 컴포넌트를 대체합니까? {#do-hooks-replace-render-props-and-higher-order-components} -Often, render props and higher-order components render only a single child. We think Hooks are a simpler way to serve this use case. There is still a place for both patterns (for example, a virtual scroller component might have a `renderItem` prop, or a visual container component might have its own DOM structure). But in most cases, Hooks will be sufficient and can help reduce nesting in your tree. +종종 render props와 고차 컴포넌트는 하나의 자식만 렌더링합니다. 우리는 Hook이 이 사용 사례를 처리하는 더 간단한 방법이라고 생각합니다. 여전히 두 패턴 모두를 쓸 수 있습니다. (예를 들어, 가상 스크롤러 컴포넌트에는 `renderItem` props가 있거나 시각적 컨테이너 컴포넌트에는 자체 DOM 구조가 있을 수 있습니다) 그러나 대부분의 경우 Hook은 충분하며 코드 트리의 중첩을 줄이는 데 도움이 될 수 있습니다. -### What do Hooks mean for popular APIs like Redux `connect()` and React Router? {#what-do-hooks-mean-for-popular-apis-like-redux-connect-and-react-router} +### Redux connect()와 React Router와 같은 인기 있는 API에 대해 Hook은 무엇을 의미합니까? {#what-do-hooks-mean-for-popular-apis-like-redux-connect-and-react-router} -You can continue to use the exact same APIs as you always have; they'll continue to work. +여태껏 쓰던 API를 계속 사용할 수 있습니다; 앞으로도 계속 작동할 것 입니다. -React Redux since v7.1.0 [supports Hooks API](https://react-redux.js.org/api/hooks) and exposes hooks like `useDispatch` or `useSelector`. +v7.1.0부터 React Redux는 [Hook API를 지원하고](https://react-redux.js.org/api/hooks) `useDispatch` 또는 `useSelector`와 같은 Hook을 노출합니다. -React Router [supports hooks](https://reacttraining.com/react-router/web/api/Hooks) since v5.1. +v5.1 이후 React Router는 [Hook을 지원합니다](https://reacttraining.com/react-router/web/api/Hooks). -Other libraries might support hooks in the future too. +다른 라이브러리도 나중에 Hook을 지원할 수 있습니다. -### Do Hooks work with static typing? {#do-hooks-work-with-static-typing} +### Hook은 정적 타이핑과 함께 작동합니까? {#do-hooks-work-with-static-typing} -Hooks were designed with static typing in mind. Because they're functions, they are easier to type correctly than patterns like higher-order components. The latest Flow and TypeScript React definitions include support for React Hooks. +Hook은 정적 타이핑을 염두에 두고 설계되었습니다. 함수 컴포넌트이기 때문에 고차 컴포넌트와 같은 패턴보다 타입을 명시하기가 더 쉽습니다. 최신 Flow 및 TypeScript React 정의에는 React Hook 지원이 포함됩니다. -Importantly, custom Hooks give you the power to constrain React API if you'd like to type them more strictly in some way. React gives you the primitives, but you can combine them in different ways than what we provide out of the box. +중요한 점은, 커스텀 Hook은 더 엄격하게 타이핑하려는 경우 React API를 제한할 수 있는 기능을 제공합니다. React는 기초 요소를 제공하지만, 기본 제공 방식과 다른 방식으로 조합 할 수 있습니다. -### How to test components that use Hooks? {#how-to-test-components-that-use-hooks} +### Hook을 사용하는 컴포넌트 테스트하는 방법? {#how-to-test-components-that-use-hooks} -From React's point of view, a component using Hooks is just a regular component. If your testing solution doesn't rely on React internals, testing components with Hooks shouldn't be different from how you normally test components. +React의 관점에서 Hook을 사용하는 컴포넌트는 일반적인 컴포넌트입니다. 테스트 솔루션이 React internals에 종속하지 않는 경우 Hook이 있는 컴포넌트 테스트는 일반적으로 컴포넌트를 테스트하는 방법과 다르지 않아야 합니다. ->Note +>주의 > ->[Testing Recipes](/docs/testing-recipes.html) include many examples that you can copy and paste. +>[테스팅 방안](/docs/testing-recipes.html)에는 복사하여 붙여넣을 수 있는 많은 예제가 포함되어 있습니다. -For example, let's say we have this counter component: +예를 들어 여기 이 계수기 컴포넌트가 있다고 가정해 보겠습니다: ```js function Example() { @@ -146,7 +146,7 @@ function Example() { } ``` -We'll test it using React DOM. To make sure that the behavior matches what happens in the browser, we'll wrap the code rendering and updating it into [`ReactTestUtils.act()`](/docs/test-utils.html#act) calls: +React DOM을 사용하여 테스트하겠습니다. 브라우저에서 발생하는 상황과 동작이 일치하도록 코드 렌더링을 래핑하고 이를 [`ReactTestUtils.act()`](/docs/test-utils.html#act) 호출로 업데이트합니다. ```js{3,20-22,29-31} import React from 'react'; @@ -167,7 +167,7 @@ afterEach(() => { }); it('can render and update a counter', () => { - // Test first render and effect + // 첫 번째 렌더링 및 effect 테스트 act(() => { ReactDOM.render(, container); }); @@ -176,7 +176,7 @@ it('can render and update a counter', () => { expect(label.textContent).toBe('You clicked 0 times'); expect(document.title).toBe('You clicked 0 times'); - // Test second render and effect + // 두 번째 렌더링 및 effect 테스트 act(() => { button.dispatchEvent(new MouseEvent('click', {bubbles: true})); }); @@ -185,50 +185,50 @@ it('can render and update a counter', () => { }); ``` -The calls to `act()` will also flush the effects inside of them. +`act()` 호출은 그 안의 effect를 플러시합니다. -If you need to test a custom Hook, you can do so by creating a component in your test, and using your Hook from it. Then you can test the component you wrote. +커스텀 Hook을 테스트해야 하는 경우 테스트에서 컴포넌트를 작성하고 Hook을 사용하여 이를 수행 할 수 있습니다. 그런 다음 작성한 컴포넌트를 테스트 할 수 있습니다. -To reduce the boilerplate, we recommend using [React Testing Library](https://testing-library.com/react) which is designed to encourage writing tests that use your components as the end users do. +상용구를 줄이려면 [React Testing Library](https://testing-library.com/react)를 사용하는 것이 좋습니다. 이 라이브러리는 최종 사용자와 마찬가지로 컴포넌트를 사용하는 테스트 작성을 장려하도록 설계되었습니다. -For more information, check out [Testing Recipes](/docs/testing-recipes.html). +자세한 내용은 [테스팅 방안](/docs/testing-recipes.html)을 확인하십시오. -### What exactly do the [lint rules](https://www.npmjs.com/package/eslint-plugin-react-hooks) enforce? {#what-exactly-do-the-lint-rules-enforce} +### [Lint 규칙](https://www.npmjs.com/package/eslint-plugin-react-hooks)은 정확히 무엇을 시행합니까? {#what-exactly-do-the-lint-rules-enforce} -We provide an [ESLint plugin](https://www.npmjs.com/package/eslint-plugin-react-hooks) that enforces [rules of Hooks](/docs/hooks-rules.html) to avoid bugs. It assumes that any function starting with "`use`" and a capital letter right after it is a Hook. We recognize this heuristic isn't perfect and there may be some false positives, but without an ecosystem-wide convention there is just no way to make Hooks work well -- and longer names will discourage people from either adopting Hooks or following the convention. +버그를 피하고자 [Hook 규칙](/docs/hooks-rules.html)을 시행하는 [ESLint 플러그인](https://www.npmjs.com/package/eslint-plugin-react-hooks)을 제공합니다. "`use`"로 시작하는 모든 함수 컴포넌트와 Hook 바로 뒤에 대문자가 있다고 가정합니다. 우리는 이 휴리스틱이 완벽하지 않고 오 탐지가 있을 수 있다는 점을 인식하지만, 생태계 전반의 협약이 없으면 훅을 제대로 작동시킬 수 있는 방법이 없습니다 -- 더 긴 이름은 사람들이 Hook을 채택하거나 협약을 따르지 못하게 합니다. -In particular, the rule enforces that: +특히, 규칙은 이것들을 시행합니다. -* Calls to Hooks are either inside a `PascalCase` function (assumed to be a component) or another `useSomething` function (assumed to be a custom Hook). -* Hooks are called in the same order on every render. +* Hook에 대한 호출은 `PascalCase` 함수 컴포넌트 (컴포넌트로 가정) 또는 다른 `useSomething` 함수 컴포넌트 (커스텀 Hook으로 가정) 내에 있습니다. +* 모든 렌더링에서 Hook은 동일한 순서로 호출됩니다. -There are a few more heuristics, and they might change over time as we fine-tune the rule to balance finding bugs with avoiding false positives. +휴리스틱이 몇 가지 더 있으며, 추후 오 탐지를 피해 버그를 찾기 위해 규칙을 미세 조정함에 따라 변경될 수 있습니다. -## From Classes to Hooks {#from-classes-to-hooks} +## Class에서 Hook으로 {#from-classes-to-hooks} -### How do lifecycle methods correspond to Hooks? {#how-do-lifecycle-methods-correspond-to-hooks} +### 생명주기 메서드가 Hook에 어떻게 대응합니까? {#how-do-lifecycle-methods-correspond-to-hooks} -* `constructor`: Function components don't need a constructor. You can initialize the state in the [`useState`](/docs/hooks-reference.html#usestate) call. If computing the initial state is expensive, you can pass a function to `useState`. +* `constructor`: 함수 컴포넌트는 constructor가 필요하지 않습니다. [`useState`](/docs/hooks-reference.html#usestate) 호출에서 state를 초기화 할 수 있습니다. 초기 state를 계산하는 것이 비싸면 `useState`에 함수 컴포넌트를 전달할 수 있습니다. -* `getDerivedStateFromProps`: Schedule an update [while rendering](#how-do-i-implement-getderivedstatefromprops) instead. +* `getDerivedStateFromProps`: [대신 렌더링](#how-do-i-implement-getderivedstatefromprops)하는 동안 업데이트 예약. -* `shouldComponentUpdate`: See `React.memo` [below](#how-do-i-implement-shouldcomponentupdate). +* `shouldComponentUpdate`: [아래의](#how-do-i-implement-shouldcomponentupdate) `React.memo`를 참조하십시오. -* `render`: This is the function component body itself. +* `render`: 이것은 함수 컴포넌트 본체 자체입니다. -* `componentDidMount`, `componentDidUpdate`, `componentWillUnmount`: The [`useEffect` Hook](/docs/hooks-reference.html#useeffect) can express all combinations of these (including [less](#can-i-skip-an-effect-on-updates) [common](#can-i-run-an-effect-only-on-updates) cases). +* `componentDidMount`, `componentDidUpdate`, `componentWillUnmount`: [`useEffect` Hook](/docs/hooks-reference.html#useeffect)은 이들의 모든 조합을 표현할 수 있습니다. ([흔하거나](#can-i-run-an-effect-only-on-updates) [그렇지 않은](#can-i-skip-an-effect-on-updates) 경우 포함). -* `getSnapshotBeforeUpdate`, `componentDidCatch` and `getDerivedStateFromError`: There are no Hook equivalents for these methods yet, but they will be added soon. +* `getSnapshotBeforeUpdate`, `componentDidCatch` 그리고 `getDerivedStateFromError`: 이러한 메서드에 대한 Hook은 없지만, 곧 추가될 예정입니다. -### How can I do data fetching with Hooks? {#how-can-i-do-data-fetching-with-hooks} +### Hook을 사용하여 데이터 가져오기를 수행하려면 어떻게 해야 합니까? {#how-can-i-do-data-fetching-with-hooks} -Here is a [small demo](https://codesandbox.io/s/jvvkoo8pq3) to get you started. To learn more, check out [this article](https://www.robinwieruch.de/react-hooks-fetch-data/) about data fetching with Hooks. +다음은 시작하기 위한 [짧은 데모](https://codesandbox.io/s/jvvkoo8pq3)입니다. 자세한 내용은 Hook을 사용한 데이터 가져오기를 다룬 [이 기사](https://www.robinwieruch.de/react-hooks-fetch-data/)를 확인하십시오. -### Is there something like instance variables? {#is-there-something-like-instance-variables} +### 인스턴스 변수와 같은 것이 있습니까? {#is-there-something-like-instance-variables} -Yes! The [`useRef()`](/docs/hooks-reference.html#useref) Hook isn't just for DOM refs. The "ref" object is a generic container whose `current` property is mutable and can hold any value, similar to an instance property on a class. +네! [`useRef()`](/docs/hooks-reference.html#useref) Hook은 DOM ref만을 위한 것이 아닙니다. "ref" 객체는 `현재` 프로퍼티가 변경할 수 있고 어떤 값이든 보유할 수 있는 일반 컨테이너입니다. 이는 class의 인스턴스 프로퍼티와 유사합니다. -You can write to it from inside `useEffect`: +`useEffect` 내부에서 쓸 수 있습니다. ```js{2,8} function Timer() { @@ -248,7 +248,7 @@ function Timer() { } ``` -If we just wanted to set an interval, we wouldn't need the ref (`id` could be local to the effect), but it's useful if we want to clear the interval from an event handler: +인터벌을 설정하고 싶다면 ref가 필요하지 않지만 (`id`는 로컬 effect일 수 있습니다), 이벤트 처리에서 인터벌을 지우고 싶을 때 유용합니다. ```js{3} // ... @@ -258,11 +258,11 @@ If we just wanted to set an interval, we wouldn't need the ref (`id` could be lo // ... ``` -Conceptually, you can think of refs as similar to instance variables in a class. Unless you're doing [lazy initialization](#how-to-create-expensive-objects-lazily), avoid setting refs during rendering -- this can lead to surprising behavior. Instead, typically you want to modify refs in event handlers and effects. +개념적으로, class의 인스턴스 변수와 ref를 비슷하게 생각할 수 있습니다. [지연 초기화](#how-to-create-expensive-objects-lazily)를 수행하지 않는 한, 렌더링 중에 ref 설정을 피하십시오 -- 이것은 놀라운 상황을 초래할 수 있습니다. 대신, 일반적으로 이벤트 처리와 effect에서 ref를 수정하는 것이 좋습니다. -### Should I use one or many state variables? {#should-i-use-one-or-many-state-variables} +### 하나 또는 여러 state 변수를 사용해야 합니까? {#should-i-use-one-or-many-state-variables} -If you're coming from classes, you might be tempted to always call `useState()` once and put all state into a single object. You can do it if you'd like. Here is an example of a component that follows the mouse movement. We keep its position and size in the local state: +Class를 배운 후라면, `useState()`를 한 번만 호출하고 모든 state를 단일 객체에 넣고 싶을 수 있습니다. 원하시면 그렇게 할 수 있습니다. 다음은 마우스 움직임을 따르는 컴포넌트의 예입니다. 포인터의 위치와 크기를 로컬 state에 유지합니다. ```js function Box() { @@ -271,27 +271,27 @@ function Box() { } ``` -Now let's say we want to write some logic that changes `left` and `top` when the user moves their mouse. Note how we have to merge these fields into the previous state object manually: +이제 사용자가 마우스를 움직일 때 `left`과 `top`의 포지션을 변경하는 로직을 작성하고 싶다고 가정해 보겠습니다. 이러한 필드를 이전 state 개체에 수동으로 병합하는 방법에 유의하십시오. ```js{4,5} // ... useEffect(() => { function handleWindowMouseMove(e) { - // Spreading "...state" ensures we don't "lose" width and height + // "... state"를 spread 하여 너비와 높이가 "손실"되지 않습니다 setState(state => ({ ...state, left: e.pageX, top: e.pageY })); } - // Note: this implementation is a bit simplified + // 주의: 이 구현은 약간 단순화되었습니다 window.addEventListener('mousemove', handleWindowMouseMove); return () => window.removeEventListener('mousemove', handleWindowMouseMove); }, []); // ... ``` -This is because when we update a state variable, we *replace* its value. This is different from `this.setState` in a class, which *merges* the updated fields into the object. +이는 state 변수를 업데이트할 때 그 값을 *대체*하기 때문입니다. 이것은 업데이트된 필드를 객체에 *병합*하는 class의 `this.setState`와 다릅니다. -If you miss automatic merging, you could write a custom `useLegacyState` Hook that merges object state updates. However, **we recommend to split state into multiple state variables based on which values tend to change together.** +자동 병합을 놓친 경우 개체 state 업데이트를 병합하는 커스텀 `useLegacyState` Hook을 작성할 수 있습니다. 그러나, **함께변경 되는 값에 따라 state를 여러 state 변수로 분할하는 것을 추천합니다.** -For example, we could split our component state into `position` and `size` objects, and always replace the `position` with no need for merging: +예를 들어 컴포넌트 state를 `position` 및 `size` 객체로 분할하고 병합할 필요 없이 항상 `position`을 대체 할 수 있습니다. ```js{2,7} function Box() { @@ -305,7 +305,7 @@ function Box() { // ... ``` -Separating independent state variables also has another benefit. It makes it easy to later extract some related logic into a custom Hook, for example: +독립된 state 변수를 분리하면 또 다른 이점이 있습니다. 예를 들어 나중에 관련 로직을 커스텀 Hook으로 쉽게 추출 할 수 있습니다. ```js{2,7} function Box() { @@ -323,17 +323,17 @@ function useWindowPosition() { } ``` -Note how we were able to move the `useState` call for the `position` state variable and the related effect into a custom Hook without changing their code. If all state was in a single object, extracting it would be more difficult. +코드를 변경하지 않고 `position` state 변수에 대한 `useState` 호출과 관련 effect를 커스텀 Hook으로 옮길 수 있었던 방법에 유의하십시오. 모든 state가 단일 객체에 있으면 추출하기가 더 어려울 것입니다. -Both putting all state in a single `useState` call, and having a `useState` call per each field can work. Components tend to be most readable when you find a balance between these two extremes, and group related state into a few independent state variables. If the state logic becomes complex, we recommend [managing it with a reducer](/docs/hooks-reference.html#usereducer) or a custom Hook. +모든 state를 단일 `useState` 호출에 넣고 필드마다 `useState` 호출을 두는 방법도 쓸 수 있습니다. 컴포넌트는 이러한 두 극단 사이의 균형을 찾고 관련 state를 몇 개의 독립 state 변수로 그룹화할 때 가장 읽기 쉬운 경향이 있습니다. State 로직이 복잡해지면 [리듀서로 관리](/docs/hooks-reference.html#usereducer), 또는 커스텀 Hook을 사용하는 것이 좋습니다. -### Can I run an effect only on updates? {#can-i-run-an-effect-only-on-updates} +### 업데이트에만 effect를 실행할 수 있습니까? {#can-i-run-an-effect-only-on-updates} -This is a rare use case. If you need it, you can [use a mutable ref](#is-there-something-like-instance-variables) to manually store a boolean value corresponding to whether you are on the first or a subsequent render, then check that flag in your effect. (If you find yourself doing this often, you could create a custom Hook for it.) +이것은 드문 사용 사례입니다. 필요한 경우 [변경 가능한 ref를 사용하여](#is-there-something-like-instance-variables) 첫 번째 또는 후속 렌더링에 있는지에 해당하는 부울 값을 수동으로 저장한 다음, 해당 플래그를 확인할 수 있습니다. (이 작업을 자주 수행하는 경우 커스텀 Hook을 만들 수 있습니다.) -### How to get the previous props or state? {#how-to-get-the-previous-props-or-state} +### 이전 props 또는 state를 얻는 방법? {#how-to-get-the-previous-props-or-state} -Currently, you can do it manually [with a ref](#is-there-something-like-instance-variables): +현재는 수동으로 [ref랑 같이](#is-there-something-like-instance-variables) 사용할 수 있습니다. ```js{6,8} function Counter() { @@ -349,7 +349,7 @@ function Counter() { } ``` -This might be a bit convoluted but you can extract it into a custom Hook: +약간 복잡 할 수 있지만, 커스텀 훅으로 추출 할 수 있습니다. ```js{3,7} function Counter() { @@ -367,7 +367,7 @@ function usePrevious(value) { } ``` -Note how this would work for props, state, or any other calculated value. +이것이 props, state 또는 기타 계산된 값에 대해 어떻게 작동하는지 확인하십시오. ```js{5} function Counter() { @@ -378,13 +378,13 @@ function Counter() { // ... ``` -It's possible that in the future React will provide a `usePrevious` Hook out of the box since it's a relatively common use case. +상대적으로 일반적인 사용 사례이기 때문에 향후 React에서 'usePrevious' Hook을 제공 할 수 있습니다. -See also [the recommended pattern for derived state](#how-do-i-implement-getderivedstatefromprops). +[파생 state에 권장되는 패턴](#how-do-i-implement-getderivedstatefromprops)도 참조하세요. -### Why am I seeing stale props or state inside my function? {#why-am-i-seeing-stale-props-or-state-inside-my-function} +### 함수 컴포넌트 안에 오래된 props나 state가 보이는 이유는 무엇입니까? {#why-am-i-seeing-stale-props-or-state-inside-my-function} -Any function inside a component, including event handlers and effects, "sees" the props and state from the render it was created in. For example, consider code like this: +이벤트 처리 및 effect를 포함한 컴포넌트 내부의 모든 함수 컴포넌트는 생성된 렌더링에서 props와 state를 "확인"합니다. 예를 들어 이와 같은 코드를 고려해보십시오. ```js function Example() { @@ -410,21 +410,21 @@ function Example() { } ``` -If you first click "Show alert" and then increment the counter, the alert will show the `count` variable **at the time you clicked the "Show alert" button**. This prevents bugs caused by the code assuming props and state don't change. +먼저 "알림 표시"를 클릭한 다음 카운터를 늘리면 **"알림 표시" 버튼을 클릭할 때** 경고 문구로 `count` 변수가 표시됩니다. 이것은 props와 state가 변경되지 않는다고 가정하는 상황에서 코드로 인한 버그를 방지합니다. -If you intentionally want to read the *latest* state from some asynchronous callback, you could keep it in [a ref](/docs/hooks-faq.html#is-there-something-like-instance-variables), mutate it, and read from it. +일부 비동기 콜백에서 *최근* state를 의도적으로 읽으려면 [ref](/docs/hooks-faq.html#is-there-something-like-instance-variables)에 보관해서 변경하고 읽으면 됩니다. -Finally, another possible reason you're seeing stale props or state is if you use the "dependency array" optimization but didn't correctly specify all the dependencies. For example, if an effect specifies `[]` as the second argument but reads `someProp` inside, it will keep "seeing" the initial value of `someProp`. The solution is to either remove the dependency array, or to fix it. Here's [how you can deal with functions](#is-it-safe-to-omit-functions-from-the-list-of-dependencies), and here's [other common strategies](#what-can-i-do-if-my-effect-dependencies-change-too-often) to run effects less often without incorrectly skipping dependencies. +마지막으로, 부실한 props 또는 state를 볼 수 있는 또 다른 이유는 "종속성 배열" 최적화를 사용하지만 모든 종속성을 올바르게 지정하지 않은 경우입니다. 예를 들어, effect가 `[]`를 두 번째 인수로 지정하지만, 내부에서 `someProp`을 읽는 경우 `someProp`의 초깃값을 계속 "보고"합니다. 해결책은 종속성 배열을 제거하거나 수정하는 것입니다. 다음은 [함수 컴포넌트를 처리하는 방법](#is-it-safe-to-omit-functions-from-the-list-of-dependencies)과 종속성을 잘못 건너뛰지 않고 effect를 덜 실행하는 [일반적인 전략](#what-can-i-do-if-my-effect-dependencies-change-too-often)입니다. ->Note +>주의 > ->We provide an [`exhaustive-deps`](https://github.com/facebook/react/issues/14920) ESLint rule as a part of the [`eslint-plugin-react-hooks`](https://www.npmjs.com/package/eslint-plugin-react-hooks#installation) package. It warns when dependencies are specified incorrectly and suggests a fix. +>[`eslint-plugin-react-hooks`](https://www.npmjs.com/package/eslint-plugin-react-hooks#installation) 패키지의 일부로 [`exhaustive-deps`](https://github.com/facebook/react/issues/14920) ESLint 규칙을 제공합니다. 종속성이 잘못 지정되면 경고하고 수정을 제안합니다. -### How do I implement `getDerivedStateFromProps`? {#how-do-i-implement-getderivedstatefromprops} +### getDerivedStateFromProps를 어떻게 구현합니까? {#how-do-i-implement-getderivedstatefromprops} -While you probably [don't need it](/blog/2018/06/07/you-probably-dont-need-derived-state.html), in rare cases that you do (such as implementing a `` component), you can update the state right during rendering. React will re-run the component with updated state immediately after exiting the first render so it wouldn't be expensive. +[필요하지 않을 수](/blog/2018/06/07/you-probably-dont-need-derived-state.html) 있지만 드물게 수행하는 경우 (예: `` 컴포넌트 구현) 렌더링 중에 state를 바로 업데이트 할 수 있습니다. React는 첫 번째 렌더링을 종료한 후 즉시 업데이트된 state로 컴포넌트를 다시 실행하므로 비용이 많이 들지 않습니다. -Here, we store the previous value of the `row` prop in a state variable so that we can compare: +여기서는 비교할 수 있도록 `row` props의 이전 값을 state 변수에 저장합니다. ```js function ScrollView({row}) { @@ -432,7 +432,7 @@ function ScrollView({row}) { const [prevRow, setPrevRow] = useState(null); if (row !== prevRow) { - // Row changed since last render. Update isScrollingDown. + // 마지막 렌더링 이후 행이 변경되었습니다. isScrollingDown을 업데이트합니다. setIsScrollingDown(prevRow !== null && row > prevRow); setPrevRow(row); } @@ -441,13 +441,13 @@ function ScrollView({row}) { } ``` -This might look strange at first, but an update during rendering is exactly what `getDerivedStateFromProps` has always been like conceptually. +처음에는 이상하게 보일 수 있지만, 렌더링 중 업데이트는 정확히 'getDerivedStateFromProps'가 개념적으로 항상 그랬던 것과 같았습니다. -### Is there something like forceUpdate? {#is-there-something-like-forceupdate} +### forceUpdate와 같은 것이 있습니까? {#is-there-something-like-forceupdate} -Both `useState` and `useReducer` Hooks [bail out of updates](/docs/hooks-reference.html#bailing-out-of-a-state-update) if the next value is the same as the previous one. Mutating state in place and calling `setState` will not cause a re-render. +`useState`와 `useReducer` Hook은 다음 값이 이전 값과 같으면 [업데이트에서 제외됩니다](/docs/hooks-reference.html#bailing-out-of-a-state-update). State를 변경하고 `setState`를 호출해도 다시 렌더링 되지 않습니다. -Normally, you shouldn't mutate local state in React. However, as an escape hatch, you can use an incrementing counter to force a re-render even if the state has not changed: +일반적으로 React에서 로컬 state를 변경해서는 안 됩니다. 그러나 도피 수단으로 증가하는 카운터를 사용하여 state가 변경되지 않은 경우에도 강제로 다시 렌더링 할 수 있습니다. ```js const [ignored, forceUpdate] = useReducer(x => x + 1, 0); @@ -457,15 +457,15 @@ Normally, you shouldn't mutate local state in React. However, as an escape hatch } ``` -Try to avoid this pattern if possible. +가능하면 이 패턴을 피하십시오. -### Can I make a ref to a function component? {#can-i-make-a-ref-to-a-function-component} +### 함수 컴포넌트에 ref를 만들 수 있습니까? {#can-i-make-a-ref-to-a-function-component} -While you shouldn't need this often, you may expose some imperative methods to a parent component with the [`useImperativeHandle`](/docs/hooks-reference.html#useimperativehandle) Hook. +자주 필요하지는 않지만 [`useImperativeHandle`](/docs/hooks-reference.html#useimperativehandle) Hook을 사용하여 일부 명령형 메서드를 부모 컴포넌트에 노출 할 수 있습니다. -### How can I measure a DOM node? {#how-can-i-measure-a-dom-node} +### DOM 노드를 측정하려면 어떻게 해야 합니까? {#how-can-i-measure-a-dom-node} -One rudimentary way to measure the position or size of a DOM node is to use a [callback ref](/docs/refs-and-the-dom.html#callback-refs). React will call that callback whenever the ref gets attached to a different node. Here is a [small demo](https://codesandbox.io/s/l7m0v5x4v9): +DOM 노드의 위치나 크기를 측정하는 기본적인 방법의 하나는 [콜백 ref](/docs/refs-and-the-dom.html#callback-refs)를 사용하는 것입니다. React는 ref가 다른 노드에 연결될 때마다 해당 콜백을 호출합니다. 다음은 [짧은 데모](https://codesandbox.io/s/l7m0v5x4v9)입니다. ```js{4-8,12} function MeasureExample() { @@ -486,13 +486,13 @@ function MeasureExample() { } ``` -We didn't choose `useRef` in this example because an object ref doesn't notify us about *changes* to the current ref value. Using a callback ref ensures that [even if a child component displays the measured node later](https://codesandbox.io/s/818zzk8m78) (e.g. in response to a click), we still get notified about it in the parent component and can update the measurements. +이 예제에서는 객체 ref가 현재 ref 값의 변경 사항에 대해 알려주지 않기 때문에 `useRef`를 선택하지 않았습니다. 콜백 ref를 사용하면 [자식 컴포넌트가 나중에 측정된 노드를 표시하더라도](https://codesandbox.io/s/818zzk8m78) (예: 클릭에 대한 응답으로) 여전히 부모 컴포넌트에서 이에 대한 알림을 받고 측정을 업데이트 할 수 있습니다. -Note that we pass `[]` as a dependency array to `useCallback`. This ensures that our ref callback doesn't change between the re-renders, and so React won't call it unnecessarily. +`[]`를 ʻuseCallback`에 종속성 배열로 전달합니다. 이렇게 하면 ref 콜백이 다시 렌더링 간에 변경되지 않음으로 React가 불필요하게 호출하지 않습니다. -In this example, the callback ref will be called only when the component mounts and unmounts, since the rendered `

` component stays present throughout any rerenders. If you want to be notified any time a component resizes, you may want to use [`ResizeObserver`](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver) or a third-party Hook built on it. +이 예제에서 콜백 ref는 렌더링 된 `

` 컴포넌트가 모든 리렌더 동안 존재하기 때문에 컴포넌트가 마운트 및 마운트 해제될 때만 호출됩니다. 컴포넌트의 크기가 조정될 때마다 알림을 받으려면 [`ResizeObserver`](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver) 또는 여기에 빌드된 제삼자 Hook을 사용할 수 있습니다. -If you want, you can [extract this logic](https://codesandbox.io/s/m5o42082xy) into a reusable Hook: +원한다면 재사용 가능한 Hook으로 [이 로직을 추출](https://codesandbox.io/s/m5o42082xy) 할 수 있습니다: ```js{2} function MeasureExample() { @@ -518,21 +518,19 @@ function useClientRect() { } ``` +### const [thing, setThing] = useState()는 무엇을 의미합니까? {#what-does-const-thing-setthing--usestate-mean} -### What does `const [thing, setThing] = useState()` mean? {#what-does-const-thing-setthing--usestate-mean} +이 구문에 익숙하지 않은 경우 State Hook 문서의 [explanation](/docs/hooks-state.html#tip-what-do-square-brackets-mean)을 확인하세요. -If you're not familiar with this syntax, check out the [explanation](/docs/hooks-state.html#tip-what-do-square-brackets-mean) in the State Hook documentation. +## 성능 최적화 {#performance-optimizations} +### 업데이트 시 effect를 건너뛸 수 있습니까? {#can-i-skip-an-effect-on-updates} -## Performance Optimizations {#performance-optimizations} +예. [조건부 effect 실행](/docs/hooks-reference.html#conditionally-firing-an-effect)을 참조하십시오. 업데이트 처리를 잊어 버리면 종종 [버그가 발생](/docs/hooks-effect.html#explanation-why-effects-run-on-each-update)하므로 이것은 기본 세팅이 아닙니다. -### Can I skip an effect on updates? {#can-i-skip-an-effect-on-updates} +### 종속성 목록에서 함수 컴포넌트를 생략하는 것이 안전합니까? {#is-it-safe-to-omit-functions-from-the-list-of-dependencies} -Yes. See [conditionally firing an effect](/docs/hooks-reference.html#conditionally-firing-an-effect). Note that forgetting to handle updates often [introduces bugs](/docs/hooks-effect.html#explanation-why-effects-run-on-each-update), which is why this isn't the default behavior. - -### Is it safe to omit functions from the list of dependencies? {#is-it-safe-to-omit-functions-from-the-list-of-dependencies} - -Generally speaking, no. +일반적으로는 아닙니다. ```js{3,8} function Example({ someProp }) { @@ -542,11 +540,11 @@ function Example({ someProp }) { useEffect(() => { doSomething(); - }, []); // 🔴 This is not safe (it calls `doSomething` which uses `someProp`) + }, []); // 🔴 이것은 안전하지 않습니다 (`someProp`을 사용하는`doSomething`을 호출합니다) } ``` -It's difficult to remember which props or state are used by functions outside of the effect. This is why **usually you'll want to declare functions needed by an effect *inside* of it.** Then it's easy to see what values from the component scope that effect depends on: +Effect 외부의 함수 컴포넌트에서 어떤 props 또는 state를 사용하는지 기억하기 어렵습니다. 이것이 **일반적으로 그 *내부의* effect에 필요한 함수 컴포넌트를 선언**하려는 이유입니다. 그러면 effect가 미치는 컴포넌트 범위의 값을 쉽게 확인할 수 있습니다. ```js{4,8} function Example({ someProp }) { @@ -556,11 +554,11 @@ function Example({ someProp }) { } doSomething(); - }, [someProp]); // ✅ OK (our effect only uses `someProp`) + }, [someProp]); // ✅ OK (우리 effect는`someProp` 만 사용합니다) } ``` -If after that we still don't use any values from the component scope, it's safe to specify `[]`: +그 후에도 컴포넌트 범위의 값을 사용하지 않으면 `[]`를 지정하는 것이 안전합니다. ```js{7} useEffect(() => { @@ -569,46 +567,46 @@ useEffect(() => { } doSomething(); -}, []); // ✅ OK in this example because we don't use *any* values from component scope +}, []); // ✅ 이 예에서는 컴포넌트 범위의 *어떤* 값도 사용하지 않기 때문에 좋습니다 ``` -Depending on your use case, there are a few more options described below. +사용 사례에 따라 아래에 설명된 몇 가지 옵션이 더 있습니다. ->Note +>주의 > ->We provide the [`exhaustive-deps`](https://github.com/facebook/react/issues/14920) ESLint rule as a part of the [`eslint-plugin-react-hooks`](https://www.npmjs.com/package/eslint-plugin-react-hooks#installation) package. It helps you find components that don't handle updates consistently. +>[`eslint-plugin-react-hooks`](https://www.npmjs.com/package/eslint-plugin-react-hooks#installation) 패키지의 일부로 [`exhaustive-deps`](https://github.com/facebook/react/issues/14920) ESLint 규칙을 제공합니다. 업데이트를 일관되게 처리하지 않는 컴포넌트를 찾는 데 도움이 됩니다. -Let's see why this matters. +이것이 왜 중요한지 봅시다. -If you specify a [list of dependencies](/docs/hooks-reference.html#conditionally-firing-an-effect) as the last argument to `useEffect`, `useLayoutEffect`, `useMemo`, `useCallback`, or `useImperativeHandle`, it must include all values that are used inside the callback and participate in the React data flow. That includes props, state, and anything derived from them. +`useEffect`, `useLayoutEffect`, `useMemo`, `useCallback` 또는 `useImperativeHandle`의 마지막 인수로 [종속성 목록](/docs/hooks-reference.html#conditionally-firing-an-effect)을 지정하는 경우 콜백 내에서 사용되는 모든 값을 포함하고 React 데이터 흐름에 참여해야 합니다. 여기에는 props, state 및 그로부터 파생된 모든 것이 포함됩니다. -It is **only** safe to omit a function from the dependency list if nothing in it (or the functions called by it) references props, state, or values derived from them. This example has a bug: +함수 컴포넌트 (또는 함수 컴포넌트가 호출하는 함수 컴포넌트)가 props, state 또는 파생된 값을 참조하지 않는 **경우에만** 종속성 목록에서 함수 컴포넌트를 생략하는 것이 안전합니다. 이 예에는 버그가 있습니다. ```js{5,12} function ProductPage({ productId }) { const [product, setProduct] = useState(null); async function fetchProduct() { - const response = await fetch('http://myapi/product/' + productId); // Uses productId prop + const response = await fetch('http://myapi/product/' + productId); // productId props 사용 const json = await response.json(); setProduct(json); } useEffect(() => { fetchProduct(); - }, []); // 🔴 Invalid because `fetchProduct` uses `productId` + }, []); // 🔴 `fetchProduct`가`productId`를 사용하므로 잘못되었습니다 // ... } ``` -**The recommended fix is to move that function _inside_ of your effect**. That makes it easy to see which props or state your effect uses, and to ensure they're all declared: +**권장되는 해결 방법은 해당 기능을 effect _내부로_ 이동하는 것입니다**. 이를 통해 effect가 사용하는 props 또는 state를 쉽게 확인하고 모두 선언되었는지 확인할 수 있습니다. ```js{5-10,13} function ProductPage({ productId }) { const [product, setProduct] = useState(null); useEffect(() => { - // By moving this function inside the effect, we can clearly see the values it uses. + // 이 함수 컴포넌트를 effect 내부로 이동하면 사용하는 값을 명확하게 볼 수 있습니다. async function fetchProduct() { const response = await fetch('http://myapi/product/' + productId); const json = await response.json(); @@ -616,12 +614,12 @@ function ProductPage({ productId }) { } fetchProduct(); - }, [productId]); // ✅ Valid because our effect only uses productId + }, [productId]); // ✅ 효과는 productId 만 사용하므로 유효합니다 // ... } ``` -This also allows you to handle out-of-order responses with a local variable inside the effect: +이를 통해 effect 내부의 로컬 변수를 사용하여 비순차적 인 응답을 처리 할 수도 있습니다. ```js{2,6,10} useEffect(() => { @@ -637,24 +635,26 @@ This also allows you to handle out-of-order responses with a local variable insi }, [productId]); ``` -We moved the function inside the effect so it doesn't need to be in its dependency list. +Effect 내부로 함수 컴포넌트를 옮겼으므로 종속성 목록에 있을 필요가 없습니다. ->Tip +>팁 > ->Check out [this small demo](https://codesandbox.io/s/jvvkoo8pq3) and [this article](https://www.robinwieruch.de/react-hooks-fetch-data/) to learn more about data fetching with Hooks. +>이 [짧은 데모](https://codesandbox.io/s/jvvkoo8pq3)와 [이 기사](https://www.robinwieruch.de/react-hooks-fetch-data/)를 확인하여 Hook을 사용한 데이터 가져오기에 대해 자세히 알아보십시오. + +**어떤 이유로 effect 내에서 함수 컴포넌트를 이동할 수 _없는_ 경우 몇 가지 옵션이 더 있습니다.** -**If for some reason you _can't_ move a function inside an effect, there are a few more options:** +* **해당 함수 컴포넌트를 컴포넌트 외부로 이동해 볼 수 있습니다**. 이 경우 함수 컴포넌트는 props나 state를 참조하지 않도록 보장되며 종속성 목록에 있을 필요도 없습니다. -* **You can try moving that function outside of your component**. In that case, the function is guaranteed to not reference any props or state, and also doesn't need to be in the list of dependencies. -* If the function you're calling is a pure computation and is safe to call while rendering, you may **call it outside of the effect instead,** and make the effect depend on the returned value. -* As a last resort, you can **add a function to effect dependencies but _wrap its definition_** into the [`useCallback`](/docs/hooks-reference.html#usecallback) Hook. This ensures it doesn't change on every render unless *its own* dependencies also change: +* 호출하는 함수 컴포넌트가 순수한 계산이고 렌더링하는 동안 호출해도 안전하다면, **대신에 effect 외부에서 호출하고** 반환된 값에 따라 effect가 달라지도록 할 수 있습니다. + +* 마지막 수단으로 **종속성에 영향을 주는 함수 컴포넌트를 추가하되, _정의를_** [`useCallback`](/docs/hooks-reference.html#usecallback) Hook에 **_래핑할 수 있습니다_**. 이렇게 하면 자체 종속성도 변경되지 않는 한 모든 렌더링에서 변경되지 않습니다. ```js{2-5} function ProductPage({ productId }) { - // ✅ Wrap with useCallback to avoid change on every render + // ✅ 모든 렌더링에서 변경되지 않도록 useCallback으로 래핑 const fetchProduct = useCallback(() => { - // ... Does something with productId ... - }, [productId]); // ✅ All useCallback dependencies are specified + // ... productId로 무언가를 합니다 ... + }, [productId]); // ✅ 모든 useCallback 종속성이 지정됩니다 return ; } @@ -662,16 +662,16 @@ function ProductPage({ productId }) { function ProductDetails({ fetchProduct }) { useEffect(() => { fetchProduct(); - }, [fetchProduct]); // ✅ All useEffect dependencies are specified + }, [fetchProduct]); // ✅ 모든 useEffect 종속성이 지정됩니다 // ... } ``` -Note that in the above example we **need** to keep the function in the dependencies list. This ensures that a change in the `productId` prop of `ProductPage` automatically triggers a refetch in the `ProductDetails` component. +위의 예에서 종속성 목록에 함수 컴포넌트를 유지할 **필요**가 있습니다. 이렇게 하면 `ProductPage`의 `productId` props가 변경되면 `ProductDetails` 컴포넌트에서 자동으로 다시 가져오기가 트리거 됩니다. -### What can I do if my effect dependencies change too often? {#what-can-i-do-if-my-effect-dependencies-change-too-often} +### effect 종속성이 너무 자주 변경되면 어떻게 해야 합니까? {#what-can-i-do-if-my-effect-dependencies-change-too-often} -Sometimes, your effect may be using state that changes too often. You might be tempted to omit that state from a list of dependencies, but that usually leads to bugs: +때로는 effect가 너무 자주 변경되는 state를 사용할 수도 있습니다. 종속성 목록에서 해당 state를 생략하고 싶을 수 있지만, 이 경우 일반적으로 버그가 발생합니다. ```js{6,9} function Counter() { @@ -679,18 +679,18 @@ function Counter() { useEffect(() => { const id = setInterval(() => { - setCount(count + 1); // This effect depends on the `count` state + setCount(count + 1); // 이 effect는 'count' state에 따라 다릅니다 }, 1000); return () => clearInterval(id); - }, []); // 🔴 Bug: `count` is not specified as a dependency + }, []); // 🔴 버그: `count`가 종속성으로 지정되지 않았습니다 return

{count}

; } ``` -The empty set of dependencies, `[]`, means that the effect will only run once when the component mounts, and not on every re-render. The problem is that inside the `setInterval` callback, the value of `count` does not change, because we've created a closure with the value of `count` set to `0` as it was when the effect callback ran. Every second, this callback then calls `setCount(0 + 1)`, so the count never goes above 1. +빈 종속성 세트, `[]`는 컴포넌트가 마운트 될 때마다 effect가 한 번만 실행되고 매번 렌더링 시에는 실행되지 않음을 의미합니다. 문제는 `setInterval` 콜백 내에서 `count` 값이 변경되지 않는다는 것입니다. Effect 콜백이 실행되었을 때와 마찬가지로 count 값이 0으로 설정된 클로저를 생성했기 때문입니다. 이 콜백은 매초 `setCount(0 + 1)`를 호출하므로 카운트가 1을 초과하지 않습니다. -Specifying `[count]` as a list of dependencies would fix the bug, but would cause the interval to be reset on every change. Effectively, each `setInterval` would get one chance to execute before being cleared (similar to a `setTimeout`.) That may not be desirable. To fix this, we can use the [functional update form of `setState`](/docs/hooks-reference.html#functional-updates). It lets us specify *how* the state needs to change without referencing the *current* state: +종속성 목록으로 `[count]`를 지정하면 버그가 수정되지만, 변경될 때마다 간격이 재설정됩니다. 효과적으로, 각 `setInterval`은 지워지기 전에 한 번의 실행 기회를 갖게 됩니다 (`setTimeout`과 유사). 이는 바람직하지 않을 수 있습니다. 이를 해결하기 위해 `setState`의 [함수 컴포넌트 업데이트 폼](/docs/hooks-reference.html#functional-updates)을 사용할 수 있습니다. *현재* state를 참조하지 않고 state를 변경해야 하는 *방법*을 지정할 수 있습니다. ```js{6,9} function Counter() { @@ -698,26 +698,26 @@ function Counter() { useEffect(() => { const id = setInterval(() => { - setCount(c => c + 1); // ✅ This doesn't depend on `count` variable outside + setCount(c => c + 1); // ✅ 이것은 외부의 'count' 변수에 의존하지 않습니다 }, 1000); return () => clearInterval(id); - }, []); // ✅ Our effect doesn't use any variables in the component scope + }, []); // ✅ 우리의 effect는 컴포넌트 범위의 변수를 사용하지 않습니다 return

{count}

; } ``` -(The identity of the `setCount` function is guaranteed to be stable so it's safe to omit.) +(`setCount` 함수 컴포넌트의 정체성은 안정적이므로 생략해도 안전합니다.) -Now, the `setInterval` callback executes once a second, but each time the inner call to `setCount` can use an up-to-date value for `count` (called `c` in the callback here.) +이제 `setInterval` 콜백이 1초에 한 번 실행되지만 `setCount`에 대한 내부 호출이 `count`에 최신 값을 사용할 수 있습니다. (여기서는 콜백에서 `c`라고 함). -In more complex cases (such as if one state depends on another state), try moving the state update logic outside the effect with the [`useReducer` Hook](/docs/hooks-reference.html#usereducer). [This article](https://adamrackis.dev/state-and-use-reducer/) offers an example of how you can do this. **The identity of the `dispatch` function from `useReducer` is always stable** — even if the reducer function is declared inside the component and reads its props. +더 복잡한 경우 (예: 한 state가 다른 state에 의존하는 경우) [`useReducer` Hook](/docs/hooks-reference.html#usereducer)을 사용하여 state 업데이트 로직을 effect 외부로 이동해보십시오. [이 문서](https://adamrackis.dev/state-and-use-reducer/)에서는 이를 수행하는 방법에 대한 예를 제공합니다. **`useReducer`의 `dispatch` 함수 컴포넌트의 정체성은 항상 안정적입니다** — 리듀서 함수 컴포넌트가 컴포넌트 내부에서 선언되고 해당 props를 읽는 경우에도 마찬가지입니다. -As a last resort, if you want something like `this` in a class, you can [use a ref](/docs/hooks-faq.html#is-there-something-like-instance-variables) to hold a mutable variable. Then you can write and read to it. For example: +마지막 수단으로, class에서 `this`와 같은 것을 원한다면 [ref를 사용](/docs/hooks-faq.html#is-there-something-like-instance-variables)하여 가변 변수를 보유 할 수 있습니다. 그런 다음 그것을 쓰고 읽을 수 있습니다. 예를 들면. ```js{2-6,10-11,16} function Example(props) { - // Keep latest props in a ref. + // 최신 props를 ref에 보관하십시오. const latestProps = useRef(props); useEffect(() => { latestProps.current = props; @@ -725,53 +725,53 @@ function Example(props) { useEffect(() => { function tick() { - // Read latest props at any time + // 언제든지 최신 props 읽기 console.log(latestProps.current); } const id = setInterval(tick, 1000); return () => clearInterval(id); - }, []); // This effect never re-runs + }, []); // 이 effect는 다시 실행되지 않습니다 } ``` -Only do this if you couldn't find a better alternative, as relying on mutation makes components less predictable. If there's a specific pattern that doesn't translate well, [file an issue](https://github.com/facebook/react/issues/new) with a runnable example code and we can try to help. +변형에 의존하면 컴포넌트를 예측하기 어렵기 때문에 더 나은 대안을 찾을 수 없는 경우에만 이 작업을 수행하십시오. 제대로 옮겨지지 않는 특정 패턴이 있는 경우 실행 가능한 예제 코드로 [문제를 제출하면](https://github.com/facebook/react/issues/new) 도움을 드릴 수 있습니다. -### How do I implement `shouldComponentUpdate`? {#how-do-i-implement-shouldcomponentupdate} +### shouldComponentUpdate는 어떻게 구현합니까? {#how-do-i-implement-shouldcomponentupdate} -You can wrap a function component with `React.memo` to shallowly compare its props: +함수 컴포넌트를 `React.memo`로 래핑하여 props를 얕게 비교할 수 있습니다. ```js const Button = React.memo((props) => { - // your component + // 당신의 컴포넌트 }); ``` -It's not a Hook because it doesn't compose like Hooks do. `React.memo` is equivalent to `PureComponent`, but it only compares props. (You can also add a second argument to specify a custom comparison function that takes the old and new props. If it returns true, the update is skipped.) +Hook처럼 구성하지 않기 때문에 Hook이 아닙니다. `React.memo`는 `PureComponent`와 동일하지만, props만 비교합니다. (두 번째 인수를 추가하여 이전 및 새 props를 받는 커스텀 비교 함수 컴포넌트를 지정할 수도 있습니다. true를 반환하면 업데이트를 건너뜁니다.) -`React.memo` doesn't compare state because there is no single state object to compare. But you can make children pure too, or even [optimize individual children with `useMemo`](/docs/hooks-faq.html#how-to-memoize-calculations). +`React.memo`는 비교할 단일 state 객체가 없기 때문에 state를 비교하지 않습니다. 하지만 자식들을 순수하게 만들 수도 있고 [`useMemo`를 사용하여 개별 자식들을 최적화](/docs/hooks-faq.html#how-to-memoize-calculations) 할 수도 있습니다. -### How to memoize calculations? {#how-to-memoize-calculations} +### 계산을 메모이제이션 하는 법? {#how-to-memoize-calculations} -The [`useMemo`](/docs/hooks-reference.html#usememo) Hook lets you cache calculations between multiple renders by "remembering" the previous computation: +[`useMemo`](/docs/hooks-reference.html#usememo) Hook을 사용하면 이전 계산을 "기억"하여 여러 렌더링 간에 계산을 캐시 할 수 있습니다. ```js const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]); ``` -This code calls `computeExpensiveValue(a, b)`. But if the dependencies `[a, b]` haven't changed since the last value, `useMemo` skips calling it a second time and simply reuses the last value it returned. +이 코드는 `computeExpensiveValue(a, b)`를 호출합니다. 그러나 종속성 `[a, b]`가 마지막 값 이후로 변경되지 않은 경우 `useMemo`는 두 번째 호출을 건너뛰고 반환된 마지막 값을 재사용합니다. -Remember that the function passed to `useMemo` runs during rendering. Don't do anything there that you wouldn't normally do while rendering. For example, side effects belong in `useEffect`, not `useMemo`. +`useMemo`에 전달된 함수는 렌더링 중에 실행됩니다. 렌더링하는 동안 일반적으로 하지 않는 작업은 하지 마십시오. 예를 들어 부작용은 `useMemo`가 아니라 `useEffect`에 속합니다. -**You may rely on `useMemo` as a performance optimization, not as a semantic guarantee.** In the future, React may choose to "forget" some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components. Write your code so that it still works without `useMemo` — and then add it to optimize performance. (For rare cases when a value must *never* be recomputed, you can [lazily initialize](#how-to-create-expensive-objects-lazily) a ref.) +**의미론적 보장이 아닌 성능 최적화로 `useMemo`를 사용할 수 있습니다.** 미래에 React는 이전에 메모한 일부 값을 "잊고" 다음 렌더링에서 다시 계산하도록 선택할 수 있습니다. 오프 스크린 컴포넌트를 위한 메모리를 확보합니다. `useMemo` 없이도 계속 작동하도록 코드를 작성한 다음 추가하여 성능을 최적화하십시오. (값을 다시 계산해서는 안 되는 드문 경우의 경우, ref를 [느리게 초기화](#how-to-create-expensive-objects-lazily) 할 수 있습니다.) -Conveniently, `useMemo` also lets you skip an expensive re-render of a child: +편리하게도 `useMemo`를 사용하면 자녀의 값 비싼 다시 렌더링을 건너뛸 수 있습니다. ```js function Parent({ a, b }) { - // Only re-rendered if `a` changes: + // 'a'가 변경된 경우에만 다시 렌더링 됩니다: const child1 = useMemo(() => , [a]); - // Only re-rendered if `b` changes: + // 'b'가 변경된 경우에만 다시 렌더링 됩니다: const child2 = useMemo(() => , [b]); return ( <> @@ -782,51 +782,51 @@ function Parent({ a, b }) { } ``` -Note that this approach won't work in a loop because Hook calls [can't](/docs/hooks-rules.html) be placed inside loops. But you can extract a separate component for the list item, and call `useMemo` there. +Hook 호출은 루프 내부에 배치될 수 [없기](/docs/hooks-rules.html) 때문에 이 방법은 루프에서 작동하지 않습니다. 그러나 목록 항목에 대해 별도의 컴포넌트를 추출하고 거기에서 `useMemo`를 호출 할 수 있습니다. -### How to create expensive objects lazily? {#how-to-create-expensive-objects-lazily} +### 고비용의 객체를 지연해서 생성하는 법? {#how-to-create-expensive-objects-lazily} -`useMemo` lets you [memoize an expensive calculation](#how-to-memoize-calculations) if the dependencies are the same. However, it only serves as a hint, and doesn't *guarantee* the computation won't re-run. But sometimes you need to be sure an object is only created once. +`useMemo`를 사용하면 종속성이 동일한 경우 [값비싼 계산을 메모](#how-to-memoize-calculations) 할 수 있습니다. 그러나 힌트 역할을 할 뿐이며 계산이 다시 실행되지 않는다는 *보장*은 없습니다. 때로는 객체가 한 번만 생성되었는지 확인해야 합니다. -**The first common use case is when creating the initial state is expensive:** +**첫 번째 일반적인 사용 사례는 초기 state를 만드는 데 비용이 많이 드는 경우입니다.** ```js function Table(props) { - // ⚠️ createRows() is called on every render + // ⚠️ createRows()는 모든 렌더링에서 호출됩니다 const [rows, setRows] = useState(createRows(props.count)); // ... } ``` -To avoid re-creating the ignored initial state, we can pass a **function** to `useState`: +무시된 초기 state를 다시 생성하지 않으려면 `useState`에 **함수 컴포넌트**를 전달할 수 있습니다. ```js function Table(props) { - // ✅ createRows() is only called once + // ✅ createRows()는 한 번만 호출됩니다 const [rows, setRows] = useState(() => createRows(props.count)); // ... } ``` -React will only call this function during the first render. See the [`useState` API reference](/docs/hooks-reference.html#usestate). +React는 첫 번째 렌더링 중에만 함수 컴포넌트를 호출합니다. [`useState` API 참조](/docs/hooks-reference.html#usestate)를 확인하세요. -**You might also occasionally want to avoid re-creating the `useRef()` initial value.** For example, maybe you want to ensure some imperative class instance only gets created once: +**때때로 `useRef()` 초깃값을 다시 작성하지 않으려고 할 수도 있습니다.** 예를 들어 명령형 class 인스턴스가 한 번만 생성되도록 하고 싶을 수 있습니다. ```js function Image(props) { - // ⚠️ IntersectionObserver is created on every render + // ⚠️ IntersectionObserver는 모든 렌더링에서 생성됩니다 const ref = useRef(new IntersectionObserver(onIntersect)); // ... } ``` -`useRef` **does not** accept a special function overload like `useState`. Instead, you can write your own function that creates and sets it lazily: +`useRef`는 `useState`와 같은 특수 함수 컴포넌트 오버로드를 허용하지 **않습니다.** 대신 느리게 생성하고 설정하는 자체 함수 컴포넌트를 작성할 수 있습니다. ```js function Image(props) { const ref = useRef(null); - // ✅ IntersectionObserver is created lazily once + // ✅ IntersectionObserver는 한 번 느리게 생성됩니다 function getObserver() { if (ref.current === null) { ref.current = new IntersectionObserver(onIntersect); @@ -834,50 +834,49 @@ function Image(props) { return ref.current; } - // When you need it, call getObserver() + // 필요할 때 getObserver()를 호출하십시오 // ... } ``` -This avoids creating an expensive object until it's truly needed for the first time. If you use Flow or TypeScript, you can also give `getObserver()` a non-nullable type for convenience. - +이렇게 하면 처음에 진정으로 필요할 때까지는 값비싼 개체를 만들지 않아도 됩니다. Flow 또는 TypeScript를 사용하는 경우 편의를 위해 `getObserver()`에 nullable이 아닌 유형을 제공 할 수도 있습니다. -### Are Hooks slow because of creating functions in render? {#are-hooks-slow-because-of-creating-functions-in-render} +### 렌더링에서 함수 컴포넌트를 만들기 때문에 Hook이 느려집니까? {#are-hooks-slow-because-of-creating-functions-in-render} -No. In modern browsers, the raw performance of closures compared to classes doesn't differ significantly except in extreme scenarios. +아니요. 최신 브라우저에서 class와 비교해 클로저의 원시적 성능은 극단적인 시나리오를 제외하고는 크게 다르지 않습니다. -In addition, consider that the design of Hooks is more efficient in a couple ways: +또한 Hook 디자인이 몇 가지 면에서 더 효율적이라는 것을 고려하십시오. -* Hooks avoid a lot of the overhead that classes require, like the cost of creating class instances and binding event handlers in the constructor. +* Hook은 class 인스턴스를 만들고 생성자에서 이벤트 핸들러를 바인딩하는 비용과 같이 class에 필요한 많은 오버헤드를 방지합니다. -* **Idiomatic code using Hooks doesn't need the deep component tree nesting** that is prevalent in codebases that use higher-order components, render props, and context. With smaller component trees, React has less work to do. +* **Hook을 사용하는 관용적 코드에는** 고차 컴포넌트, 렌더링 props 및 context를 사용하는 코드 베이스에서 널리 알려진 **깊은 컴포넌트 트리 중첩이 필요하지 않습니다.** 컴포넌트 트리가 작을수록 React는 할 일이 적습니다. -Traditionally, performance concerns around inline functions in React have been related to how passing new callbacks on each render breaks `shouldComponentUpdate` optimizations in child components. Hooks approach this problem from three sides. +전통적으로 React의 인라인 함수 컴포넌트와 관련된 성능 문제는 각 렌더에서 새 콜백을 전달하면 자식 컴포넌트에서 `shouldComponentUpdate` 최적화가 중단되는 방식과 관련이 있습니다. Hook은 세 가지 측면에서 이 문제에 접근합니다. -* The [`useCallback`](/docs/hooks-reference.html#usecallback) Hook lets you keep the same callback reference between re-renders so that `shouldComponentUpdate` continues to work: +* [`useCallback`](/docs/hooks-reference.html#usecallback) Hook을 사용하면 `shouldComponentUpdate`가 계속 작동하도록 다시 렌더링간에 동일한 콜백 참조를 유지할 수 있습니다. ```js{2} - // Will not change unless `a` or `b` changes + // `a` 또는` b`가 변경되지 않으면 변경되지 않습니다 const memoizedCallback = useCallback(() => { doSomething(a, b); }, [a, b]); ``` -* The [`useMemo`](/docs/hooks-faq.html#how-to-memoize-calculations) Hook makes it easier to control when individual children update, reducing the need for pure components. +* [`useMemo`](/docs/hooks-faq.html#how-to-memoize-calculations) Hook을 사용하면 개별 자식들이 업데이트되는 시기를 보다 쉽게 제어할 수 있음으로 순수한 컴포넌트의 필요성이 줄어듭니다. -* Finally, the [`useReducer`](/docs/hooks-reference.html#usereducer) Hook reduces the need to pass callbacks deeply, as explained below. +* 마지막으로, [`useReducer`](/docs/hooks-reference.html#usereducer) Hook은 아래에 설명된 것처럼 콜백을 깊이 전달할 필요성을 줄여줍니다. -### How to avoid passing callbacks down? {#how-to-avoid-passing-callbacks-down} +### 콜백 전달을 피하는 법? {#how-to-avoid-passing-callbacks-down} -We've found that most people don't enjoy manually passing callbacks through every level of a component tree. Even though it is more explicit, it can feel like a lot of "plumbing". +우리는 대부분의 사람이 모든 레벨의 컴포넌트 트리를 통해 콜백을 수동으로 전달하는 것을 좋아하지 않는다는 것을 발견했습니다. 더 명백하지만 마치 "배관"이 많은 것처럼 느껴질 수 있습니다. -In large component trees, an alternative we recommend is to pass down a `dispatch` function from [`useReducer`](/docs/hooks-reference.html#usereducer) via context: +큰 컴포넌트 트리에서 권장되는 대안은 context를 통해 [`useReducer`](/docs/hooks-reference.html#usereducer)에서 `dispatch` 함수 컴포넌트를 전달하는 것입니다. ```js{4,5} const TodosDispatch = React.createContext(null); function TodosApp() { - // Note: `dispatch` won't change between re-renders + // 주의: `dispatch`는 다시 렌더링 간에 변경되지 않습니다 const [todos, dispatch] = useReducer(todosReducer); return ( @@ -888,11 +887,11 @@ function TodosApp() { } ``` -Any child in the tree inside `TodosApp` can use the `dispatch` function to pass actions up to `TodosApp`: +`TodosApp` 내의 트리에 있는 모든 자식은 `dispatch` 기능을 사용하여 `TodosApp`에 작업을 전달할 수 있습니다. ```js{2,3} function DeepChild(props) { - // If we want to perform an action, we can get dispatch from context. + // 작업을 수행하려면 context에서 dispatch를 얻을 수 있습니다. const dispatch = useContext(TodosDispatch); function handleClick() { @@ -905,19 +904,19 @@ function DeepChild(props) { } ``` -This is both more convenient from the maintenance perspective (no need to keep forwarding callbacks), and avoids the callback problem altogether. Passing `dispatch` down like this is the recommended pattern for deep updates. +이것은 유지 보수 관점에서 더 편리하고 (콜백을 계속 전달할 필요가 없음) 콜백 문제를 모두 방지합니다. 이처럼 `dispatch`를 전달하는 것이 심층 업데이트에 권장되는 패턴입니다. -Note that you can still choose whether to pass the application *state* down as props (more explicit) or as context (more convenient for very deep updates). If you use context to pass down the state too, use two different context types -- the `dispatch` context never changes, so components that read it don't need to rerender unless they also need the application state. +애플리케이션 state를 props (더욱 명백한) 또는 context로 (매우 심층적인 업데이트에 더 편리함) 전달할지 여부를 선택할 수 있습니다. context를 사용하여 state를 전달하는 경우에도 두 가지 context 유형을 사용하십시오. `dispatch` context는 변경되지 않음으로 이를 읽는 컴포넌트는 애플리케이션 state가 필요하지 않은 한 다시 렌더링할 필요가 없습니다. -### How to read an often-changing value from `useCallback`? {#how-to-read-an-often-changing-value-from-usecallback} +### useCallback에서 자주 변경되는 값을 읽는 방법? {#how-to-read-an-often-changing-value-from-usecallback} ->Note +>주의 > ->We recommend to [pass `dispatch` down in context](#how-to-avoid-passing-callbacks-down) rather than individual callbacks in props. The approach below is only mentioned here for completeness and as an escape hatch. +>props의 개별 콜백보다는 [context에서 `dispatch`를 전달](#how-to-avoid-passing-callbacks-down)하는 것이 좋습니다. 아래 접근 방식은 완전성과 탈출구로만 여기에서 언급됩니다. > ->Also note that this pattern might cause problems in the [concurrent mode](/blog/2018/03/27/update-on-async-rendering.html). We plan to provide more ergonomic alternatives in the future, but the safest solution right now is to always invalidate the callback if some value it depends on changes. +>또한 이 패턴은 [동시 모드](/blog/2018/03/27/update-on-async-rendering.html)에서 문제를 일으킬 수 있습니다. 앞으로 더 효율적인 대안을 제공할 계획이지만 현재 가장 안전한 해결책은 값이 변경에 따라 달라지는 경우 항상 콜백을 무효로 하는 것입니다. -In some rare cases you might need to memoize a callback with [`useCallback`](/docs/hooks-reference.html#usecallback) but the memoization doesn't work very well because the inner function has to be re-created too often. If the function you're memoizing is an event handler and isn't used during rendering, you can use [ref as an instance variable](#is-there-something-like-instance-variables), and save the last committed value into it manually: +드물게 [`useCallback`](/docs/hooks-reference.html#usecallback)을 사용하여 콜백을 메모해야 할 수도 있지만, 내부 함수 컴포넌트를 너무 자주 다시 만들어야 하므로 메모가 제대로 작동하지 않습니다. 메모하는 함수 컴포넌트가 이벤트 핸들러이고 렌더링 중에 사용되지 않는 경우 [ref를 인스턴스 변수로](#is-there-something-like-instance-variables) 사용하고 마지막으로 커밋 된 값을 수동으로 저장할 수 있습니다. ```js{6,10} function Form() { @@ -925,13 +924,13 @@ function Form() { const textRef = useRef(); useEffect(() => { - textRef.current = text; // Write it to the ref + textRef.current = text; // ref에 쓰기 }); const handleSubmit = useCallback(() => { - const currentText = textRef.current; // Read it from the ref + const currentText = textRef.current; // ref에서 읽기 alert(currentText); - }, [textRef]); // Don't recreate handleSubmit like [text] would do + }, [textRef]); // [text]처럼 handleSubmit을 다시 만들지 마십시오 return ( <> @@ -942,12 +941,12 @@ function Form() { } ``` -This is a rather convoluted pattern but it shows that you can do this escape hatch optimization if you need it. It's more bearable if you extract it to a custom Hook: +이것은 다소 복잡한 패턴이지만 필요한 경우에 탈출구 최적화를 수행 할 수 있음을 보여줍니다. 커스텀 Hook으로 추출하면 견딜 수 있습니다. ```js{4,16} function Form() { const [text, updateText] = useState(''); - // Will be memoized even if `text` changes: + // 'text'가 변경되어도 메모합니다: const handleSubmit = useEventCallback(() => { alert(text); }, [text]); @@ -976,27 +975,26 @@ function useEventCallback(fn, dependencies) { } ``` -In either case, we **don't recommend this pattern** and only show it here for completeness. Instead, it is preferable to [avoid passing callbacks deep down](#how-to-avoid-passing-callbacks-down). - +두 경우 모두 이 패턴을 **권장하지 않으며** 완전성을 위해 여기에 표시합니다. 대신 [콜백을 깊게 전달하지 않는 것](#how-to-avoid-passing-callbacks-down)이 좋습니다. -## Under the Hood {#under-the-hood} +## Hook의 이면 {#under-the-hood} -### How does React associate Hook calls with components? {#how-does-react-associate-hook-calls-with-components} +### React는 Hook 호출을 컴포넌트와 어떻게 연관시키는가? {#how-does-react-associate-hook-calls-with-components} -React keeps track of the currently rendering component. Thanks to the [Rules of Hooks](/docs/hooks-rules.html), we know that Hooks are only called from React components (or custom Hooks -- which are also only called from React components). +React는 현재 렌더링 컴포넌트를 추적합니다. [Rules of Hook](/docs/hooks-rules.html) 덕분에 Hook은 React 컴포넌트 (또는 React 컴포넌트에서만 호출되는 커스텀 Hook)에서만 호출된다는 것을 알고 있습니다. -There is an internal list of "memory cells" associated with each component. They're just JavaScript objects where we can put some data. When you call a Hook like `useState()`, it reads the current cell (or initializes it during the first render), and then moves the pointer to the next one. This is how multiple `useState()` calls each get independent local state. +각 컴포넌트와 관련된 "메모리 셀"의 내부 목록이 있습니다. 이것은 단지 데이터를 넣을 수 있는 JavaScript 객체입니다. `useState()`와 같은 Hook을 호출하면 현재 셀을 읽거나 첫 번째 렌더링 중에 초기화한 다음 포인터를 다음 셀로 이동합니다. 이것이 여러 `useState()` 호출이 각각 독립적인 로컬 state를 얻는 방법입니다. -### What is the prior art for Hooks? {#what-is-the-prior-art-for-hooks} +### Hook에 대한 선행 기술은 무엇입니까? {#what-is-the-prior-art-for-hooks} -Hooks synthesize ideas from several different sources: +Hook은 여러 소스에서 아이디어를 합성합니다. -* Our old experiments with functional APIs in the [react-future](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) repository. -* React community's experiments with render prop APIs, including [Ryan Florence](https://github.com/ryanflorence)'s [Reactions Component](https://github.com/reactions/component). -* [Dominic Gannaway](https://github.com/trueadm)'s [`adopt` keyword](https://gist.github.com/trueadm/17beb64288e30192f3aa29cad0218067) proposal as a sugar syntax for render props. -* State variables and state cells in [DisplayScript](http://displayscript.org/introduction.html). -* [Reducer components](https://reasonml.github.io/reason-react/docs/en/state-actions-reducer.html) in ReasonReact. -* [Subscriptions](http://reactivex.io/rxjs/class/es6/Subscription.js~Subscription.html) in Rx. -* [Algebraic effects](https://github.com/ocamllabs/ocaml-effects-tutorial#2-effectful-computations-in-a-pure-setting) in Multicore OCaml. +* [react-future](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) 저장소에서 기능적 API를 사용한 이전 실험. +* [Ryan Florence](https://github.com/ryanflorence)의 [Reactions 컴포넌트](https://github.com/reactions/component)를 포함하여 렌더링 props API를 사용한 React 커뮤니티의 실험. +* 렌더링 props를 위한 편의 문법으로 제안된 [Dominic Gannaway](https://github.com/trueadm)의 [`adopt` 키워드](https://gist.github.com/trueadm/17beb64288e30192f3aa29cad0218067). +* [DisplayScript](http://displayscript.org/introduction.html)의 state 변수 및 state 셀. +* ReasonReact의 [리듀서 컴포넌트](https://reasonml.github.io/reason-react/docs/en/state-actions-reducer.html). +* Rx의 [구독](http://reactivex.io/rxjs/class/es6/Subscription.js~Subscription.html). +* Multicore OCaml의 [대수 효과](https://github.com/ocamllabs/ocaml-effects-tutorial#2-effectful-computations-in-a-pure-setting). -[Sebastian Markbåge](https://github.com/sebmarkbage) came up with the original design for Hooks, later refined by [Andrew Clark](https://github.com/acdlite), [Sophie Alpert](https://github.com/sophiebits), [Dominic Gannaway](https://github.com/trueadm), and other members of the React team. +[Sebastian Markbåge](https://github.com/sebmarkbage)는 Hook의 원래 디자인을 생각해냈고, 나중에 [Andrew Clark](https://github.com/acdlite), [Sophie Alpert](https://github.com/sophiebits), [Dominic Gannaway](https://github.com/trueadm) 및 React 팀의 다른 구성원에 의해 개선되었습니다.