Translation for thinking in react #77

yesjin-git · 2019-03-24T07:49:07Z

스타일 가이드와 모범사례 확인, 용어 확인 후 맞춤법 검사까지 진행했습니다. 혹시 부족한 점이 있으면 말씀해 주세요.

참고 : 중간에 원칙들에 대한 설명으로 wiki page로 연결이 되는 부분이 있는데, 단일 책임 원칙은 한글 wiki 문서가 잘 돼 있어 한글 페이지로 이동하도록 바꾸었고, 중복 배제 원칙의 경우 한글wiki 문서가 부족해 영문 페이지로 이동하게 했습니다.

Progress

번역 초안 작성 (Draft translation)
공통 스타일 가이드 확인 (Check the common style guide)
모범사례 확인 (Check best practices)
용어 확인 (Check the term)
맞춤법 검사 (Spelling check)
리뷰 반영 (Resolve reviews)

netlify · 2019-03-24T07:54:17Z

Deploy preview for ko-reactjs-org ready!

Built with commit 8585063

https://deploy-preview-77--ko-reactjs-org.netlify.com

content/docs/thinking-in-react.md

hg-pyun

Need one more review.

taehwanno · 2019-04-04T07:48:54Z

content/docs/thinking-in-react.md

-Hopefully, this gives you an idea of how to think about building components and applications with React. While it may be a little more typing than you're used to, remember that code is read far more than it's written, and it's extremely easy to read this modular, explicit code. As you start to build large libraries of components, you'll appreciate this explicitness and modularity, and with code reuse, your lines of code will start to shrink. :)
+---
+id: thinking-in-react
+title: React처럼 사고하기


네비게이션 번역과 관련된 #84 에서는 React로 생각하기로 번역했는데 어떤게 더 나을까요?

리액트로 생각하기가 더 좋은 것 같습니다.

taehwanno · 2019-04-04T07:49:16Z

content/docs/thinking-in-react.md

+prev: composition-vs-inheritance.html
+---
+
+React 는 JavaScript로 규모가 크고 빠른 웹 애플리케이션을 만드는 가장 좋은 방법입니다. React는 Facebook과 Instagram을 통해 확장성을 입증했습니다.


React 는 -> React는

반영했습니다.

taehwanno · 2019-04-04T07:49:37Z

content/docs/thinking-in-react.md

+
+React 는 JavaScript로 규모가 크고 빠른 웹 애플리케이션을 만드는 가장 좋은 방법입니다. React는 Facebook과 Instagram을 통해 확장성을 입증했습니다.
+
+React의 가장 멋진 점 중 하나는 앱을 설계하는 방식입니다. 이 문서를 통해 리액트로 상품들을 검색할 수 있는 데이터 테이블을 만드는 과정을 함께 생각해 봅시다.


리액트 -> React 고유명사는 그대로 나둬주세요 :)

반영했습니다.

taehwanno · 2019-04-04T07:52:43Z

content/docs/thinking-in-react.md

+
+## 1단계: UI를 컴포넌트 계층 구조로 나누기 {#step-1-break-the-ui-into-a-component-hierarchy} 
+
+우리가 할 첫 번째 일은 모든 컴포넌트(와 하위 컴포넌트)의 주변에 박스를 그리고 그 각각에 이름을 붙이는 것입니다. 만약 디자이너와 함께 일한다면, 이것들을 이미 정해두었을 수 있으니 한번 대화해보세요! 디자이너의 Photoshop 레이어 이름이 React 컴포넌트의 이름이 될 수 있습니다.


만약은 일한다면으로 인해 삭제해도 될 것 같아요!

반영했습니다.

taehwanno · 2019-04-04T07:53:30Z

content/docs/thinking-in-react.md

+
+우리가 할 첫 번째 일은 모든 컴포넌트(와 하위 컴포넌트)의 주변에 박스를 그리고 그 각각에 이름을 붙이는 것입니다. 만약 디자이너와 함께 일한다면, 이것들을 이미 정해두었을 수 있으니 한번 대화해보세요! 디자이너의 Photoshop 레이어 이름이 React 컴포넌트의 이름이 될 수 있습니다.
+
+하지만 어떤 것이 컴포넌트가 되어야 할지 어떻게 알 수 있을까요? 우리가 새로운 함수나 객체를 만들 때처럼 만드시면 됩니다. 한 가지 테크닉은 [단일 책임 원칙](https://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%B1%85%EC%9E%84_%EC%9B%90%EC%B9%99)입니다. 이는 하나의 컴포넌트는 한 가지 일을 하는게 이상적이라는 원칙입니다. 만약 하나의 컴포넌트가 커지게 된다면 이는 보다 작은 하위 컴포넌트로 분리되어야 합니다.


만약 삭제 부탁드려요!

반영했습니다.

taehwanno · 2019-04-04T09:09:18Z

content/docs/thinking-in-react.md

+
+## 2단계: React로 정적인 버전 만들기 {#step-2-build-a-static-version-in-react}
+
+<p data-height="600" data-theme-id="0" data-slug-hash="BwWzwm" data-default-tab="js" data-user="lacker" data-embed-versi기n="2" class="codepen"><a href="https://codepen.io">CodePen</a>에서<a href="https://codepen.io/gaearon/pen/BwWzwm">Thinking In React: Step 2</a>를 살펴보세요.</p>


versi기n -> version

에서 -> 에서 (끝에 공백 추가가 필요해요)

반영했습니다.

taehwanno · 2019-04-04T15:11:33Z

content/docs/thinking-in-react.md

+
+이 단계가 끝나면 데이터 렌더링을 위해 만들어진 재사용 가능한 컴포넌트들의 라이브러리를 가지게 됩니다. 현재는 앱의 정적 버전이기 때문에 컴포넌트는 `render()` 메서드만 가지고 있을 것입니다. 계층구조의 최상단 컴포넌트 (`FilterableProductTable`)는 prop으로 데이터 모델을 받습니다. 데이터 모델이 변경되면  `ReactDOM.render()`를 다시 호출하서 UI가 업데이트 됩니다. 지금 단계서 어떻게 UI가 업데이트되는지 확인하는 일은 어렵지 않은데 지금은 크게 복잡한 부분이 없기 때문입니다. React의 **단방향 데이터 흐름(one-way data flow)** (또는 *단방향 바인딩(one-way binding*))는 모든 것을 모듈화 하고 빠르게 만들어줍니다.
+
+이 단계를 실행하는데 어려움이 있다면 [공식 리액트 문서](/docs/)를 참고하세요.


공식 리액트 문서 -> 공식 React 문서

반영했습니다.

content/docs/thinking-in-react.md

taehwanno · 2019-04-04T15:15:04Z

content/docs/thinking-in-react.md

+애플리케이션이 가지는 각각의 state에 대해서
+
+  * state를 기반으로 렌더링하는 모든 컴포넌트를 찾으세요.
+  * 공통 소유 컴포넌트 (common owner component)를 찾으세요. (계층 구조 내에서 특정 state가 있어야 하는 모든 컴포넌트들의 위에 있는 하나의 컴포넌트).


위에 있는 -> 상위에 있는 으로 제안드려봐요 :)

반영했습니다.

taehwanno · 2019-04-04T15:15:50Z

content/docs/thinking-in-react.md

+
+  * state를 기반으로 렌더링하는 모든 컴포넌트를 찾으세요.
+  * 공통 소유 컴포넌트 (common owner component)를 찾으세요. (계층 구조 내에서 특정 state가 있어야 하는 모든 컴포넌트들의 위에 있는 하나의 컴포넌트).
+  * 공통  혹은 더 상위에 있는 컴포넌트가 state를 가져야 합니다.


공통과 혹은 사이에 추가적인 공백 삭제 부탁드려요

반영했습니다.

아직 반영이 되지 않은것 같아요. 확인 부탁드립니다.

확인했고 수정했습니다.

hg-pyun

제가 리뷰한 부분은 수정 되었습니다 :)

yesjin-git

fix : 2nd review

gnujoow · 2019-05-04T05:02:06Z

content/docs/thinking-in-react.md

+
+애플리케이션을 올바르게 만들기 위해서는 애플리케이션에서 필요로 하는 변경 가능한 state의 최소 집합을 생각해보아야 합니다. 여기서 핵심은 [중복배제](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)원칙입니다. 애플리케이션이 필요로 하는 가장 최소한의 state를 찾고 이를 통해 나머지 모든 것들이 필요에 따라 그때그때 계산되도록 만드세요. 예를 들어 TODO 리스트를 만든다고 하면, TODO 아이템을 저장하는 배열만 유지하고 TODO 아이템의 개수를 표현하는 state를 별도로 만들지 마세요. TODO 갯수를 렌더링해야한다면 TODO 아이템 배열의 길이를 가져오면 됩니다.
+
+예시 애플리케이션 내 데이터들을 생각해봅시다. 우리는 현재,


완벽한 문장의 형태가 아닙니다.

예시 애플리케이션 내 데이터들을 생각해봅시다. 어플리케이션에 다음과 같은 데이터를 가지고 있습니다.

와 같이 수정하면 읽는데 더 편할것 같습니다.

애플리케이션은 다음과 같은 데이터를 가지고 있습니다. 로 수정했습니다.

gnujoow · 2019-05-04T05:03:37Z

content/docs/thinking-in-react.md

+
+제품의 원본 목록은 props를 통해 전달되므로 state가 아닙니다. 검색어와 체크박스는 state로 볼 수 있는데 시간이 지남에 따라 변하기도 하면서 다른 것들로부터 계산될 수 없기 때문입니다. 그리고 마지막으로 필터링된 목록은 state가 아닙니다. 제품의 원본 목록과 검색어, 체크박스의 값을 조합해서 계산해낼 수 있기 때문입니다.
+
+결과적으로 state는


완벽한 문장의 형태가 아닙니다.

결과적으로 앱은 다음과 같은 state를 가집니다.

와 같이 순화하면 더 쉽게 읽힐 수 있을것 같아요

결과적으로 애플리케이션은 다음과 같은 state를 가집니다. 로 바꿨습니다.

gnujoow · 2019-05-04T05:04:23Z

content/docs/thinking-in-react.md

+
+우리가 원하는 것이 무엇인지를 한번 생각해봅시다. 우리는 사용자가 폼을 변경할 때마다 사용자의 입력을 반영할 수 있도록 state를 업데이트하기를 원합니다. 컴포넌트는 그 자신의 state만 변경할 수 있기 때문에 `FilterableProductTable`는 `SearchBar`에 콜백을 넘겨서 state가 업데이트되어야 할 때마다 호출되도록 할 것입니다. 우리는 input에 onChange 이벤트를 사용해서 알림을 받을 수 있습니다. `FilterableProductTable`에서 전달된 콜백은 `setState()`를 호출하고 앱이 업데이트될 것입니다.
+
+복잡해 보이지만 코드에선 몇줄밖에 안됩니다. 그리고 이를 통해 앱 전체적으로 데이터가 흐르는 모습을 명시적으로 볼 수 있습니다.


몇줄밖에 안됩니다.(x) -> 몇줄밖에 안 됩니다(o)

수정했습니다.

gnujoow · 2019-05-04T05:08:37Z

content/docs/thinking-in-react.md

+
+![Component diagram](../images/blog/thinking-in-react-components.png)
+
+다섯개의 컴포넌트로 이루어진 간단한 앱을 한번 봅시다. 각각의 컴포넌트에 들어간 데이터는 이탤릭체로 표현했습니다.


표현했습니다. -> 표기했습니다. / 작성하였습니다.

표기했습니다. 로 바꿨습니다.

gnujoow · 2019-05-04T05:10:00Z

content/docs/thinking-in-react.md

+  4. **`ProductCategoryRow`(하늘색)**: 각 *카테고리(category)*의 헤더를 보여줍니다.
+  5. **`ProductRow`(빨강색)**: 각각의 *제품(product)*에 해당하는 행을 보여줍니다.
+
+`ProductTable`을 보면 “Name” 과 “Price” 레이블을 포함한 테이블 헤더만을 가진 컴포넌트는 없습니다. 이와 같은 경우, 데이터를 위한 독립된 컴포넌트를 생성할지 생성하지 않을지는 선택입니다. 이 예시에서는 `ProductTable`의 책임인 *데이터 컬렉션(data collection)*이 렌더링의 일부이기 때문에 `ProductTable`을 남겨두었습니다. 그러나 이 헤더가 복잡해지면 (즉 정렬을 위한 기능을 추가하는 등) `ProductTableHeader`컴포넌트를 만드는 것이 더 합리적일 것입니다.


이와 같은 경우 -> 이 같은 경우

이 같은 경우로 수정했습니다.

gnujoow

LGTM

first draft: thinking in react

3f08a75

hg-pyun added the needs review label Mar 24, 2019

hg-pyun requested changes Mar 24, 2019

View reviewed changes

content/docs/thinking-in-react.md Outdated Show resolved Hide resolved

content/docs/thinking-in-react.md Outdated Show resolved Hide resolved

content/docs/thinking-in-react.md Show resolved Hide resolved

hg-pyun added needs +1 approval and removed needs review labels Mar 24, 2019

fix 1st review

56c6f6d

yesjin-git changed the title ~~first draft: thinking in react~~ Translation for thinking in react Mar 25, 2019

tesseralis mentioned this pull request Mar 26, 2019

Korean Translation Progress #1

Open

Merge branch 'master' into master

c868105

hg-pyun removed the needs author response label Mar 31, 2019

hg-pyun reviewed Mar 31, 2019

View reviewed changes

taehwanno mentioned this pull request Apr 4, 2019

Translate a document of 'Thinking in React' into Korean #71

Closed

5 tasks

taehwanno reviewed Apr 4, 2019

View reviewed changes

taehwanno added needs author response and removed needs +1 approval labels Apr 4, 2019

hg-pyun previously approved these changes Apr 14, 2019

View reviewed changes

Update thinking-in-react.md

2f1964a

yesjin-git dismissed hg-pyun’s stale review via 2f1964a April 21, 2019 14:32

yesjin-git commented Apr 21, 2019

View reviewed changes

hg-pyun added needs +1 approval and removed needs author response labels Apr 23, 2019

hg-pyun previously approved these changes Apr 23, 2019

View reviewed changes

hg-pyun added 2 commits April 23, 2019 16:47

Merge branch 'master' into master

c36013d

Merge branch 'master' into master

8d41a74

gnujoow reviewed May 4, 2019

View reviewed changes

gnujoow requested changes May 4, 2019

View reviewed changes

gnujoow requested a review from hg-pyun May 4, 2019 05:11

Update thinking-in-react.md

581c86a

yesjin-git dismissed hg-pyun’s stale review via 581c86a May 5, 2019 11:55

hg-pyun approved these changes May 6, 2019

View reviewed changes

Merge branch 'master' into master

248d36f

gnujoow requested review from taehwanno and gnujoow May 6, 2019 15:20

gnujoow approved these changes May 6, 2019

View reviewed changes

gnujoow added ready to merge and removed needs +1 approval labels May 6, 2019

Merge branch 'master' into master

8585063

hg-pyun merged commit 7283283 into reactjs:master May 7, 2019


		React 는 JavaScript로 규모가 크고 빠른 웹 애플리케이션을 만드는 가장 좋은 방법입니다. React는 Facebook과 Instagram을 통해 확장성을 입증했습니다.

		React의 가장 멋진 점 중 하나는 앱을 설계하는 방식입니다. 이 문서를 통해 리액트로 상품들을 검색할 수 있는 데이터 테이블을 만드는 과정을 함께 생각해 봅시다.


		## 1단계: UI를 컴포넌트 계층 구조로 나누기 {#step-1-break-the-ui-into-a-component-hierarchy}

		우리가 할 첫 번째 일은 모든 컴포넌트(와 하위 컴포넌트)의 주변에 박스를 그리고 그 각각에 이름을 붙이는 것입니다. 만약 디자이너와 함께 일한다면, 이것들을 이미 정해두었을 수 있으니 한번 대화해보세요! 디자이너의 Photoshop 레이어 이름이 React 컴포넌트의 이름이 될 수 있습니다.


		우리가 할 첫 번째 일은 모든 컴포넌트(와 하위 컴포넌트)의 주변에 박스를 그리고 그 각각에 이름을 붙이는 것입니다. 만약 디자이너와 함께 일한다면, 이것들을 이미 정해두었을 수 있으니 한번 대화해보세요! 디자이너의 Photoshop 레이어 이름이 React 컴포넌트의 이름이 될 수 있습니다.

		하지만 어떤 것이 컴포넌트가 되어야 할지 어떻게 알 수 있을까요? 우리가 새로운 함수나 객체를 만들 때처럼 만드시면 됩니다. 한 가지 테크닉은 [단일 책임 원칙](https://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%B1%85%EC%9E%84_%EC%9B%90%EC%B9%99)입니다. 이는 하나의 컴포넌트는 한 가지 일을 하는게 이상적이라는 원칙입니다. 만약 하나의 컴포넌트가 커지게 된다면 이는 보다 작은 하위 컴포넌트로 분리되어야 합니다.


		## 2단계: React로 정적인 버전 만들기 {#step-2-build-a-static-version-in-react}

		<p data-height="600" data-theme-id="0" data-slug-hash="BwWzwm" data-default-tab="js" data-user="lacker" data-embed-versi기n="2" class="codepen"><a href="https://codepen.io">CodePen</a>에서<a href="https://codepen.io/gaearon/pen/BwWzwm">Thinking In React: Step 2</a>를 살펴보세요.</p>


		이 단계가 끝나면 데이터 렌더링을 위해 만들어진 재사용 가능한 컴포넌트들의 라이브러리를 가지게 됩니다. 현재는 앱의 정적 버전이기 때문에 컴포넌트는 `render()` 메서드만 가지고 있을 것입니다. 계층구조의 최상단 컴포넌트 (`FilterableProductTable`)는 prop으로 데이터 모델을 받습니다. 데이터 모델이 변경되면 `ReactDOM.render()`를 다시 호출하서 UI가 업데이트 됩니다. 지금 단계서 어떻게 UI가 업데이트되는지 확인하는 일은 어렵지 않은데 지금은 크게 복잡한 부분이 없기 때문입니다. React의 단방향 데이터 흐름(one-way data flow) (또는 단방향 바인딩(one-way binding))는 모든 것을 모듈화 하고 빠르게 만들어줍니다.

		이 단계를 실행하는데 어려움이 있다면 [공식 리액트 문서](/docs/)를 참고하세요.


		애플리케이션을 올바르게 만들기 위해서는 애플리케이션에서 필요로 하는 변경 가능한 state의 최소 집합을 생각해보아야 합니다. 여기서 핵심은 [중복배제](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)원칙입니다. 애플리케이션이 필요로 하는 가장 최소한의 state를 찾고 이를 통해 나머지 모든 것들이 필요에 따라 그때그때 계산되도록 만드세요. 예를 들어 TODO 리스트를 만든다고 하면, TODO 아이템을 저장하는 배열만 유지하고 TODO 아이템의 개수를 표현하는 state를 별도로 만들지 마세요. TODO 갯수를 렌더링해야한다면 TODO 아이템 배열의 길이를 가져오면 됩니다.

		예시 애플리케이션 내 데이터들을 생각해봅시다. 우리는 현재,


		제품의 원본 목록은 props를 통해 전달되므로 state가 아닙니다. 검색어와 체크박스는 state로 볼 수 있는데 시간이 지남에 따라 변하기도 하면서 다른 것들로부터 계산될 수 없기 때문입니다. 그리고 마지막으로 필터링된 목록은 state가 아닙니다. 제품의 원본 목록과 검색어, 체크박스의 값을 조합해서 계산해낼 수 있기 때문입니다.

		결과적으로 state는


		우리가 원하는 것이 무엇인지를 한번 생각해봅시다. 우리는 사용자가 폼을 변경할 때마다 사용자의 입력을 반영할 수 있도록 state를 업데이트하기를 원합니다. 컴포넌트는 그 자신의 state만 변경할 수 있기 때문에 `FilterableProductTable`는 `SearchBar`에 콜백을 넘겨서 state가 업데이트되어야 할 때마다 호출되도록 할 것입니다. 우리는 input에 onChange 이벤트를 사용해서 알림을 받을 수 있습니다. `FilterableProductTable`에서 전달된 콜백은 `setState()`를 호출하고 앱이 업데이트될 것입니다.

		복잡해 보이지만 코드에선 몇줄밖에 안됩니다. 그리고 이를 통해 앱 전체적으로 데이터가 흐르는 모습을 명시적으로 볼 수 있습니다.


		![Component diagram](../images/blog/thinking-in-react-components.png)

		다섯개의 컴포넌트로 이루어진 간단한 앱을 한번 봅시다. 각각의 컴포넌트에 들어간 데이터는 이탤릭체로 표현했습니다.

Translation for thinking in react #77

Translation for thinking in react #77

Conversation

yesjin-git commented Mar 24, 2019 • edited Loading

Progress

netlify bot commented Mar 24, 2019 • edited Loading

hg-pyun left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hg-pyun left a comment

Choose a reason for hiding this comment

yesjin-git left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gnujoow left a comment

Choose a reason for hiding this comment

yesjin-git commented Mar 24, 2019 •

edited

Loading

netlify bot commented Mar 24, 2019 •

edited

Loading