diff --git a/content/docs/reconciliation.md b/content/docs/reconciliation.md index 1624bfbde..5a1ace34f 100644 --- a/content/docs/reconciliation.md +++ b/content/docs/reconciliation.md @@ -1,35 +1,35 @@ --- id: reconciliation -title: Reconciliation +title: 재조정 (Reconciliation) permalink: docs/reconciliation.html --- -React provides a declarative API so that you don't have to worry about exactly what changes on every update. This makes writing applications a lot easier, but it might not be obvious how this is implemented within React. This article explains the choices we made in React's "diffing" algorithm so that component updates are predictable while being fast enough for high-performance apps. +React는 선언적 API를 제공하기 때문에 갱신이 될 때마다 매번 무엇이 바뀌었는지를 걱정할 필요가 없습니다. 이는 애플리케이션 작성을 무척 쉽게 만들어주지만, React 내부에서 어떤 일이 일어나고 있는지는 명확히 눈에 보이지 않습니다. 이 글에서는 우리가 React의 “비교 (diffing)” 알고리즘을 만들 때 어떤 선택을 했는지를 소개합니다. 이 비교 알고리즘 덕분에 컴포넌트의 갱신이 예측 가능해지면서도 고성능 앱이라고 불러도 손색없을 만큼 충분히 빠른 앱을 만들 수 있습니다. -## Motivation {#motivation} +## 동기 {#motivation} -When you use React, at a single point in time you can think of the `render()` function as creating a tree of React elements. On the next state or props update, that `render()` function will return a different tree of React elements. React then needs to figure out how to efficiently update the UI to match the most recent tree. +React를 사용하다 보면, '`render()` 함수는 React 엘리먼트 트리를 만드는 것이다.'라고 생각이 드는 순간이 있을 것입니다. state나 props가 갱신되면 `render()` 함수는 새로운 React 엘리먼트 트리를 반환할 것입니다. 이때 React는 방금 만들어진 트리에 맞게 가장 효과적으로 UI를 갱신하는 방법을 알아낼 필요가 있습니다. -There are some generic solutions to this algorithmic problem of generating the minimum number of operations to transform one tree into another. However, the [state of the art algorithms](https://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_bille.pdf) have a complexity in the order of O(n3) where n is the number of elements in the tree. +하나의 트리를 가지고 다른 트리로 변환하기 위한 최소한의 연산 수를 구하는 알고리즘 문제를 풀기 위한 일반적인 해결책들이 있습니다. 하지만 [이러한 최첨단의 알고리즘](https://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_bille.pdf)도 n개의 엘리먼트가 있는 트리에 대해 O(n3)의 복잡도를 가집니다. -If we used this in React, displaying 1000 elements would require in the order of one billion comparisons. This is far too expensive. Instead, React implements a heuristic O(n) algorithm based on two assumptions: +React에 이 알고리즘을 적용한다면, 1000개의 엘리먼트를 그리기 위해 10억 번의 비교 연산을 수행해야 합니다. 너무나도 비싼 연산이죠. React는 대신, 두 가지 가정을 기반하여 O(n) 복잡도의 휴리스틱 알고리즘을 구현했습니다. -1. Two elements of different types will produce different trees. -2. The developer can hint at which child elements may be stable across different renders with a `key` prop. +1. 서로 다른 타입의 두 엘리먼트는 서로 다른 트리를 만들어낸다. +2. 개발자가 `key` prop을 통해, 여러 렌더링 사이에서 어떤 자식 엘리먼트가 변경되지 않아야 할지 표시해 줄 수 있다. -In practice, these assumptions are valid for almost all practical use cases. +실제로 거의 모든 사용 사례에서 이 가정들은 들어맞습니다. -## The Diffing Algorithm {#the-diffing-algorithm} +## 비교 알고리즘 (Diffing Algorithm) {#the-diffing-algorithm} -When diffing two trees, React first compares the two root elements. The behavior is different depending on the types of the root elements. +두 개의 트리를 비교할 때, React는 두 엘리먼트의 루트(root) 엘리먼트부터 비교합니다. 이후의 동작은 루트 엘리먼트의 타입에 따라 달라집니다. -### Elements Of Different Types {#elements-of-different-types} +### 엘리먼트의 타입이 다른 경우 {#elements-of-different-types} -Whenever the root elements have different types, React will tear down the old tree and build the new tree from scratch. Going from `` to ``, or from `
` to ``, or from `