diff --git a/content/docs/optimizing-performance.md b/content/docs/optimizing-performance.md index 1222abf05..8b95bdbdd 100644 --- a/content/docs/optimizing-performance.md +++ b/content/docs/optimizing-performance.md @@ -1,93 +1,93 @@ --- id: optimizing-performance -title: Optimizing Performance +title: 성능 최적화 permalink: docs/optimizing-performance.html redirect_from: - "docs/advanced-performance.html" --- -Internally, React uses several clever techniques to minimize the number of costly DOM operations required to update the UI. For many applications, using React will lead to a fast user interface without doing much work to specifically optimize for performance. Nevertheless, there are several ways you can speed up your React application. +내부적으로 React는 UI를 최신화하기 위해 비용이 많이 드는 DOM 작업의 수를 최소화하기 위해 몇 가지 기발한 방법을 활용합니다. 많은 애플리케이션에서 React를 사용하면 성능을 특별히 최적화하기 위해 많은 작업을 수행하지 않고도 빠른 사용자 인터페이스로 이어질 수 있습니다. 그럼에도 불구하고 React 애플리케이션의 속도를 높일 수 있는 몇 가지 방법이 있습니다. -## Use the Production Build {#use-the-production-build} +## 프로덕션 빌드를 활용하세요 {#use-the-production-build} -If you're benchmarking or experiencing performance problems in your React apps, make sure you're testing with the minified production build. +React 앱에서 성능 문제를 겪고 있거나 벤치마크하고 있는 경우, 축소된 프로덕션 빌드를 사용하여 테스트를 수행하고 있는지 확인하세요. -By default, React includes many helpful warnings. These warnings are very useful in development. However, they make React larger and slower so you should make sure to use the production version when you deploy the app. +기본적으로 React에는 유용한 경고가 많이 포함되어 있습니다. 이 경고들은 개발하는데 있어 매우 유용합니다. 그러나 그 경고는 React를 더 크고 느리게 만들기 때문에 앱을 배포할 때 프로덕션 버전을 사용해야합니다. -If you aren't sure whether your build process is set up correctly, you can check it by installing [React Developer Tools for Chrome](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi). If you visit a site with React in production mode, the icon will have a dark background: +빌드 프로세스가 올바르게 설정되었는지 잘 모르는 경우에는 [React Developer Tools for Chrome](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi)를 설치하여 확인할 수 있습니다. 프로덕션 모드의 React 기반 사이트에 접속하면 아이콘의 배경이 어두운 색으로 표시됩니다. React DevTools on a website with production version of React -If you visit a site with React in development mode, the icon will have a red background: +개발 모드의 React 기반 사이트에 접속하면 아이콘의 배경이 빨간색으로 표시됩니다. React DevTools on a website with development version of React -It is expected that you use the development mode when working on your app, and the production mode when deploying your app to the users. +앱을 개발할 때는 개발 모드를, 사용자에게 앱을 배포할 때는 프로덕션 모드를 사용해야 합니다. -You can find instructions for building your app for production below. +아래에서 프로덕션 용도의 앱을 제작할 수 있는 방법을 확인할 수 있습니다. ### Create React App {#create-react-app} -If your project is built with [Create React App](https://github.com/facebookincubator/create-react-app), run: +프로젝트가 Create React App 기반이라면 아래 명령어를 실행하세요. ``` npm run build ``` -This will create a production build of your app in the `build/` folder of your project. +명령어를 실행하면 프로젝트의 `build/` 폴더에 애플리케이션의 프로덕션 빌드파일이 만들어집니다. -Remember that this is only necessary before deploying to production. For normal development, use `npm start`. +프로덕션 환경에 배포하기 전에만 필요하다는 것을 기억하세요. 정상적인 개발 환경에선 `npm start`를 이용하세요. -### Single-File Builds {#single-file-builds} +### 단일 파일 빌드 {#single-file-builds} -We offer production-ready versions of React and React DOM as single files: +React 및 React DOM의 프로덕션 준비 버전을 단일 파일로 제공합니다. ```html ``` -Remember that only React files ending with `.production.min.js` are suitable for production. +`.production.min.js`로 끝나는 React 파일만이 프로덕션 환경에 적합합니다. ### Brunch {#brunch} -For the most efficient Brunch production build, install the [`terser-brunch`](https://github.com/brunch/terser-brunch) plugin: +가장 효율적인 Brunch 프로덕션 빌드를 위해 [`terser-brunch`](https://github.com/brunch/terser-brunch)를 설치하세요. ``` -# If you use npm +# npm을 사용한다면 npm install --save-dev terser-brunch -# If you use Yarn +# Yarn을 사용한다면 yarn add --dev terser-brunch ``` -Then, to create a production build, add the `-p` flag to the `build` command: +다음 프로덕션 빌드를 생성하기 위해 `build` 명령어에 `-p` 플래그를 추가합니다. ``` brunch build -p ``` -Remember that you only need to do this for production builds. You shouldn't pass the `-p` flag or apply this plugin in development, because it will hide useful React warnings and make the builds much slower. +프로덕션 빌드에 대해서만 이 작업을 수행하면 됩니다. React의 유용한 경고문구를 숨기고 빌드를 훨씬 느리게 만들기 때문에 개발 환경에서 플러그인을 적용하거나 `-p`플래그를 추가하지 마세요. ### Browserify {#browserify} -For the most efficient Browserify production build, install a few plugins: +가장 효율적인 Browserify 프로덕션 빌드를 위해 몇 가지 플러그인을 설치하세요. ``` -# If you use npm +# npm을 사용하는 경우 npm install --save-dev envify terser uglifyify -# If you use Yarn -yarn add --dev envify terser uglifyify +# Yarn을 사용하는 경우 +yarn add --dev envify terser uglifyify ``` -To create a production build, make sure that you add these transforms **(the order matters)**: +프로덕션 빌드를 만들려면, 다음 변환을 추가하세요. **(순서는 중요합니다.)** -* The [`envify`](https://github.com/hughsk/envify) transform ensures the right build environment is set. Make it global (`-g`). -* The [`uglifyify`](https://github.com/hughsk/uglifyify) transform removes development imports. Make it global too (`-g`). -* Finally, the resulting bundle is piped to [`terser`](https://github.com/terser-js/terser) for mangling ([read why](https://github.com/hughsk/uglifyify#motivationusage)). +* [`envify`](https://github.com/hughsk/envify) 변환은 올바른 빌드 환경이 설정되도록 합니다. 또한 전역 (`-g`)으로 변환시킵니다. +* [`uglifyify`](https://github.com/hughsk/uglifyify) 변환은 개발에서만 사용하는 package를 제거합니다. 또한 전역(`-g`)으로 변환시킵니다. +* 마지막으로 최종 bundle은 mangling을 위해 [`terser`](https://github.com/terser-js/terser)로 연결됩니다. ([원리](https://github.com/hughsk/uglifyify#motivationusage)) -For example: +예시를 확인하세요. ``` browserify ./index.js \ @@ -96,25 +96,25 @@ browserify ./index.js \ | terser --compress --mangle > ./bundle.js ``` -Remember that you only need to do this for production builds. You shouldn't apply these plugins in development because they will hide useful React warnings, and make the builds much slower. +프로덕션 빌드에서만 필요한 작업이라는 점을 기억하세요. 이러한 플러그인은 React의 유용한 경고를 숨기고 빌드를 훨씬 느리게 만들기 때문에 개발 중에는 적용하지 마세요. ### Rollup {#rollup} -For the most efficient Rollup production build, install a few plugins: +가장 효율적인 Rollup 프로덕션 빌드를 위해 몇 가지 플러그인을 설치하세요. ```bash -# If you use npm +# npm을 사용하는 경우 npm install --save-dev rollup-plugin-commonjs rollup-plugin-replace rollup-plugin-terser -# If you use Yarn +# Yarn을 사용하는 경우 yarn add --dev rollup-plugin-commonjs rollup-plugin-replace rollup-plugin-terser ``` -To create a production build, make sure that you add these plugins **(the order matters)**: +프로덕션 빌드를 만들려면, 다음 플러그인을 추가하세요. **(순서는 중요합니다.)** -* The [`replace`](https://github.com/rollup/rollup-plugin-replace) plugin ensures the right build environment is set. -* The [`commonjs`](https://github.com/rollup/rollup-plugin-commonjs) plugin provides support for CommonJS in Rollup. -* The [`terser`](https://github.com/TrySound/rollup-plugin-terser) plugin compresses and mangles the final bundle. +* [`replace`](https://github.com/rollup/rollup-plugin-replace) 플러그인은 올바른 빌드 환경이 설정되도록 해줍니다. +* [`commonjs`](https://github.com/rollup/rollup-plugin-commonjs) 플러그인은 CommonJS를 지원하도록 해줍니다. +* [`terser`](https://github.com/TrySound/rollup-plugin-terser) 플러그인은 최종 bundle을 압축하고 mangle 해줍니다. ```js plugins: [ @@ -128,18 +128,18 @@ plugins: [ ] ``` -For a complete setup example [see this gist](https://gist.github.com/Rich-Harris/cb14f4bc0670c47d00d191565be36bf0). +전체적인 설정 예시는 [gist](https://gist.github.com/Rich-Harris/cb14f4bc0670c47d00d191565be36bf0)를 참고하세요. -Remember that you only need to do this for production builds. You shouldn't apply the `terser` plugin or the `replace` plugin with `'production'` value in development because they will hide useful React warnings, and make the builds much slower. +프로덕션 빌드에서만 필요한 작업이라는 점을 기억하세요. React의 유용한 경고를 숨기고 빌드를 훨씬 느리게 만들기 때문에 `terser` 플러그인이나 `replace` 플러그인을 개발 중에 `'production'` 값으로 적용하지 마세요. ### webpack {#webpack} ->**Note:** +>**주의** > ->If you're using Create React App, please follow [the instructions above](#create-react-app).
->This section is only relevant if you configure webpack directly. +>Create React App을 사용한다면 [위 설명](#create-react-app)을 참고하세요.
+>이 부분은 webpack을 직접 구성할 경우에만 해당합니다. -Webpack v4+ will minify your code by default in production mode. +Webpack v4 이상에서는 프로덕션 모드에서 기본적으로 코드를 축소합니다. ```js const TerserPlugin = require('terser-webpack-plugin'); @@ -152,84 +152,84 @@ module.exports = { }; ``` -You can learn more about this in [webpack documentation](https://webpack.js.org/guides/production/). +이 부분에 대해 더 알고 싶다면 [webpack 문서](https://webpack.js.org/guides/production/)를 참고하세요. -Remember that you only need to do this for production builds. You shouldn't apply `TerserPlugin` in development because it will hide useful React warnings, and make the builds much slower. +production 빌드에서만 필요한 작업이라는 점을 기억하세요. React의 유용한 경고를 숨기고 빌드를 훨씬 느리게 만들기 때문에 `TerserPlugin`을 개발 중에 적용하지 마세요. -## Profiling Components with the Chrome Performance Tab {#profiling-components-with-the-chrome-performance-tab} +## Chrome Performance 탭으로 컴포넌트 프로파일링 {#profiling-components-with-the-chrome-performance-tab} -In the **development** mode, you can visualize how components mount, update, and unmount, using the performance tools in supported browsers. For example: +**개발** 모드에서 지원되는 브라우저의 Performance 탭을 사용하여 어떻게 컴포넌트가 마운트, 업데이트, 그리고 마운트 해제되는지 시각화할 수 있습니다. 예를 들면.
React components in Chrome timeline
-To do this in Chrome: +Chrome에서 이 작업을 하려면 -1. Temporarily **disable all Chrome extensions, especially React DevTools**. They can significantly skew the results! +1. 일시적으로 **특히 React 개발 도구를 포함해 모든 Chrome 확장 프로그램을 비활성화하세요.** 결과가 크게 왜곡될 수 있습니다! -2. Make sure you're running the application in the development mode. +2. 개발 모드에서 애플리케이션을 실행 중인지 확인하세요. -3. Open the Chrome DevTools **[Performance](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/timeline-tool)** tab and press **Record**. +3. Chrome 개발 도구의 **[Performance](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/timeline-tool)** 탭을 열고 **Record**버튼을 클릭하세요. -4. Perform the actions you want to profile. Don't record more than 20 seconds or Chrome might hang. +4. 프로파일링할 작업을 진행하세요. 20초 이상 기록하지 마세요. 그렇지 않으면 Chrome이 멈출 수 있습니다. -5. Stop recording. +5. 기록을 멈추세요. -6. React events will be grouped under the **User Timing** label. +6. React 이벤트는 **User Timing** 라벨로 그룹화됩니다. -For a more detailed walkthrough, check out [this article by Ben Schwarz](https://calibreapp.com/blog/2017-11-28-debugging-react/). +더 자세한 사례를 보려면 [Ben Schwarz의 글](https://calibreapp.com/blog/2017-11-28-debugging-react/)을 확인하세요. -Note that **the numbers are relative so components will render faster in production**. Still, this should help you realize when unrelated UI gets updated by mistake, and how deep and how often your UI updates occur. +**수치는 상대적이어서 프로덕션 상태에서는 컴포넌트가 더 빠르게 렌더링 될 수 있다는 사실**을 기억하세요. 그래도 관계없는 UI가 실수에 의해 업데이트되는 현상과 UI 업데이트의 깊이와 빈도를 깨닫는 데 도움을 줄 것입니다. -Currently Chrome, Edge, and IE are the only browsers supporting this feature, but we use the standard [User Timing API](https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API) so we expect more browsers to add support for it. +현재는 Chrome, Edge 그리고 IE만이 이 기능을 지원하는 브라우저지만 [User Timing API](https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API)가 표준으로 사용되기 때문에 더 많은 브라우저가 지원을 추가할 것으로 예상됩니다. -## Profiling Components with the DevTools Profiler {#profiling-components-with-the-devtools-profiler} +## Profiler DevTools Profiler로 컴포넌트 프로파일링 {#profiling-components-with-the-devtools-profiler} -`react-dom` 16.5+ and `react-native` 0.57+ provide enhanced profiling capabilities in DEV mode with the React DevTools Profiler. -An overview of the Profiler can be found in the blog post ["Introducing the React Profiler"](/blog/2018/09/10/introducing-the-react-profiler.html). -A video walkthrough of the profiler is also [available on YouTube](https://www.youtube.com/watch?v=nySib7ipZdk). +`react-dom` 16.5+와 `react-native` 0.57+는 React DevTools Profiler를 사용하여 개발 모드에서 향상된 프로파일링 기능을 제공합니다. +Profiler에 대한 내용은 블로그 포스트 ["Introducing the React Profiler"](/blog/2018/09/10/introducing-the-react-profiler.html)에서 확인할 수 있습니다. +Profiler에 대한 영상도 [YouTube](https://www.youtube.com/watch?v=nySib7ipZdk)에서 확인 가능합니다. -If you haven't yet installed the React DevTools, you can find them here: +아직 React DevTools를 설치하지 않은 경우 다음 링크에서 확인하세요. - [Chrome Browser Extension](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en) - [Firefox Browser Extension](https://addons.mozilla.org/en-GB/firefox/addon/react-devtools/) - [Standalone Node Package](https://www.npmjs.com/package/react-devtools) -> Note +> 주의 > -> A production profiling bundle of `react-dom` is also available as `react-dom/profiling`. -> Read more about how to use this bundle at [fb.me/react-profiling](https://fb.me/react-profiling) +> `react-dom`의 프로덕션 프로파일링 bundle은 `react-dom/profiling`으로 이용할 수 있습니다. +> bundle을 사용하는 법에 대한 자세한 내용은 [fb.me/react-profiling](https://fb.me/react-profiling)에서 확인하세요. -## Virtualize Long Lists {#virtualize-long-lists} +## 긴 목록 가상화하세요 {#virtualize-long-lists} -If your application renders long lists of data (hundreds or thousands of rows), we recommended using a technique known as "windowing". This technique only renders a small subset of your rows at any given time, and can dramatically reduce the time it takes to re-render the components as well as the number of DOM nodes created. +애플리케이션에서 긴 목록(수백 또는 수천행)을 렌더링하는 경우 'windowing'이라는 기법을 사용하는 것을 추천합니다. 이 기법은 주어진 시간에 목록의 부분 목록만 렌더링하며 컴포넌트를 다시 렌더링하는 데 걸리는 시간과 생성된 DOM 노드의 수를 크게 줄일 수 있습니다. -[react-window](https://react-window.now.sh/) and [react-virtualized](https://bvaughn.github.io/react-virtualized/) are popular windowing libraries. They provide several reusable components for displaying lists, grids, and tabular data. You can also create your own windowing component, like [Twitter did](https://medium.com/@paularmstrong/twitter-lite-and-high-performance-react-progressive-web-apps-at-scale-d28a00e780a3), if you want something more tailored to your application's specific use case. +[react-window](https://react-window.now.sh/)와 [react-virtualized](https://bvaughn.github.io/react-virtualized/)는 널리 알려진 windowing 라이브러리입니다. 목록, 그리드 및 표 형식 데이터를 표시하기 위한 몇 가지 재사용 가능한 컴포넌트를 제공합니다. 애플리케이션의 특정한 활용 사례에 더 적합한 것을 원한다면 Twitter처럼 자신만의 windowing 컴포넌트를 만들 수 있습니다. -## Avoid Reconciliation {#avoid-reconciliation} +## 재조정을 피하세요 {#avoid-reconciliation} -React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a "virtual DOM", but it works the same way on React Native. +React는 렌더링 된 UI의 internal representation을 빌드하고 유지 관리합니다. 여기에는 컴포넌트에서 반환되는 React 엘리먼트가 포함됩니다. representation은 React가 JavaScript 객체에서의 작업보다 느릴 수 있기 때문에 필요에 따라 DOM 노드를 만들고 기존 노드에 접근하지 못하도록 합니다. 때론 "virtual DOM"이라고 불리기도 하지만, React Native에서 같은 방식으로 동작합니다. -When a component's props or state change, React decides whether an actual DOM update is necessary by comparing the newly returned element with the previously rendered one. When they are not equal, React will update the DOM. +컴포넌트의 prop이나 state가 변경되면 React는 새로 반환된 엘리먼트를 이전에 렌더링된 엘리먼트와 비교해서 실제 DOM 업데이트가 필요한지 여부를 결정합니다. 같지 않을 경우 React는 DOM을 업데이트합니다. -You can now visualize these re-renders of the virtual DOM with React DevTools: +React DevTools를 활용해 가상 DOM이 리렌더링되는 현상을 시각화할 수 있습니다. - [Chrome Browser Extension](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en) - [Firefox Browser Extension](https://addons.mozilla.org/en-GB/firefox/addon/react-devtools/) - [Standalone Node Package](https://www.npmjs.com/package/react-devtools) -In the developer console select the **Highlight Updates** option in the **React** tab: +개발자 콘솔의 **React** 탭에서 **Highlight Updates** 옵션을 선택하세요.
How to enable highlight updates
-Interact with your page and you should see colored borders momentarily appear around any components that have re-rendered. This lets you spot re-renders that were not necessary. You can learn more about this React DevTools feature from this [blog post](https://blog.logrocket.com/make-react-fast-again-part-3-highlighting-component-updates-6119e45e6833) from [Ben Edelstein](https://blog.logrocket.com/@edelstein). +페이지와 상호 작용하면서 리렌더링된 컴포넌트 주변 색 테두리가 순간적으로 나타나는 것을 볼 수 있습니다. 이렇게 하면 불필요한 리렌더링을 발견할 수 있습니다. 해당 React DevTools의 기능은 [Ben Edelstein](https://blog.logrocket.com/@edelstein)의 [블로그 포스트](https://blog.logrocket.com/make-react-fast-again-part-3-highlighting-component-updates-6119e45e6833)에서 확인할 수 있습니다. -Consider this example: +아래 예시를 살펴보세요.
React DevTools Highlight Updates example
-Note that when we're entering a second todo, the first todo also flashes on the screen on every keystroke. This means it is being re-rendered by React together with the input. This is sometimes called a "wasted" render. We know it is unnecessary because the first todo content has not changed, but React doesn't know this. +두 번째 할 일을 입력하면 모든 key 입력 시 첫 번째 할 일이 화면에서 깜박입니다. 이 현상은 React에 의해 input과 함께 다시 렌더링 된다는 것을 의미합니다. 이런 현상을 때론 "wasted" 렌더라고 부릅니다. 첫 번째 할 일의 내용이 변경되지 않았기 때문에 불필요한 렌더링이라는 것을 우리는 알지만 React는 모릅니다. -Even though React only updates the changed DOM nodes, re-rendering still takes some time. In many cases it's not a problem, but if the slowdown is noticeable, you can speed all of this up by overriding the lifecycle function `shouldComponentUpdate`, which is triggered before the re-rendering process starts. The default implementation of this function returns `true`, leaving React to perform the update: +React가 변경된 DOM 노드만 업데이트하더라도 리렌더링에는 여전히 다소 시간이 걸립니다. 대부분의 경우 문제가 되지 않지만 속도 저하가 눈에 띄는 경우 다시 렌더링이 시작되기 전에 실행되는 생명주기 함수 `shouldComponentUpdate`로 이 기능을 무시함으로써 속도를 높일 수 있습니다. 이 함수의 기본 implementation은 `true`를 반환하고 React는 업데이트를 진행합니다. ```javascript shouldComponentUpdate(nextProps, nextState) { @@ -237,27 +237,27 @@ shouldComponentUpdate(nextProps, nextState) { } ``` -If you know that in some situations your component doesn't need to update, you can return `false` from `shouldComponentUpdate` instead, to skip the whole rendering process, including calling `render()` on this component and below. +몇몇 상황에서 컴포넌트를 업데이트할 필요가 없다는 것을 알고 있다면 `shouldComponentUpdate`에서 `false`를 반환해서 컴포넌트와 그 자식 컴포넌트에서 `render()`를 호출하는 것을 포함해서 전체 렌더링 프로세스를 건너뛰게 할 수 있습니다. -In most cases, instead of writing `shouldComponentUpdate()` by hand, you can inherit from [`React.PureComponent`](/docs/react-api.html#reactpurecomponent). It is equivalent to implementing `shouldComponentUpdate()` with a shallow comparison of current and previous props and state. +대부분의 경우 `shouldComponentUpdate()`를 직접 작성하는 대신 [`React.PureComponent`](/docs/react-api.html#reactpurecomponent)에서 상속 받을 수 있습니다. 그것은 현재와 이전의 prop과 state의 얕은 비교로 `shouldComponentUpdate()`를 호출하는 것과 같습니다. ## shouldComponentUpdate In Action {#shouldcomponentupdate-in-action} -Here's a subtree of components. For each one, `SCU` indicates what `shouldComponentUpdate` returned, and `vDOMEq` indicates whether the rendered React elements were equivalent. Finally, the circle's color indicates whether the component had to be reconciled or not. +컴포넌트의 하위트리를 살펴보세요. 각 항목에 대해 `SCU`는 `shouldComponentUpdate`가 반환한 것을 나타내며, `vDOMEq`는 React 엘리먼트가 동일한지 여부를 표시합니다. 마지막으로 원의 색은 컴포넌트를 조정해야 하는지 여부를 나타냅니다.
-Since `shouldComponentUpdate` returned `false` for the subtree rooted at C2, React did not attempt to render C2, and thus didn't even have to invoke `shouldComponentUpdate` on C4 and C5. +`shouldComponentUpdate`는 C2에 뿌리를 둔 하위트리에서 `false`를 반환했기 때문에 React는 C2를 렌더링하려고 시도하지 않았으므로 C4 및 C5에서 `shouldComponentUpdate`를 호출할 필요가 없었습니다. -For C1 and C3, `shouldComponentUpdate` returned `true`, so React had to go down to the leaves and check them. For C6 `shouldComponentUpdate` returned `true`, and since the rendered elements weren't equivalent React had to update the DOM. +C1과 C3의 경우 `shouldComponentUpdate`가 `true`를 반환했으므로 React가 트리의 가장 하위에 가서 확인해야 했습니다. C6의 경우 `shouldComponentUpdate`는 `true`를 반환했고 렌더링 된 엘리먼트는 동일하지 않기 때문에 React는 DOM을 업데이트해야 했습니다. -The last interesting case is C8. React had to render this component, but since the React elements it returned were equal to the previously rendered ones, it didn't have to update the DOM. +마지막 흥미로운 경우는 C8입니다. React는 이 컴포넌트를 렌더링 해야 했지만 이전에 렌더링 된 React 엘리먼트와 동일했기 때문에 DOM을 업데이트할 필요가 없었습니다. -Note that React only had to do DOM mutations for C6, which was inevitable. For C8, it bailed out by comparing the rendered React elements, and for C2's subtree and C7, it didn't even have to compare the elements as we bailed out on `shouldComponentUpdate`, and `render` was not called. +React는 C6에 대해 DOM 변경(mutation)을 수행하면 되는데, 이는 불가피했습니다. C8의 경우 렌더링 된 React 엘리먼트를 비교해서 빠져(bail out)나오고 C2의 하위트리와 C7의 경우 `shouldComponentUpdate`를 구제할 때 엘리먼트를 비교할 필요조차 없었고 `render`도 호출되지 않았습니다. -## Examples {#examples} +## 예시 {#examples} -If the only way your component ever changes is when the `props.color` or the `state.count` variable changes, you could have `shouldComponentUpdate` check that: +컴포넌트가 변경되는 유일한 방법이 `props.color` 또는 `state.count`변수가 변경되는 경우라면 `shouldComponentUpdate`에서 다음을 확인하세요. ```javascript class CounterButton extends React.Component { @@ -288,7 +288,7 @@ class CounterButton extends React.Component { } ``` -In this code, `shouldComponentUpdate` is just checking if there is any change in `props.color` or `state.count`. If those values don't change, the component doesn't update. If your component got more complex, you could use a similar pattern of doing a "shallow comparison" between all the fields of `props` and `state` to determine if the component should update. This pattern is common enough that React provides a helper to use this logic - just inherit from `React.PureComponent`. So this code is a simpler way to achieve the same thing: +이 코드에서 `shouldComponentUpdate`는 `props.color` 또는 `state.count`에 변화가 있는지 확인합니다. 해당 값들이 변경되지 않으면 컴포넌트가 업데이트되지 않습니다. 컴포넌트가 더 복잡해지면 `props`와 `state`의 모든 필드 사이에 "얕은 비교"를 하는 것과 유사한 패턴을 사용해서 컴포넌트가 업데이트되어야만 하는지 여부를 결정할 수 있습니다. 이 패턴은 React가 `React.PureComponent`에서 단순히 상속받아 활용되는 이 로직을 사용하는 데 도움을 줄 만큼 일반적입니다. 따라서 이 코드는 동일한 효과를 얻을 수 있는 더 간단한 방법입니다. ```js class CounterButton extends React.PureComponent { @@ -309,9 +309,9 @@ class CounterButton extends React.PureComponent { } ``` -Most of the time, you can use `React.PureComponent` instead of writing your own `shouldComponentUpdate`. It only does a shallow comparison, so you can't use it if the props or state may have been mutated in a way that a shallow comparison would miss. +대부분의 경우 `shouldComponentUpdate`를 쓰는 대신 `React.PureComponent`를 사용할 수 있습니다. 얕은 비교만 수행하기 때문에 얕은 비교로는 지나칠 수 있는 방식으로 state나 props가 변화한다면 사용할 수 없습니다. -This can be a problem with more complex data structures. For example, let's say you want a `ListOfWords` component to render a comma-separated list of words, with a parent `WordAdder` component that lets you click a button to add a word to the list. This code does *not* work correctly: +이런 부분은 복잡한 데이터 구조인 경우 문제가 될 수 있습니다. 예를 들어 `listOfWords`라는 컴포넌트가 쉼표로 구분된 단어 목록을 렌더링하고 단어를 목록에 추가할 수 있는 버튼을 클릭하도록 해주는 상위의 `WordAdder` 컴포넌트를 사용한다고 가정을 해보겠습니다. 이 코드는 정상적으로 **작동하지 않습니다.** ```javascript class ListOfWords extends React.PureComponent { @@ -347,11 +347,11 @@ class WordAdder extends React.Component { } ``` -The problem is that `PureComponent` will do a simple comparison between the old and new values of `this.props.words`. Since this code mutates the `words` array in the `handleClick` method of `WordAdder`, the old and new values of `this.props.words` will compare as equal, even though the actual words in the array have changed. The `ListOfWords` will thus not update even though it has new words that should be rendered. +문제는 `PureComponent`가 `this.props.words`의 이전 값과 새로운 값을 간단하게 비교한다는 점입니다. 이 코드는 `WordAdder`의 `handleClick`메서드에서 `words`배열을 변경시키기 때문에 배열의 실제 단어가 변경되었다 하더라도 `this.props.words`의 이전 값과 새로운 값은 동일하게 비교됩니다. 따라서 `ListOfWords`는 렌더링 되어야 하는 새로운 단어가 있어도 업데이트되지 않습니다. -## The Power Of Not Mutating Data {#the-power-of-not-mutating-data} +## 데이터를 변형시키지 않음으로써 얻는 효과 {#the-power-of-not-mutating-data} -The simplest way to avoid this problem is to avoid mutating values that you are using as props or state. For example, the `handleClick` method above could be rewritten using `concat` as: +이 문제를 피하는 가장 간단한 방법은 props와 state로 사용중인 값의 변경을 피하는 것입니다. 예를 들어 `handleClick`메서드는 `concat`을 사용해서 다시 작성될 수 있습니다. ```javascript handleClick() { @@ -361,7 +361,7 @@ handleClick() { } ``` -ES6 supports a [spread syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator) for arrays which can make this easier. If you're using Create React App, this syntax is available by default. +ES6는 이런 동작을 쉽게 만들어주는 [spread syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator)를 배열에서 지원합니다. Create React App을 사용하고 있다면 이 문법은 기본적으로 사용할 수 있습니다. ```js handleClick() { @@ -371,7 +371,7 @@ handleClick() { }; ``` -You can also rewrite code that mutates objects to avoid mutation, in a similar way. For example, let's say we have an object named `colormap` and we want to write a function that changes `colormap.right` to be `'blue'`. We could write: +비슷한 방법으로 mutation을 피하기 위해 객체를 변경하는 코드를 다시 쓸 수 있습니다. 예를 들어 `colormap`이란 객체가 있고 `colormap.right`를 `'blue'`로 변경시키는 함수를 만들고 싶다고 가정해봅시다. 그렇다면 아래와 같이 작성할 수 있습니다. ```js function updateColorMap(colormap) { @@ -379,7 +379,7 @@ function updateColorMap(colormap) { } ``` -To write this without mutating the original object, we can use [Object.assign](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign) method: +객체 원본을 변경시키지 않고 작성하려면 [Object.assign](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Object/assign)메서드를 사용하세요. ```js function updateColorMap(colormap) { @@ -387,9 +387,9 @@ function updateColorMap(colormap) { } ``` -`updateColorMap` now returns a new object, rather than mutating the old one. `Object.assign` is in ES6 and requires a polyfill. +`updateColorMap`은 기존 객체를 변경하지않고 새로운 객체를 반환합니다. `Object.assign`은 ES6의 문법이고 폴리필(polyfill)을 필요로합니다. -There is a JavaScript proposal to add [object spread properties](https://github.com/sebmarkbage/ecmascript-rest-spread) to make it easier to update objects without mutation as well: +객체 또한 변경 없이 손쉽게 업데이트될 수 있도록 [object spread properties](https://github.com/sebmarkbage/ecmascript-rest-spread)를 추가하자는 JavaScript 제안이 있습니다. ```js function updateColorMap(colormap) { @@ -397,17 +397,17 @@ function updateColorMap(colormap) { } ``` -If you're using Create React App, both `Object.assign` and the object spread syntax are available by default. +Create React App을 사용하고 있다면 `Object.assign`과 object spread 문법은 기본적으로 활용 가능합니다. -## Using Immutable Data Structures {#using-immutable-data-structures} +## 불변의 데이터 구조 사용 {#using-immutable-data-structures} -[Immutable.js](https://github.com/facebook/immutable-js) is another way to solve this problem. It provides immutable, persistent collections that work via structural sharing: +[Immutable.js](https://github.com/facebook/immutable-js)는 이 문제를 해결할 수 있는 또 다른 방법입니다. 구조적 공유(Structural sharing)를 통해 작동되는 지속성과 불변성을 지닌 컬렉션을 제공합니다. -* *Immutable*: once created, a collection cannot be altered at another point in time. -* *Persistent*: new collections can be created from a previous collection and a mutation such as set. The original collection is still valid after the new collection is created. -* *Structural Sharing*: new collections are created using as much of the same structure as the original collection as possible, reducing copying to a minimum to improve performance. +* *불변성*: 일단 생성되면 컬렉션은 다른 시점에서 변경될 수 없습니다. +* *지속성*: 새로운 컬렉션은 이전 컬렉션과 set과 같은 변화로부터 생성될 수 있습니다. 기존의 컬렉션은 새 컬렉션이 만들어지고 나서도 유효합니다. +* *구조적 공유(Structural Sharing)*: 가능한 한 원본의 컬렉션과 동일한 구조를 사용해서 새 컬렉션이 만들어지므로 복사를 최소화해서 성능을 향상시킵니다. -Immutability makes tracking changes cheap. A change will always result in a new object so we only need to check if the reference to the object has changed. For example, in this regular JavaScript code: +불변성은 변화를 추적하는 비용을 적게 만듭니다. 변경은 항상 새로운 객체를 생성하므로 객체에 대한 참조가 변경되었는지 여부만 확인하면 됩니다. 예를 들어 일반적인 JavaScript 코드에서는 아래와 같습니다. ```javascript const x = { foo: 'bar' }; @@ -416,7 +416,7 @@ y.foo = 'baz'; x === y; // true ``` -Although `y` was edited, since it's a reference to the same object as `x`, this comparison returns `true`. You can write similar code with immutable.js: +`y`는 수정되었지만 `x`와 동일한 객체에 대한 참조이기 때문에 `true`를 반환합니다. immutable.js로 비슷한 코드를 작성할 수 있습니다. ```javascript const SomeRecord = Immutable.Record({ foo: null }); @@ -427,8 +427,8 @@ x === y; // false x === z; // true ``` -In this case, since a new reference is returned when mutating `x`, we can use a reference equality check `(x === y)` to verify that the new value stored in `y` is different than the original value stored in `x`. +이 경우에는 `x`를 변경할 때 새로운 참조가 반환되기 때문에 `y`에 저장된 새로운 값이 저장된 원래 값과 다른지 확인하기 위해 참조가 동일한지 여부를 판단하는 확인하는 코드`(x===y)`를 사용할 수 있습니다. -Other libraries that can help use immutable data include [Immer](https://github.com/mweststrate/immer), [immutability-helper](https://github.com/kolodny/immutability-helper), and [seamless-immutable](https://github.com/rtfeldman/seamless-immutable). +불변성을 가지는 데이터를 사용할 수 있도록 하는 두 개의 라이브러리는 [seamless-immutable](https://github.com/rtfeldman/seamless-immutable)와 [immutability-helper](https://github.com/kolodny/immutability-helper)입니다. -Immutable data structures provide you with a cheap way to track changes on objects, which is all we need to implement `shouldComponentUpdate`. This can often provide you with a nice performance boost. +불변성을 가지는 데이터 구조는 객체의 변경을 추적하는 적은 비용의 방법을 제공합니다. 이는 `shouldComponentUpdate`를 적용하는데 필요한 모든 것입니다. 이 방법은 좋은 성능 향상을 제공할 수 있습니다.