{"patch":"diff --git a\/docs\/docs\/11-advanced-performance.ko-KR.md b\/docs\/docs\/11-advanced-performance.ko-KR.md\nnew file mode 100644\nindex 0000000000..ab355b9213\n--- \/dev\/null\n+++ b\/docs\/docs\/11-advanced-performance.ko-KR.md\n@@ -0,0 +1,205 @@\n+---\n+id: advanced-performance-ko-KR\n+title: 성능 심화\n+permalink: advanced-performance-ko-KR.html\n+prev: perf-ko-KR.html\n+---\n+\n+React를 도입하려 할 때 많은 사람이 묻는 첫 번째 질문은 React를 사용하지 않을 때처럼 애플리케이션이 빠르고 반응성도 좋을 것이냐는 것입니다. 모든 상태변화에 대해 컴포넌트의 하위 트리를 전부 다시 렌더링하는 아이디어에 대해 사람들은 이 프로세스가 성능에 부정적인 영향을 줄 것으로 생각하지만, React는 여러 가지 영리한 방법을 통해 UI를 업데이트하는데 필요한 비싼 DOM 조작을 최소화합니다.\n+\n+## DOM 조정 회피\n+\n+React는 브라우저에서 렌더된 DOM 하위 트리의 서술자 개념인 *가상의 DOM*을 사용합니다. 이 병렬적인 서술체는 React가 DOM 노드를 생성하거나 이미 존재하는 DOM 노드에 접근하는 것(JavaScript 객체를 조작하는 것보다 느리죠)을 피하게 해 줍니다. 컴포넌트의 props나 state가 변경되면 React는 새로운 가상의 DOM을 구성해 이전의 것과 비교해서 실제 DOM 업데이트가 필요한지 결정합니다. 가능한 적게 변화를 적용하기 위해, React는 둘이 다를 경우에만 DOM을 [조정](\/react\/docs\/reconciliation-ko-KR.html)할 것입니다.\n+\n+이에 더해, React는 컴포넌트 생명주기 함수인 `shouldComponentUpdate`를 제공합니다. 이는 다시 렌더링하는 프로세스가 일어나기 직전에 일어나며 개발자가 프로세스를 중단할 수 있게 합니다. 이 함수의 기본구현은 `true`를 반환해 React가 업데이트를 수행하도록 합니다.\n+\n+```javascript\n+shouldComponentUpdate: function(nextProps, nextState) {\n+ return true;\n+}\n+```\n+\n+React가 이 함수를 자주 호출한다는 것을 명심하십시오. 따라서 구현체는 빨라야 합니다. \n+\n+대화 스레드가 여럿 돌고 있는 메시지처리 애플리케이션을 생각해 봅시다. 오직 하나의 스레드만이 변경되었다고 가정해 보죠. `ChatThread`에 `shouldComponentUpdate`를 구현했다면 React는 다른 스레드의 렌더링 프로세스를 건너뛸 수 있습니다. \n+\n+```javascript\n+shouldComponentUpdate: function(nextProps, nextState) {\n+ \/\/ TODO: 현재의 대화 스레드가 이전의 것과 다른지 아닌지를 반환한다\n+}\n+```\n+\n+정리하자면, React는 사용자가 `shouldComponentUpdate`를 사용해 렌더링 프로세스를 중단하고 가상의 DOM과 비교해 업데이트 여부를 결정해서 DOM의 하위 트리를 조정하는 비싼 DOM 조작을 피하도록 합니다. \n+\n+## shouldComponentUpdate 실전\n+\n+다음은 컴포넌트의 하위 트리입니다. 각각은 `shouldComponentUpdate`의 반환값(SCU)과 가상의 DOM과의 동일성(vDOMEq)을 표시합니다. 마지막으로, 원의 색은 컴포넌트가 조정되었는지를 표시합니다.\n+\n+

dillon1000/react

Files changed