Apply review feedbacks

Author: hewonjeong

content/docs/reconciliation.md

@@ -8,7 +8,7 @@ React는 선언적 API를 제공하기 때문에 갱신이 될 때마다 매번
 
 ## 동기 {#motivation}
 
-React를 사용하다 보면, '`render()` 함수는 React 엘리먼트 트리를 만드는 것이다'라고 생각이 드는 순간이 있을 것입니다. state나 props가 갱신되면 `render()` 함수는 새로운 React 엘리먼트 트리를 반환할 것입니다. 이때 React는 방금 만들어진 트리에 맞게 가장 효과적으로 UI를 갱신하는 방법을 알아낼 필요가 있습니다.
+React를 사용하다 보면, '`render()` 함수는 React 엘리먼트 트리를 만드는 것이다.'라고 생각이 드는 순간이 있을 것입니다. state나 props가 갱신되면 `render()` 함수는 새로운 React 엘리먼트 트리를 반환할 것입니다. 이때 React는 방금 만들어진 트리에 맞게 가장 효과적으로 UI를 갱신하는 방법을 알아낼 필요가 있습니다.
 
 하나의 트리를 가지고 다른 트리로 변환하기 위한 최소한의 연산 수를 구하는 알고리즘 문제를 풀기 위한 일반적인 해결책들이 있습니다. 하지만 [이러한 최첨단의 알고리즘](https://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_bille.pdf)도 n개의 엘리먼트가 있는 트리에 대해 O(n<sup>3</sup>)의 복잡도를 가집니다.
 
@@ -53,7 +53,7 @@ React에 이 알고리즘을 적용한다면, 1000개의 엘리먼트를 그리
 <div className="after" title="stuff" />
 ```
 
-이 두 엘리먼트를 비교하면, React는 현재 DOM node 상에 `className`만 수정합니다.
+이 두 엘리먼트를 비교하면, React는 현재 DOM 노드 상에 `className`만 수정합니다.
 
 `style`이 갱신될 때, React는 또한 변경된 속성만을 갱신합니다. 예를 들어,
 
@@ -92,7 +92,7 @@ DOM 노드의 자식들을 재귀적으로 처리할 때, React는 기본적으
 </ul>
 ```
 
-React는 두 트리의 `<li>first</li>`가 일치하는 것을 확인하고, `<li>second</li>`가 일치하는 것을 확인하고, 마지막으로 `<li>third</li>`를 트리에 추가합니다.
+React는 두 트리에서 `<li>first</li>`가 일치하는 것을 확인하고, `<li>second</li>`가 일치하는 것을 확인합니다. 그리고 마지막으로 <li>third</li>를 트리에 추가합니다.
 
 하지만 위와 같이 단순하게 구현하면, 리스트의 맨 앞에 엘리먼트를 추가하는 경우 성능이 좋지 않습니다. 예를 들어, 아래의 두 트리 변환은 형편없이 작동합니다.
 
@@ -130,7 +130,7 @@ React는 `<li>Duke</li>`와 `<li>Villanova</li>` 종속 트리를 그대로 유
 
 이제 React는 `'2014'` key를 가진 엘리먼트가 새로 추가되었고, `'2015'`와 `'2016'` key를 가진 엘리먼트는 그저 이동만 하면 되는 것을 알 수 있습니다.
 
-실제로, 키로 사용할 값을 정하는 것은 어렵지 않습니다. 일반적으로 그리려고 하는 엘리먼트는 일반적으로 식별자를 가지고 있을 것이고, 그대로 해당 데이터를 key로 사용할 수 있습니다:
+실제로, key로 사용할 값을 정하는 것은 어렵지 않습니다. 그리려고 하는 엘리먼트는 일반적으로 식별자를 가지고 있을 것이고, 그대로 해당 데이터를 key로 사용할 수 있습니다.
 
 ```js
 <li key={item.id}>{item.name}</li>
@@ -140,9 +140,9 @@ React는 `<li>Duke</li>`와 `<li>Villanova</li>` 종속 트리를 그대로 유
 
 최후의 수단으로 배열의 인덱스를 key로 사용할 수 있습니다. 만약 항목들이 재배열되지 않는다면 이 방법도 잘 동작할 것이지만, 재배열되는 경우 비효율적으로 동작할 것입니다.
 
-인덱스를 키로 사용 중 배열이 재배열되면 컴포넌트의 state와 관련된 문제가 발생할 수 있습니다. 컴포넌트 인스턴스는 키를 기반으로 갱신되고 재사용됩니다. 인덱스를 키로 사용하면, 항목의 순서가 바뀌었을 때 key 또한 바뀔 것입니다. 그 결과로, 컴포넌트의 state가 엉망이 되거나 의도하지 않은 방식으로 바뀔 수도 있습니다.
+인덱스를 key로 사용 중 배열이 재배열되면 컴포넌트의 state와 관련된 문제가 발생할 수 있습니다. 컴포넌트 인스턴스는 key를 기반으로 갱신되고 재사용됩니다. 인덱스를 key로 사용하면, 항목의 순서가 바뀌었을 때 key 또한 바뀔 것입니다. 그 결과로, 컴포넌트의 state가 엉망이 되거나 의도하지 않은 방식으로 바뀔 수도 있습니다.
 
-[여기](codepen://reconciliation/index-used-as-key) 인덱스를 key로 사용하여 문제가 발생하는 Codepen 예시가 있습니다. 그리고 [여기](codepen://reconciliation/no-index-used-as-key) 같은 내용을 가지고 개선한 예시에서는 인덱스를 key로 사용하지 않으면서도 앞에서 다뤘던 재배열, 정렬 그리고 이어서 발생하는 문제들을 어떻게 해결하는지 확인할 수 있습니다.
+인덱스를 key로 사용하여 문제가 발생하는 Codepen 예시는 [여기](codepen://reconciliation/index-used-as-key)에 있습니다. 그리고 개선한 예시에서는 인덱스를 key로 사용하지 않으면서도 앞에서 다뤘던 재배열, 정렬 그리고 이어서 발생하는 문제들을 어떻게 해결하는지 [여기](codepen://reconciliation/no-index-used-as-key)에서 확인할 수 있습니다
 
 ## 고려 사항 {#tradeoffs}
 
@@ -155,4 +155,4 @@ React는 휴리스틱에 의존하고 있기 때문에, 휴리스틱이 기반
 
 1. 알고리즘은 다른 컴포넌트 타입을 갖는 종속 트리들의 일치 여부를 확인하지 않습니다. 만약 매우 비슷한 결과물을 출력하는 두 컴포넌트를 교체하고 있다면, 그 둘을 같은 타입으로 만드는 것이 더 나을 수도 있습니다. 우리는 실제 사용 사례에서 이 가정이 문제가 되는 경우를 발견하지 못했습니다.
 
-2. Key는 반드시 변하지 않고, 예상 가능하며, 유일해야 합니다. 변하는 key(`Math.random()`으로 생성된 값 등)를 사용하면 많은 컴포넌트 인스턴스와 DOM 노드를 불필요하게 재생성하여 성능이 나빠지거나  자식 컴포넌트의 state가 유실될 수 있습니다.
+2. key는 반드시 변하지 않고, 예상 가능하며, 유일해야 합니다. 변하는 key(`Math.random()`으로 생성된 값 등)를 사용하면 많은 컴포넌트 인스턴스와 DOM 노드를 불필요하게 재생성하여 성능이 나빠지거나  자식 컴포넌트의 state가 유실될 수 있습니다.