-
Notifications
You must be signed in to change notification settings - Fork 14
상호보완 도구들, 리액트로 생각해보기 번역 #7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
||
이 문서의 원본은 [공식 블로그](/react/blog)의 [포스팅](/react/blog/2013/11/05/thinking-in-react.html) 입니다. | ||
|
||
제가 생각하기에, React는 Javascript로 크고 빠른 웹 어플리케이션을 만드는데 최고입니다. 페이스북과 인스타그램에서 우리에게 잘 맞도록 조정되어 왔습니다. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
중요한 건 아니지만... 자바스크립트
는 JavaScript
입니다. ㅋㅋㅋ
component는 구성요소보다는 '컴포넌트'로 쓰면 어떨까요! |
단어 쓰신건 https://github.com/reactkr/discuss/wiki/glossary 요기에도.. |
|
||
그런데 무엇이 구성요소가 되어야 할까요? 당신이 새로운 함수나 객체를 만들어야만 한다면, 똑같이 적용하세요. 한가지 방법은 [단일 책임의 원칙](http://en.wikipedia.org/wiki/Single_responsibility_principle) 입니다. 즉 하나의 구성요소는 이상적으로 한가지 작업만 수행해야합니다. 구성요소가 결국 커진다면 작은 자식 구성요소로 쪼개져야 합니다. | ||
|
||
때때로 사용자에게 JSON 데이터 모델을 보여준 이후, 자료 모델이 잘 설계 되었다면 UI(혹은 구성요소 구조)가 잘 맞아떨어진다는 것을 알게될겁니다. UI와 자료 모델은 같은 *정보 설계구조*로 들러붙으려는 경향이 있기 때문입니다. 즉, UI를 구성요소들로 쪼개려는 작업은 크게 어렵지 않습니다. 확실하게 각각 하나의 부분이 되도록 쪼개세요. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 때때로 ~ 이후 -> 주로(often) JSON 데이터 모델을 사용자에게 보여주기 때문에(since)
- '들러붙으려는'보다는 '따라가는'이 어떨까요.
감사합니다. 최대한 반영 했습니다. |
|
||
껍데기부터 혹은 속알맹이부터 만들 수 있습니다. 즉 계층구조상 위에서부터 (`FilterableProductTable` 부터) 혹은 아래에서부터 (`ProductRow`), 어느 방향에서든 시작해도 됩니다. 통상 큰 프로젝트에서는 계층구조상 위에서부터 시작하는게 쉽고, 테스트를 작성할때는 아래에서부터 시작하는게 쉽습니다. | ||
|
||
이 단계의 결과, 자료 모델을 그리는 재활용 가능한 컴포넌트의 라이브러리를 갖게 되었습니다. 정적버전 이후로 컴포넌트들은 오직 `render()` 메서드만 갖고 있습니다. 계층구조상 가장 위의 컴포넌트 (`FilterableProductTable`)은 자료 모델을 prop으로 취할 것입니다. 자료 모델이 변했을 때, `React.render()`를 다시 부르면 업데이트 됩니다. 어떻게 UI가 업데이트 되는지 참 알기 쉽습니다. 자료가 바뀌어도 처리해야 할 복잡한 일이 아무것도 없습니다. React의 **단일 방향 자료 흐름** (혹은 *딘일방향 바인딩*)이 모든것을 모듈식으로, 추론하기 쉽게, 그리고 빠르게 유지해줍니다. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
딘일 -> 단일
|
||
우리가 원하는게 뭔지 생각해 봅시다. 사용자가 form을 바꿀때마다 사용자 입력을 반영하기 위해 업데이트 하기를 원하죠. 컴포넌트들이 오직 자기 자신의 state만 업데이트 하더라도 `FilterableProductTable`은 state가 변할때마다 반영되어야할 `SearchBar`에 콜백을 전달할것입니다. 이 알림을 위해서 `onChange`이벤트를 사용할 수 있습니다. 그리고 `FilterableProductTable`으로부터 전달된 콜백은 `setState()`를 호출할 것이고, 애플리케이션은 업데이트 될겁니다. | ||
|
||
듣기에는 휘황찬란한것 같지만, 실제로는 적은량의 코드입니다. 그리고 실제로 애플리케이션을 통해 자료가 흐릅니다. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
많은 코드가 필요한 것 같이 들릴 수 있지만 실제로는 몇 줄 되지 않습니다. 그리고 애플리케이션의 구석구석을 데이터가 어떻게 흘러가는지 매우 명확해집니다.
저는 일단 괜찮은 것 같아요. 나중에 좀 더 다듬으면 될 듯... |
|
||
당신이 하고싶은 첫번째는 모형에 있는 모든 컴포넌트 (그리고 자식요소) 주위에 상자를 그리고, 이름을 부여하는 것입니다. 만약 당신이 디자이너와 같이 작업중이라면, 그들은 이미 이 작업을 해놨을지도 모릅니다. 당장 가서 이야기해보세요. 그들의 포토샵 레이어 이름이 결국 당신의 React 컴포넌트들의 이름이 될것입니다. | ||
|
||
그런데 무엇이 컴포넌트가 되어야 할까요? 당신이 새로운 함수나 객체를 만들어야만 한다면, 똑같이 적용하세요. 한가지 방법은 [단일 책임의 원칙](http://en.wikipedia.org/wiki/Single_responsibility_principle) 입니다. 즉 하나의 컴포넌트는 이상적으로 한가지 작업만 수행해야합니다. 컴포넌트가 결국 커진다면 작은 자식 컴포넌트로 쪼개져야 합니다. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
단일 책임의 원칙 url은 여기로 해도 될것 같아요.
http://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%B1%85%EC%9E%84_%EC%9B%90%EC%B9%99
감사합니다. |
👍 |
from e36614f
리액트로 생각해보기
문서에서 마지막 문단은 어떤식으로 번역해야할지 모르겠읍니다..도와주세요.