Update thinking-in-react.md

content/docs/thinking-in-react.md

@@ -41,15 +41,15 @@ JSON API는 아래와 같은 데이터를 반환합니다.
 
 ![Component diagram](../images/blog/thinking-in-react-components.png)
 
-다섯개의 컴포넌트로 이루어진 간단한 앱을 한번 봅시다. 각각의 컴포넌트에 들어간 데이터는 이탤릭체로 표현했습니다.
+다섯개의 컴포넌트로 이루어진 간단한 앱을 한번 봅시다. 각각의 컴포넌트에 들어간 데이터는 이탤릭체로 표기했습니다.
 
   1. **`FilterableProductTable`(노란색)**: 예시 전체를 포괄합니다.
   2. **`SearchBar`(파란색)**: 모든 *유저의 입력(user input)* 을 받습니다.
   3. **`ProductTable`(연두색)**: *유저의 입력(user input)*을 기반으로 *데이터 콜렉션(data collection)*을 필터링 해서 보여줍니다.
   4. **`ProductCategoryRow`(하늘색)**: 각 *카테고리(category)*의 헤더를 보여줍니다.
   5. **`ProductRow`(빨강색)**: 각각의 *제품(product)*에 해당하는 행을 보여줍니다.
 
-`ProductTable`을 보면 “Name” 과 “Price” 레이블을 포함한 테이블 헤더만을 가진 컴포넌트는 없습니다. 이와 같은 경우, 데이터를 위한 독립된 컴포넌트를 생성할지 생성하지 않을지는 선택입니다. 이 예시에서는 `ProductTable`의 책임인 *데이터 컬렉션(data collection)*이 렌더링의 일부이기 때문에 `ProductTable`을 남겨두었습니다. 그러나 이 헤더가 복잡해지면 (즉 정렬을 위한 기능을 추가하는 등) `ProductTableHeader`컴포넌트를 만드는 것이 더 합리적일 것입니다.
+`ProductTable`을 보면 “Name” 과 “Price” 레이블을 포함한 테이블 헤더만을 가진 컴포넌트는 없습니다. 이 같은 경우, 데이터를 위한 독립된 컴포넌트를 생성할지 생성하지 않을지는 선택입니다. 이 예시에서는 `ProductTable`의 책임인 *데이터 컬렉션(data collection)*이 렌더링의 일부이기 때문에 `ProductTable`을 남겨두었습니다. 그러나 이 헤더가 복잡해지면 (즉 정렬을 위한 기능을 추가하는 등) `ProductTableHeader`컴포넌트를 만드는 것이 더 합리적일 것입니다.
 
 이제 목업에서 컴포넌트를 확인하였으므로 이를 계층 구조로 나열해봅시다. 이 작업은 쉽습니다. 모형의 다른 컴포넌트 내부에 나타나는 컴포넌트는 계층 구조의 자식으로 나타냅니다.
 
@@ -84,7 +84,7 @@ UI를 상호작용하게 만들려면 기반 데이터 모델을 변경할 수 
 
 애플리케이션을 올바르게 만들기 위해서는 애플리케이션에서 필요로 하는 변경 가능한 state의 최소 집합을 생각해보아야 합니다. 여기서 핵심은 [중복배제](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)원칙입니다. 애플리케이션이 필요로 하는 가장 최소한의 state를 찾고 이를 통해 나머지 모든 것들이 필요에 따라 그때그때 계산되도록 만드세요. 예를 들어 TODO 리스트를 만든다고 하면, TODO 아이템을 저장하는 배열만 유지하고 TODO 아이템의 개수를 표현하는 state를 별도로 만들지 마세요. TODO 갯수를 렌더링해야한다면 TODO 아이템 배열의 길이를 가져오면 됩니다.
 
-예시 애플리케이션 내 데이터들을 생각해봅시다. 우리는 현재,
+예시 애플리케이션 내 데이터들을 생각해봅시다. 애플리케이션은 다음과 같은 데이터를 가지고 있습니다. 
 
   * 제품의 원본 목록
   * 유저가 입력한 검색어
@@ -99,7 +99,7 @@ UI를 상호작용하게 만들려면 기반 데이터 모델을 변경할 수 
 
 제품의 원본 목록은 props를 통해 전달되므로 state가 아닙니다. 검색어와 체크박스는 state로 볼 수 있는데 시간이 지남에 따라 변하기도 하면서 다른 것들로부터 계산될 수 없기 때문입니다. 그리고 마지막으로 필터링된 목록은 state가 아닙니다. 제품의 원본 목록과 검색어, 체크박스의 값을 조합해서 계산해낼 수 있기 때문입니다.
 
-결과적으로 state는
+결과적으로 애플리케이션은 다음과 같은 state를 가집니다.
 
   * 유저가 입력한 검색어
   * 체크박스의 값
@@ -116,7 +116,7 @@ UI를 상호작용하게 만들려면 기반 데이터 모델을 변경할 수 
 
   * state를 기반으로 렌더링하는 모든 컴포넌트를 찾으세요.
   * 공통 소유 컴포넌트 (common owner component)를 찾으세요. (계층 구조 내에서 특정 state가 있어야 하는 모든 컴포넌트들의 상위에 있는 하나의 컴포넌트).
-  * 공통  혹은 더 상위에 있는 컴포넌트가 state를 가져야 합니다.
+  * 공통 혹은 더 상위에 있는 컴포넌트가 state를 가져야 합니다.
   * state를 소유할 적절한 컴포넌트를 찾지 못하였다면, 단순히 state를 소유하는 컴포넌트를 하나 만들어서 공통 오너 컴포넌트의 상위 계층에 추가하세요.
 
 이 전략을 애플리케이션에 적용해봅시다.
@@ -141,7 +141,7 @@ React는 전통적인 양방향 데이터 바인딩(two-way data binding)과 비
 
 우리가 원하는 것이 무엇인지를 한번 생각해봅시다. 우리는 사용자가 폼을 변경할 때마다 사용자의 입력을 반영할 수 있도록 state를 업데이트하기를 원합니다. 컴포넌트는 그 자신의 state만 변경할 수 있기 때문에 `FilterableProductTable`는 `SearchBar`에 콜백을 넘겨서 state가 업데이트되어야 할 때마다 호출되도록 할 것입니다. 우리는 input에 onChange 이벤트를 사용해서 알림을 받을 수 있습니다. `FilterableProductTable`에서 전달된 콜백은 `setState()`를 호출하고 앱이 업데이트될 것입니다.
 
-복잡해 보이지만 코드에선 몇줄밖에 안됩니다. 그리고 이를 통해 앱 전체적으로 데이터가 흐르는 모습을 명시적으로 볼 수 있습니다.
+복잡해 보이지만 코드에선 몇줄밖에 안 됩니다. 그리고 이를 통해 앱 전체적으로 데이터가 흐르는 모습을 명시적으로 볼 수 있습니다.
 
 ## 이게 전부입니다. {#and-thats-it}