From 34c4e4aacddcb2dbedb45a04b733f93f8b849579 Mon Sep 17 00:00:00 2001 From: Jay Jaeho Lee Date: Mon, 26 Jan 2015 20:37:43 +0900 Subject: [PATCH 01/52] Add docs/docs 01 --- docs/01-why-react.ko-KR.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 docs/01-why-react.ko-KR.md diff --git a/docs/01-why-react.ko-KR.md b/docs/01-why-react.ko-KR.md new file mode 100644 index 00000000..40757c6b --- /dev/null +++ b/docs/01-why-react.ko-KR.md @@ -0,0 +1,30 @@ +--- +id: why-react-ko-KR +title: 왜 React인가? +permalink: why-react-ko-KR.html +next: displaying-data-ko-KR.html +--- + +React는 페이스북과 인스타그램에서 사용자 인터페이스를 구성하기 위해 만들어진 라이브러리입니다. 많은 사람들은 React를 **[MVC](http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)** 에서의 **V** 로 생각하는 경향이 있습니다. + +우리는 단 하나의 문제를 해결하기 위해 React를 만들었습니다: **지속해서 데이터가 변화하는 대규모 애플리케이션을 구축하기.** 이 문제를 해결하기 위해, React는 두가지 컨셉을 도입했습니다. + +### 단순함 + +당신의 애플리케이션이 특정 시점에 어떻게 보여야 할지를 단순히 표현하는 것만으로, 데이터가 변할 때 React는 자동으로 모든 UI 업데이트를 관리해줍니다. + +### 선언적 문법 + +데이터가 변할 때 React는 "새로 고침" 버튼을 누르듯이 작동하며, 데이터의 바뀐 부분만을 업데이트할 수 있습니다. + +## 구성적인 컴포넌트를 만드세요 + +React는 재사용 가능한 컴포넌트들을 만드는 데에 도움이 됩니다. 사실, React를 사용하면 *단지* 컴포넌트를 만드는 일만 하게 됩니다. 컴포넌트들은 잘 캡슐화되어 되어 있기 때문에, 컴포넌트들은 코드의 재사용성을 높이고, 테스트를 쉽게 해 주며, 관심 분리의 원칙(separation of concerns)을 지키게 해 줍니다. + +## 5분만 투자하세요 + +React는 많은 관습적인 사고에 도전하며, 첫눈에 볼 때는 이상한 아이디어들의 모음이라고 생각할 수도 있습니다. 이 가이드를 읽기 위해 [5분만 투자하세요](http://37signals.com/svn/posts/3124-give-it-five-minutes); 그 이상한 아이디어들은 페이스북과 인스타그램 안팎의 수천 개의 컴포넌트들을 만드는 데에 사용되었기 때문입니다. + +## 더 알아보기 + +[이 블로그 포스트](http://facebook.github.io/react/blog/2013/06/05/why-react.html)에서 React를 만든 우리의 동기에 대해 알아볼 수 있습니다. From 7f3d18557ce751653d1373cc816ee52a12c49099 Mon Sep 17 00:00:00 2001 From: Lee Jaeyoung Date: Thu, 29 Jan 2015 16:36:00 +0900 Subject: [PATCH 02/52] translate examples.md --- docs/examples.ko-KR.md | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 docs/examples.ko-KR.md diff --git a/docs/examples.ko-KR.md b/docs/examples.ko-KR.md new file mode 100644 index 00000000..a14afe78 --- /dev/null +++ b/docs/examples.ko-KR.md @@ -0,0 +1,8 @@ +--- +id: examples-ko-KR +title: 예제 +permalink: examples-ko-KR.html +prev: complementary-tools-ko-KR.html +--- + +이 페이지는 이동 되었습니다. [GitHub wiki](https://github.com/facebook/react/wiki/Examples). From 4277b57ebe888dd8cb1fcb34dde811cba90149c8 Mon Sep 17 00:00:00 2001 From: Lee Jaeyoung Date: Thu, 29 Jan 2015 17:54:47 +0900 Subject: [PATCH 03/52] translate videos.md --- docs/videos.ko-KR.md | 141 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 docs/videos.ko-KR.md diff --git a/docs/videos.ko-KR.md b/docs/videos.ko-KR.md new file mode 100644 index 00000000..2bbc7f52 --- /dev/null +++ b/docs/videos.ko-KR.md @@ -0,0 +1,141 @@ +--- +id: videos-ko-KR +title: 비디오들 +permalink: videos-ko-KR.html +prev: thinking-in-react-ko-KR.html +next: complementary-tools-ko-KR.html +--- + +### Rethinking best practices - JSConf.eu + + + +"페이스북과 인스타그램에서, 우리는 React 를 이용해 웹에서 벌어질 수 있는 한계를 뛰어넘으려 노력하고 있습니다. 저는 프레임워크에 대한 짤막한 소개로 시작해서, 논쟁이 벌어질 수 있는 다음의 세가지 주제로 넘어갈겁니다. 템플릿의 개념을 버리고 Javascript 를 이용해 View 를 구축하기, 자료가 변할때 전체 어플리케이션을 다시 그리기(“re-rendering”), 그리고 DOM과 events의 경량화된 구현 입니다." -- [Pete Hunt](http://www.petehunt.net/) + +### Thinking in react - tagtree.tv + +[tagtree.tv](http://tagtree.tv/)의 비디오는 간단한 어플리케이션을 구성하면서 [Thinking in React](/react/docs/thinking-in-react.html) 의 원리들을 전달합니다. +
[![](/react/img/docs/thinking-in-react-tagtree.png)](http://tagtree.tv/thinking-in-react)
+ + +### Secrets of the Virtual DOM - MtnWest JS + + + +"이번에는 왜 우리가 virtual DOM을 만들었는지, 이것이 다른 시스템들과는 어떻게 다른지, 그리고 브라우져 기술들의 미래와 어떻게 관련이 있는지에 대해서 이야기 해 볼 겁니다." -- [Pete Hunt](http://www.petehunt.net/) + + +### Going big with React + +"이 발표에서, 이 모든 JS 프레임워크가 다음을 약속하는것처럼 보입니다: 꺠끗한 구현들, 빠른 코드 디자인, 완전한 수행. 그런데 당신이 Javascript 스트레스 테스트를 할때, 어떤 일이 발생합니까? 혹은 6MB의 코드를 던지면 무슨일이 발생합니까? 이번에는 높은 스트레스 환경에서 React가 어떻게 작동하는지, 그리고 이것이 우리 팀이 방대한 크기의 코드를 안전하게 구성하는데 어떻게 도움이 되어줄지를 조사해 볼겁니다." +[![](https://i.vimeocdn.com/video/481670116_650.jpg)](https://skillsmatter.com/skillscasts/5429-going-big-with-react#video) + +### CodeWinds + +CodeWinds Episode 4 에서 [Pete Hunt](http://www.petehunt.net/)와 [Jeff Barczewski](http://jeff.barczewski.com/)가 React에 대해서 이야기 합니다. + +
[![](/react/img/docs/codewinds-004.png)](http://codewinds.com/4)
+ +
+02:08 - What is React and why use it?
+03:08 - The symbiotic relationship of ClojureScript and React
+04:54 - The history of React and why it was created
+09:43 - Updating web page with React without using data binding
+13:11 - Using the virtual DOM to change the browser DOM
+13:57 - Programming with React, render targets HTML, canvas, other
+16:45 - Working with designers. Contrasted with Ember and AngularJS
+21:45 - JSX Compiler bridging HTML and React javascript
+23:50 - Autobuilding JSX and in browser tools for React
+24:50 - Tips and tricks to working with React, getting started
+		 +27:17 - Rendering HTML on the server with Node.js. Rendering backends
+29:20 - React evolved through survival of the fittest at Facebook
+30:15 - Ideas for having state on server and client, using web sockets.
+32:05 - React-multiuser - distributed shared mutable state using Firebase
+33:03 - Better debugging with React using the state transitions, replaying events
+34:08 - Differences from Web Components
+34:25 - Notable companies using React
+35:16 - Could a React backend plugin be created to target PDF?
+36:30 - Future of React, what's next?
+39:38 - Contributing and getting help
+
+ +[방송 자료 읽어보기](http://codewinds.com/4) + + +### JavaScript Jabber + +Javascript Jabber 73에서 [Pete Hunt](http://www.petehunt.net/)와 [Jordan Walke](https://github.com/jordwalke)가 React에 대해서 이야기했습니다. + +
[![](/react/img/docs/javascript-jabber.png)](http://javascriptjabber.com/073-jsj-react-with-pete-hunt-and-jordan-walke/#content)
+ +
+01:34 – Pete Hunt Introduction
+02:45 – Jordan Walke Introduction
+04:15 – React
+06:38 – 60 Frames Per Second
+09:34 – Data Binding
+12:31 – Performance
+17:39 – Diffing Algorithm
+19:36 – DOM Manipulation +		 +23:06 – Supporting node.js
+24:03 – rendr
+26:02 – JSX
+30:31 – requestAnimationFrame
+34:15 – React and Applications
+38:12 – React Users Khan Academy
+39:53 – Making it work +
+ +[전체 기록 읽어보기](http://javascriptjabber.com/073-jsj-react-with-pete-hunt-and-jordan-walke/) + +### Introduction to React.js - Facebook Seattle + + + +By [Tom Occhino](http://tomocchino.com/), [Jordan Walke](https://github.com/jordwalke) + +### Backbone + React + Middleman Screencast + + +Backbone은 React로 REST API를 제공하기 위한 아주 좋은 방법입니다. 이 화면중개는 [Backbone-React-Component](https://github.com/magalhas/backbone-react-component)을 이용해서 어떻게 이 두가지를 병합하는지 보여줍니다. Middleman은 이 예제에서 사용되는 프레임워크이지만, 쉽게 다른 프레임워크로 대체하실 수 있습니다. 지원되는 템플릿은 [이곳](https://github.com/jbhatab/middleman-backbone-react-template)에서 찾으실 수 있습니다. -- [열린 마음의 혁명들](http://www.openmindedinnovations.com/) + +### Developing User Interfaces With React - Super VanJS + + + +By [Steven Luscher](https://github.com/steveluscher) + +### Introduction to React - LAWebSpeed meetup + + + +by [Stoyan Stefanov](http://www.phpied.com/) + +### React, or how to make life simpler - FrontEnd Dev Conf '14 + + + +**러시아어** by [Alexander Solovyov](http://solovyov.net/) + +### "Functional DOM programming" - Meteor DevShop 11 + + + +### "Rethinking Web App Development at Facebook" - Facebook F8 Conference 2014 + + + +### React and Flux: Building Applications with a Unidirectional Data Flow - Forward JS 2014 + + + +Facebook 개발자 [Bill Fisher](http://twitter.com/fisherwebdev)와 [Jing Chen](http://twitter.com/jingc)가 Flux 와 React 에 대해서 이야기합니다. 그리고 어떻게 단일 방향의 자료흐름을 사용하는 어플리케이션 구조가 방대한 코드를 정리하는지에 대해서 이야기합니다." + +### Server-Side Rendering of Isomorphic Apps at SoundCloud + + + +Server-side rendering을 위해 [SoundCloud](https://developers.soundcloud.com/blog/)가 React 와 Flux를 사용하는지 by [Andres Suarez](https://github.com/zertosh) +[발표 자료와 예제 코드](https://github.com/zertosh/ssr-demo-kit) From 34933df164ed1a52209f5c655941df7601d4de46 Mon Sep 17 00:00:00 2001 From: Shim Won Date: Thu, 29 Jan 2015 16:16:53 +0900 Subject: [PATCH 04/52] Translate 03 to Korean - Up to 9f18ccd --- .../03-interactivity-and-dynamic-uis.ko-KR.md | 86 +++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 docs/03-interactivity-and-dynamic-uis.ko-KR.md diff --git a/docs/03-interactivity-and-dynamic-uis.ko-KR.md b/docs/03-interactivity-and-dynamic-uis.ko-KR.md new file mode 100644 index 00000000..6b5dd0b7 --- /dev/null +++ b/docs/03-interactivity-and-dynamic-uis.ko-KR.md @@ -0,0 +1,86 @@ +--- +id: interactivity-and-dynamic-uis +title: Interactivity and Dynamic UIs +permalink: interactivity-and-dynamic-uis.ko-KR.html +prev: jsx-gotchas.ko-KR.html +next: multiple-components.ko-KR.html +--- + +이미 React에서 [어떻게 데이터를 표시](/react/docs/displaying-data.ko-KR.html)하는지를 배웠습니다. 이제 UI와의 상호작용을 어떻게 만드는지 살펴보죠. + + +## 간단한 예제 + +```javascript +var LikeButton = React.createClass({ + getInitialState: function() { + return {liked: false}; + }, + handleClick: function(event) { + this.setState({liked: !this.state.liked}); + }, + render: function() { + var text = this.state.liked ? 'like' : 'haven\'t liked'; + return ( +

+ You {text} this. Click to toggle. +

+ ); + } +}); + +React.render( + , + document.getElementById('example') +); +``` + + +## 이벤트 핸들링과 통합적인(Synthetic) 이벤트 + +React에서의 이벤트 핸들러는 HTML에서 그러던 것처럼 간단히 카멜케이스 프로퍼티(camelCased prop)로 넘기면 됩니다. React의 모든 이벤트는 통합적인 이벤트 시스템의 구현으로 IE8 이상에서는 같은 행동이 보장됩니다. 즉, React는 사양에 따라 어떻게 이벤트를 일으키고(bubble) 잡는지 알고 있고, 당신이 사용하는 브라우저와 관계없이 이벤트 핸들러에 전달되는 이벤트는 [W3C 사양](http://www.w3.org/TR/DOM-Level-3-Events/)과 같도록 보장됩니다. + +React를 폰이나 테블릿같은 터치 디바이스에서 사용하려 한다면, 간단히 `React.initializeTouchEvents(true);`로 터치 이벤트 핸들링을 켜면 됩니다. + + +## 기본 구현: 오토바인딩과 이벤트 딜리게이션 + +코드를 고성능으로 유지하고 이해하기 쉽게 하기 위해 React는 안 보이는 곳에서 몇 가지 일을 합니다. + +**오토바인딩:** 자바스크립트에서 콜백을 만들 때, 보통은 `this`의 값이 정확하도록 명시적으로 메서드를 인스턴스에 바인드해야 합니다. React에서는 모든 메서드가 자동으로 React의 컴포넌트 인스턴스에 바인드됩니다. React가 바인드 메서드를 캐시하기 때문에 매우 CPU와 메모리에 효율적입니다. 타이핑해야 할 것도 적죠! + +**이벤트 딜리게이션:** React는 실제로는 노드자신에게 이벤트 핸들러를 붙이지 않습니다. React가 시작되면 React는 탑 레벨의 단일 이벤트 리스너로 모든 이벤트를 리스닝하기 시작합니다. 컴포넌트가 마운트되거나 언마운트 될 때, 이벤트 핸들러는 그냥 내부 매핑에서 넣거나 뺄 뿐입니다. 이벤트가 발생하면, React는 이 매핑을 사용해서 어떻게 디스패치할 지를 알게 됩니다. 매핑에 이벤트 핸들러가 남아있지 않으면, React의 이벤트 핸들러는 그냥 아무것도 하지 않습니다. 왜 이 방식이 빠른지 더 알고 싶으시면, [David Walsh의 멋진 블로그 글](http://davidwalsh.name/event-delegate)을 읽어 보세요. + + +## 컴포넌트는 그냥 상태 머신일 뿐 + +React는 UI를 간단한 상태머신이라 생각합니다. UI를 다양한 상태와 그 상태의 렌더링으로 생각함으로써 UI를 일관성 있게 관리하기 쉬워집니다. + +React에서는, 간단히 컴포넌트의 상태를 업데이트하고, 이 새로운 상태의 UI를 렌더링합니다. React는 DOM의 변경을 가장 효율적인 방법으로 관리해줍니다. + + +## 상태의 동작 원리 + +React에게 데이터의 변경을 알리는 일반적인 방법은 `setState(data, callback)`을 호출하는 것입니다. 이 메서드는 `this.state`에 `data`를 머지하고 컴포넌트를 재 렌더링 합니다. 컴포넌트의 재 렌더링이 끝나면, 생략가능한 `callback`이 호출됩니다. 대부분의 경우 React가 UI를 최신상태로 유지해주기 때문에 `callback`을 사용할 필요가 없습니다. + + +## 어떤 컴포넌트가 상태를 가져야 할까요? + +대부분의 컴포넌트는 `props`로부터 데이터를 받아 렌더할 뿐입니다만, 가끔 유저 인풋, 서버 리퀘스트, 시간의 경과에 반응해야 할 필요가 있습니다. 이럴 때 상태를 사용합니다. + +**가능한 한 컴포넌트가 상태가 가지지 않도록(stateless) 하세요.** 이렇게 함으로써 가장 논리적인 장소로 상태를 격리하게 되고 쉽게 애플리케이션을 추론할 수 있도록 중복을 최소화할 수 있습니다. + +일반적인 패턴은 데이터만 렌더하는 여러 상태를 가지지 않은 컴포넌트를 만들고, 그 위에 상태기반 컴포넌트를 만들어 계층 안의 자식 컴포넌트에게 `props`를 통해 상태를 전달하는 것입니다. 상태를 가지지 않은 컴포넌트가 선언적인 방법으로 데이터를 렌더링 하는 동안, 상태기반 컴포넌트는 모든 상호작용 로직을 캡슐화합니다. + + +## 상태를 어떻게 *써야* 할까요? + +**상태는 컴포넌트의 이벤트 핸들러에 의해 UI 업데이트를 트리거할때 변경될 가능성이 있어, 그때 사용할 데이터를 가져야 합니다.** 실제 엡에서는 이 데이터는 매우 작고 JSON 직렬화 가능한 경향이 있습니다. 상태기반 컴포넌트를 만들때, 가능한 작게 상태를 서술하고 `this.state`에만 저장하도록 해보세요. 그냥 `render()` 안에서 이 상태를 기반으로 다른 모든 정보를 계산합니다. 이 방식으로 애플리케이션을 작성하고 생각하면 가장 최적의 애플리케이션으로 발전해가는 경향이 있다는 것을 발견하게 될것입니다. 장황하거나 계산된 값을 상태에 추가하는 것은 렌더가 그것을 계산하는 대신에 명시적으로 그것들을 싱크해야 하는 것을 의미하기 때문이죠. + +## 상태를 어떻게 *쓰지 말아야* 할까요? + +`this.state`는 UI의 상태를 표현할 최소한의 데이터만 가져야 합니다. 그래서 이런것을들 가지지 말아야 합니다. + +* **계산된 데이터:** 상태에 따라 값을 미리 계산하는 것을 염려하지 마세요. 계산은 모두 `render()`에서 하는 것이 UI의 일관성을 유지하기 쉽습니다. 예를 들어, 상태에서 list items 배열을 가지고 있고 문자열으로 카운트를 렌더링 할 경우, 상태에 저장하기보다는 그냥 `render()` 메서드안에서 `this.state.listItems.length + ' list items'`를 렌더하세요. +* **React 컴포넌트:** 가지고 있는 props와 상태로 `render()`안에서 만드세요. +* **props에서 복사한 데이터:** 가능한한 원래의 소스로 props를 사용하도록 해보세요. props를 상태에 저장하는 단하나의 올바른 사용법은 이전 값을 알고 싶을 때입니다. props는 시간이 지나면 변경될 수도 있기 때문이죠. From 74e801b510faf2845390258327ac1ccb6e41596d Mon Sep 17 00:00:00 2001 From: Shim Won Date: Fri, 30 Jan 2015 22:46:57 +0900 Subject: [PATCH 05/52] Fix some words, Translate title - Up to 9f18ccd --- .../03-interactivity-and-dynamic-uis.ko-KR.md | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/03-interactivity-and-dynamic-uis.ko-KR.md b/docs/03-interactivity-and-dynamic-uis.ko-KR.md index 6b5dd0b7..a5195e5e 100644 --- a/docs/03-interactivity-and-dynamic-uis.ko-KR.md +++ b/docs/03-interactivity-and-dynamic-uis.ko-KR.md @@ -1,6 +1,6 @@ --- -id: interactivity-and-dynamic-uis -title: Interactivity and Dynamic UIs +id: interactivity-and-dynamic-uis-ko-KR +title: 상호 작용 및 동적 UI permalink: interactivity-and-dynamic-uis.ko-KR.html prev: jsx-gotchas.ko-KR.html next: multiple-components.ko-KR.html @@ -52,35 +52,35 @@ React를 폰이나 테블릿같은 터치 디바이스에서 사용하려 한다 **이벤트 딜리게이션:** React는 실제로는 노드자신에게 이벤트 핸들러를 붙이지 않습니다. React가 시작되면 React는 탑 레벨의 단일 이벤트 리스너로 모든 이벤트를 리스닝하기 시작합니다. 컴포넌트가 마운트되거나 언마운트 될 때, 이벤트 핸들러는 그냥 내부 매핑에서 넣거나 뺄 뿐입니다. 이벤트가 발생하면, React는 이 매핑을 사용해서 어떻게 디스패치할 지를 알게 됩니다. 매핑에 이벤트 핸들러가 남아있지 않으면, React의 이벤트 핸들러는 그냥 아무것도 하지 않습니다. 왜 이 방식이 빠른지 더 알고 싶으시면, [David Walsh의 멋진 블로그 글](http://davidwalsh.name/event-delegate)을 읽어 보세요. -## 컴포넌트는 그냥 상태 머신일 뿐 +## 컴포넌트는 그냥 state 머신일 뿐 -React는 UI를 간단한 상태머신이라 생각합니다. UI를 다양한 상태와 그 상태의 렌더링으로 생각함으로써 UI를 일관성 있게 관리하기 쉬워집니다. +React는 UI를 간단한 state 머신이라 생각합니다. UI를 다양한 state와 그 state의 렌더링으로 생각함으로써 UI를 일관성 있게 관리하기 쉬워집니다. -React에서는, 간단히 컴포넌트의 상태를 업데이트하고, 이 새로운 상태의 UI를 렌더링합니다. React는 DOM의 변경을 가장 효율적인 방법으로 관리해줍니다. +React에서는, 간단히 컴포넌트의 state를 업데이트하고, 이 새로운 state의 UI를 렌더링합니다. React는 DOM의 변경을 가장 효율적인 방법으로 관리해줍니다. -## 상태의 동작 원리 +## state의 동작 원리 React에게 데이터의 변경을 알리는 일반적인 방법은 `setState(data, callback)`을 호출하는 것입니다. 이 메서드는 `this.state`에 `data`를 머지하고 컴포넌트를 재 렌더링 합니다. 컴포넌트의 재 렌더링이 끝나면, 생략가능한 `callback`이 호출됩니다. 대부분의 경우 React가 UI를 최신상태로 유지해주기 때문에 `callback`을 사용할 필요가 없습니다. -## 어떤 컴포넌트가 상태를 가져야 할까요? +## 어떤 컴포넌트가 state를 가져야 할까요? -대부분의 컴포넌트는 `props`로부터 데이터를 받아 렌더할 뿐입니다만, 가끔 유저 인풋, 서버 리퀘스트, 시간의 경과에 반응해야 할 필요가 있습니다. 이럴 때 상태를 사용합니다. +대부분의 컴포넌트는 `props`로부터 데이터를 받아 렌더할 뿐입니다만, 가끔 유저 인풋, 서버 리퀘스트, 시간의 경과에 반응해야 할 필요가 있습니다. 이럴 때 state를 사용합니다. -**가능한 한 컴포넌트가 상태가 가지지 않도록(stateless) 하세요.** 이렇게 함으로써 가장 논리적인 장소로 상태를 격리하게 되고 쉽게 애플리케이션을 추론할 수 있도록 중복을 최소화할 수 있습니다. +**가능한 한 컴포넌트가 상태를 가지지 않도록(stateless) 하세요.** 이렇게 함으로써 가장 논리적인 장소로 state를 격리하게 되고 쉽게 애플리케이션을 추론할 수 있도록 중복을 최소화할 수 있습니다. -일반적인 패턴은 데이터만 렌더하는 여러 상태를 가지지 않은 컴포넌트를 만들고, 그 위에 상태기반 컴포넌트를 만들어 계층 안의 자식 컴포넌트에게 `props`를 통해 상태를 전달하는 것입니다. 상태를 가지지 않은 컴포넌트가 선언적인 방법으로 데이터를 렌더링 하는 동안, 상태기반 컴포넌트는 모든 상호작용 로직을 캡슐화합니다. +일반적인 패턴은 데이터만 렌더하는 여러 상태를 가지지 않은 컴포넌트를 만들고, 그 위에 상태기반(stateful) 컴포넌트를 만들어 계층 안의 자식 컴포넌트에게 `props`를 통해 state를 전달하는 것입니다. state를 가지지 않은 컴포넌트가 선언적인 방법으로 데이터를 렌더링 하는 동안, 상태기반 컴포넌트는 모든 상호작용 로직을 캡슐화합니다. -## 상태를 어떻게 *써야* 할까요? +## state를 어떻게 *써야* 할까요? -**상태는 컴포넌트의 이벤트 핸들러에 의해 UI 업데이트를 트리거할때 변경될 가능성이 있어, 그때 사용할 데이터를 가져야 합니다.** 실제 엡에서는 이 데이터는 매우 작고 JSON 직렬화 가능한 경향이 있습니다. 상태기반 컴포넌트를 만들때, 가능한 작게 상태를 서술하고 `this.state`에만 저장하도록 해보세요. 그냥 `render()` 안에서 이 상태를 기반으로 다른 모든 정보를 계산합니다. 이 방식으로 애플리케이션을 작성하고 생각하면 가장 최적의 애플리케이션으로 발전해가는 경향이 있다는 것을 발견하게 될것입니다. 장황하거나 계산된 값을 상태에 추가하는 것은 렌더가 그것을 계산하는 대신에 명시적으로 그것들을 싱크해야 하는 것을 의미하기 때문이죠. +**state는 컴포넌트의 이벤트 핸들러에 의해 UI 업데이트를 트리거할때 변경될 가능성이 있어, 그때 사용할 데이터를 가져야 합니다.** 실제 엡에서는 이 데이터는 매우 작고 JSON 직렬화 가능한 경향이 있습니다. 상태기반 컴포넌트를 만들때, 가능한 작게 state를 서술하고 `this.state`에만 저장하도록 해보세요. 그냥 `render()` 안에서 이 state를 기반으로 다른 모든 정보를 계산합니다. 이 방식으로 애플리케이션을 작성하고 생각하면 가장 최적의 애플리케이션으로 발전해가는 경향이 있다는 것을 발견하게 될것입니다. 장황하거나 계산된 값을 state에 추가하는 것은 렌더가 그것을 계산하는 대신에 명시적으로 그것들을 싱크해야 하는 것을 의미하기 때문이죠. -## 상태를 어떻게 *쓰지 말아야* 할까요? +## state를 어떻게 *쓰지 말아야* 할까요? -`this.state`는 UI의 상태를 표현할 최소한의 데이터만 가져야 합니다. 그래서 이런것을들 가지지 말아야 합니다. +`this.state`는 UI의 state를 표현할 최소한의 데이터만 가져야 합니다. 그래서 이런것을들 가지지 말아야 합니다. -* **계산된 데이터:** 상태에 따라 값을 미리 계산하는 것을 염려하지 마세요. 계산은 모두 `render()`에서 하는 것이 UI의 일관성을 유지하기 쉽습니다. 예를 들어, 상태에서 list items 배열을 가지고 있고 문자열으로 카운트를 렌더링 할 경우, 상태에 저장하기보다는 그냥 `render()` 메서드안에서 `this.state.listItems.length + ' list items'`를 렌더하세요. -* **React 컴포넌트:** 가지고 있는 props와 상태로 `render()`안에서 만드세요. -* **props에서 복사한 데이터:** 가능한한 원래의 소스로 props를 사용하도록 해보세요. props를 상태에 저장하는 단하나의 올바른 사용법은 이전 값을 알고 싶을 때입니다. props는 시간이 지나면 변경될 수도 있기 때문이죠. +* **계산된 데이터:** state에 따라 값을 미리 계산하는 것을 염려하지 마세요. 계산은 모두 `render()`에서 하는 것이 UI의 일관성을 유지하기 쉽습니다. 예를 들어, state에서 list items 배열을 가지고 있고 문자열으로 카운트를 렌더링 할 경우, state에 저장하기보다는 그냥 `render()` 메서드안에서 `this.state.listItems.length + ' list items'`를 렌더하세요. +* **React 컴포넌트:** 가지고 있는 props와 state로 `render()`안에서 만드세요. +* **props에서 복사한 데이터:** 가능한한 원래의 소스로 props를 사용하도록 해보세요. props를 state에 저장하는 단하나의 올바른 사용법은 이전 값을 알고 싶을 때입니다. props는 시간이 지나면 변경될 수도 있기 때문이죠. From f2ac7da009ad0964a595e260ba769afe1c0c555d Mon Sep 17 00:00:00 2001 From: Jay Jaeho Lee Date: Thu, 29 Jan 2015 03:03:40 +0900 Subject: [PATCH 06/52] translated docs/docs/02-displaying-data.md into Korean Up to b25e2e70d8ed7eb17a18d57f16c03390767a194a --- docs/02-displaying-data.ko-KR.md | 125 +++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+) create mode 100644 docs/02-displaying-data.ko-KR.md diff --git a/docs/02-displaying-data.ko-KR.md b/docs/02-displaying-data.ko-KR.md new file mode 100644 index 00000000..1a56260e --- /dev/null +++ b/docs/02-displaying-data.ko-KR.md @@ -0,0 +1,125 @@ +--- +id: displaying-data-ko-KR +title: 데이터를 표시하기 +permalink: displaying-data.ko-KR.html +prev: why-react.ko-KR.html +next: jsx-in-depth.ko-KR.html +--- + +UI를 가지고 할 수 있는 가장 기초적인 것은 데이터를 표시하는 것입니다. React는 데이터를 표시하고 데이터가 변할 때마다 인터페이스를 최신의 상태로 자동으로 유지하기 쉽게 해 줍니다. + +## 시작하기 + +정말 간단한 예제를 보도록 하죠. 다음과 같은 코드의 `hello-react.html` 파일을 만듭시다. + +```html + + + + Hello React + + + + +
+ + + +``` + +문서의 나머지에서, 코드가 위와 같은 HTML 템플릿에 들어갔다고 가정하고 자바스크립트 코드에만 집중할 것입니다. 위의 주석 부분을 다음과 같은 자바스크립트 코드로 바꿔 보세요: + +```javascript +var HelloWorld = React.createClass({ + render: function() { + return ( +

+ 안녕, ! + 지금 시간은 {this.props.date.toTimeString()} 입니다. +

+ ); + } +}); + +setInterval(function() { + React.render( + , + document.getElementById('example') + ); +}, 500); +``` + + +## 반응 적(Reactive) 갱신 + +`hello-react.html` 파일을 웹 브라우저에서 열어 당신의 이름을 텍스트 필드에 써 보세요. React는 단지 시간을 표시하는 부분만을 바꿉니다 — 텍스트 필드 안에 입력한 것은 그대로 남아 있구요, 당신이 이 동작을 관리하는 그 어떤 코드도 쓰지 않았음에도 불구하고 말이죠. React는 그걸 올바른 방법으로 알아서 해줍니다. + +우리가 이걸 할 수 있었던 건, React는 필요한 경우에만 DOM을 조작하기 때문입니다. **React는 빠른 React 내부의 DOM 모형을 이용하여 변경된 부분을 측정하고, 가장 효율적인 DOM 조작 방법을 계산해 줍니다.** + +이 컴포넌트에 대한 입력은 `props` 라고 불립니다 — "properties" 를 줄인 것이죠. 그들은 JSX 문법에서는 어트리뷰트로서 전달됩니다. 당신은 `props` 를 컴포넌트 안에서 불변의(immutable) 요소로서 생각해야 하고, `this.props` 를 덮어씌우려고 해서는 안됩니다. + + +## 컴포넌트들은 함수와 같습니다 + +React 컴포넌트들은 매우 단순합니다. 당신은 그것들을 `props` 와 `state` (이것들은 나중에 언급할 것입니다) 를 받고 HTML을 렌더링하는 단순한 함수들로 생각해도 됩니다. 그것들은 너무 단순하기 때문에, 그것들의 작동을 이해하는 것 또한 쉽게 만듭니다. + +> 주의: +> +> **한가지 제약이 있습니다**: React 컴포넌트들은 단 하나의 루트 노드(root node)만을 렌더할 수 있습니다. 만약 여러개의 노드들을 반환하고 싶다면, 그것들은 단 하나의 루트 노드로 싸여져 있어야만 합니다. + + +## JSX 문법 + +우리는 컴포넌트를 사용하는 것이 "템플릿"과 "디스플레이 로직(display logic)"을 이용하는 것보다 관심을 분리(separate concerns)하는 데에 올바른 방법이라고 강하게 믿고 있습니다. 우리는 마크업과 그것을 만들어내는 코드는 친밀하게 함께 결합되어있다고 생각합니다. 또한, 디스플레이 로직은 종종 매우 복잡하고, 그것을 템플릿 언어를 이용해 표현하는 것은 점점 사용하기 어렵게 됩니다. + +우리는 이 문제를 해결하는 최고의 해결책은, UI를 만드는 진짜 프로그래밍 언어의 표현력을 모두 사용할 수 있는 자바스크립트 코드로부터 HTML과 컴포넌트 트리들을 생성하는 것임을 발견했습니다. + +이것을 더 쉽게 하기 위해서, 우리는 매우 간단하고, **선택적인** HTML과 비슷한 문법을 추가하여 이 React 트리 노드들을 만들 수 있게 했습니다. + +**JSX는 당신으로 하여금 HTML 문법을 이용해 자바스크립트 오브젝트를 만들게 해줍니다.** React를 이용해 순수한 자바스크립트 문법으로 링크를 만드려고 한다면, 코드는 다음과 같습니다: + +`React.createElement('a', {href: 'http://facebook.github.io/react/'}, '안녕하세요!')` + +JSX를 이용하면: + +`안녕하세요!` + +우리는 이것이 React 앱들을 만들기 쉽게 하고, 디자이너들이 이 문법을 더 선호하는 것을 발견했습니다, 하지만 모든 사람은 그들만의 선호하는 워크플로우가 있기 마련이므로, **JSX는 React를 사용하기 위해 필수적이지는 않습니다.** + +JSX는 매우 작은 언어입니다. 그것을 배우고 싶다면, [JSX 깊게 살펴보기](/react/docs/jsx-in-depth-ko-KR.html). 를 살펴 보시기 바랍니다. 또는, [우리의 온라인 JSX 컴파일러](/react/jsx-compiler.html)를 통해 문법이 변환되는 것을 살펴 보시기 바랍니다. + +JSX는 HTML과 비슷하지만, 완전히 똑같지는 않습니다. [JSX의 실수하기 쉬운 부분들](/react/docs/jsx-gotchas-ko-KR.html)에 중요한 차이점들에 대해 설명되어 있습니다. + +JSX를 사용하기 시작하기 위한 가장 쉬운 방법은 브라우저에서 작동하는 `JSXTransformer`를 사용하는 것입니다. 우리는 이것을 프로덕션에서는 사용하지 않기를 강하게 권장하는 바입니다. 당신은 우리의 커맨드 라인 [react-tools](http://npmjs.org/package/react-tools) 패키지를 이용하여 미리 컴파일(precompile)해 사용할 수 있습니다. + + +## JSX 없이 React 사용하기 + +JSX는 완전히 선택적입니다. 당신은 React와 JSX를 함께 사용하지 않아도 상관없습니다. 당신은 이 트리들을 `React.createElement` 를 통해 만들 수 있습니다. 첫번째 인자는 태그 이름이며, 두번째 인자에 속성 오브젝트를 전달하고 세번째 인자로는 자식 엘리먼트를 전달하면 됩니다. + +```javascript +var child = React.createElement('li', null, 'Text Content'); +var root = React.createElement('ul', { className: 'my-list' }, child); +React.render(root, document.body); +``` + +편의를 위하여, 당신은 팩토리 함수 헬퍼들을 이용해 커스텀 컴포넌트로부터 엘리먼트들을 만들 수 있습니다. + +```javascript +var Factory = React.createFactory(ComponentClass); +... +var root = Factory({ custom: 'prop' }); +React.render(root, document.body); +``` + +React는 이미 일반적인 HTML 태그에 대한 빌트인 팩토리를 가지고 있습니다. + +```javascript +var root = React.DOM.ul({ className: 'my-list' }, + React.DOM.li(null, '텍스트') + ); +``` From 768fa1bb6df4bdc1c612c02fa4561b9753fcac42 Mon Sep 17 00:00:00 2001 From: Lee Jaeyoung Date: Fri, 30 Jan 2015 14:28:34 +0900 Subject: [PATCH 07/52] translate complementary-tools --- docs/complementary-tools.ko-KR.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 docs/complementary-tools.ko-KR.md diff --git a/docs/complementary-tools.ko-KR.md b/docs/complementary-tools.ko-KR.md new file mode 100644 index 00000000..c387883f --- /dev/null +++ b/docs/complementary-tools.ko-KR.md @@ -0,0 +1,9 @@ +--- +id: complementary-tools-ko-KR +title: 상호 보완적인 도구들 +permalink: complementary-tools-ko-KR.html +prev: videos-ko-KR.html +next: examples-ko-KR.html +--- + +이 페이지는 이동되었습니다. [GitHub wiki](https://github.com/facebook/react/wiki/Complementary-Tools). From e1bab45bebd71d4d3c408016161e4b5edf4c246a Mon Sep 17 00:00:00 2001 From: Lee Jaeyoung Date: Fri, 30 Jan 2015 16:25:17 +0900 Subject: [PATCH 08/52] translate thinking-in-react.ko --- docs/thinking-in-react.ko-KR.md | 146 ++++++++++++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 docs/thinking-in-react.ko-KR.md diff --git a/docs/thinking-in-react.ko-KR.md b/docs/thinking-in-react.ko-KR.md new file mode 100644 index 00000000..90d1be9a --- /dev/null +++ b/docs/thinking-in-react.ko-KR.md @@ -0,0 +1,146 @@ +--- +id: thinking-in-react-ko-KR +title: 리액트로 생각해보기 +prev: tutorial-ko-KR.html +next: videos-ko-KR.html +--- + +이 문서의 원본은 [공식 블로그](/react/blog)의 [포스팅](/react/blog/2013/11/05/thinking-in-react.html) 입니다. + +제가 생각하기에, React는 JavaScript로 크고 빠른 웹 애플리케이션을 만드는데 최고입니다. 페이스북과 인스타그램에서 우리에게 잘 맞도록 조정되어 왔습니다. + +React의 많은 뛰어난 점들중 하나는 생각을 하면서 애플리케이션을 만들게 한다는 겁니다. 이 포스트에서 React를 이용해 검색이 가능한 상품자료 테이블을 만드는 생각 과정을 이해할 수 있게 차근차근 설명할겁니다. *만약 이 페이지에서 jsfiddle이 보이지 않는다면 https가 아니라 http페이지를 가리키고 있는지 확인해 보세요.* + +## 모형으로 시작해보기 + +우리가 이미 JSON API와 디자이너로부터 넘겨받은 모형을 이미 가지고 있다고 생각해봅시다. 보시다시피 우리 디자이너는 별로 좋지 않습니다: + +![Mockup](/react/img/blog/thinking-in-react-mock.png) + +우리의 JSON API는 아래와 같은 데이터를 반환합니다: + +``` +[ + {category: "Sporting Goods", price: "$49.99", stocked: true, name: "Football"}, + {category: "Sporting Goods", price: "$9.99", stocked: true, name: "Baseball"}, + {category: "Sporting Goods", price: "$29.99", stocked: false, name: "Basketball"}, + {category: "Electronics", price: "$99.99", stocked: true, name: "iPod Touch"}, + {category: "Electronics", price: "$399.99", stocked: false, name: "iPhone 5"}, + {category: "Electronics", price: "$199.99", stocked: true, name: "Nexus 7"} +]; +``` + +## 1단계: UI를 계층 구조의 컴포넌트로 분쇄하세요. + +당신이 하고싶은 첫번째는 모형에 있는 모든 컴포넌트 (그리고 자식요소) 주위에 상자를 그리고, 이름을 부여하는 것입니다. 만약 당신이 디자이너와 같이 작업중이라면, 그들은 이미 이 작업을 해놨을지도 모릅니다. 당장 가서 이야기해보세요. 그들의 포토샵 레이어 이름이 결국 당신의 React 컴포넌트들의 이름이 될것입니다. + +그런데 무엇이 컴포넌트가 되어야 할까요? 당신이 새로운 함수나 객체를 만들어야만 한다면, 똑같이 적용하세요. 한가지 방법은 [단일 책임의 원칙](http://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%B1%85%EC%9E%84_%EC%9B%90%EC%B9%99) 입니다. 즉 하나의 컴포넌트는 이상적으로 한가지 작업만 수행해야합니다. 컴포넌트가 결국 커진다면 작은 자식 컴포넌트로 쪼개져야 합니다. + +주로 JSON 데이터 모델을 사용자에게 보여주기 때문에, 자료 모델이 잘 설계 되었다면 UI(혹은 컴포넌트 구조)가 잘 맞아떨어진다는 것을 알게될겁니다. UI와 자료 모델은 같은 *정보 설계구조*로 따라가는 경향이 있기 때문입니다. 즉, UI를 컴포넌트들로 쪼개려는 작업은 크게 어렵지 않습니다. 확실하게 각각 하나의 부분이 되도록 쪼개세요. + +![Component diagram](/react/img/blog/thinking-in-react-components.png) + +이 간단한 애플리케이션에는 다섯개의 컴포넌트가 있습니다. 각 컴포넌트들이 대표하는 자료를 이탤릭체로 표기했습니다. + + 1. **`FilterableProductTable` (오렌지):** 예제 전부를 포함합니다. + 2. **`SearchBar` (파랑):** 모든 *사용자 입력* 을 받습니다. + 3. **`ProductTable` (초록):** *자료 모음*을 *사용자 입력*에 맞게 거르고 보여줍니다. + 4. **`ProductCategoryRow` (청록):** 각 *카테고리*의 제목을 보여줍니다. + 5. **`ProductRow` (빨강):** 각 *프로덕트*를 보여줍니다. + +`ProductTable`을 보면 테이블 제목("Name", "Price" 라벨들을 포함한)은 컴포넌트가 아닌것을 알 수 있습니다. 이건 기호의 문제이고, 어느쪽으로 만들던 논쟁거리입니다. 예를들어 저는 *자료 모음*을 그리는 `ProductTable`의 의무라고 생각했기 때문에 남겨 두었습니다. 하지만 이 제목이 복잡해진다면 (예를들어 정렬을 추가할 여유가 있다거나 하는), 이건 확실히 `ProductTableHeader` 컴포넌트로 만드는게 맞을겁니다. + +이제 모형에 들어있는 컴포넌트들에 대해 알아보았으니, 계층 구조로 만들어 봅시다. 이건 쉽습니다. 다른 컴포넌트 속에 들어있는 컴포넌트를 그저 자식으로 나타내면 됩니다. + + * `FilterableProductTable` + * `SearchBar` + * `ProductTable` + * `ProductCategoryRow` + * `ProductRow` + +## 2단계: 정적 버전을 만드세요. + + + +계층구조의 컴포넌트들을 가지고 있으니, 이젠 애플리케이션을 구현할 시간입니다. 가장 쉬운 방법은 상호작용을 하지 않는채로 자료 모델을 이용해 UI를 그리는 것입니다. 정적 버전을 만드는데는 적은 생각과 많은 노동이 필요하고, 상호작용을 추가하는데는 많은 생각과 적은 노동이 필요하기때문에 둘을 분리하는게 쉽습니다. 왜그런지 봅시다. + +자료 모델을 그리는 애플리케이션의 정적버전을 만들기 위해서, 다른 컴포넌트에 재사용할 컴포넌트를 만들고 자료 전달을 위해 *props*를 사용하고 싶을 것입니다. 만약 *상태*라는 개념에 익숙하다면, 정적 버전을 만들때 **절대 상태를 사용하지 마세요**. 상태는 오직 상호작용, 즉 가변적인 자료를 위해서만 준비되어 있습니다. 정적 버전을 만들때는 필요가 없다는 겁니다. + +껍데기부터 혹은 속알맹이부터 만들 수 있습니다. 즉 계층구조상 위에서부터 (`FilterableProductTable` 부터) 혹은 아래에서부터 (`ProductRow`), 어느 방향에서든 시작해도 됩니다. 통상 큰 프로젝트에서는 계층구조상 위에서부터 시작하는게 쉽고, 테스트를 작성할때는 아래에서부터 시작하는게 쉽습니다. + +이 단계의 결과, 자료 모델을 그리는 재활용 가능한 컴포넌트의 라이브러리를 갖게 되었습니다. 정적버전 이후로 컴포넌트들은 오직 `render()` 메서드만 갖고 있습니다. 계층구조상 가장 위의 컴포넌트 (`FilterableProductTable`)은 자료 모델을 prop으로 취할 것입니다. 자료 모델이 변했을 때, `React.render()`를 다시 부르면 업데이트 됩니다. 어떻게 UI가 업데이트 되는지 참 알기 쉽습니다. 자료가 바뀌어도 처리해야 할 복잡한 일이 아무것도 없습니다. React의 **단일 방향 자료 흐름** (혹은 *단일방향 바인딩*)이 모든것을 모듈식으로, 추론하기 쉽게, 그리고 빠르게 유지해줍니다. + +이 단계를 진행하는데 도움이 필요하시다면, [React 문서](http://facebook.github.io/react/docs/)를 참조하세요. + +### 잠시만: props vs state + +React 에는 두가지 타입의 자료 "모델"이 있습니다: props 와 state. 두가지의 구분점을 이해하는데 매우 중요합니다; 혹시 차이점을 확신하지 못한다면 걷어내세요 [공식 문서](http://facebook.github.io/react/docs/interactivity-and-dynamic-uis.html). + +## 3단계: UI state 의 표현을 작지만 완전하도록 확인하세요. + +상호적인 UI를 만들기 위해서는 자료 모델 변화에 반응할 수 있어야 합니다. React는 **state**로 이걸 쉽게 만들어주죠. + +올바르게 애플리케이션을 만들기 위해서는 첫째로 애플리케이션에 필요한 변할 수 있는 state 들의 최소한의 집합에 대해서 생각해볼 필요가 있습니다. 여기 방법이 있습니다: *스스로 반복하지 마세요*. 애플리케이션의 상태를 나타낼 수 있는 가장 최소한의 표현 방식을 찾고, 그 밖의 것은 필요할 때 계산합니다. 예를들어 TODO 리스트를 만든다고 칩시다. TODO 아이템들의 배열만 유지하세요; 갯수를 표현하기 위한 state 변수를 분리하지 마세요. 대신 TODO 아이템들 배열의 길이를 이용하세요. + +예제 애플리케이션에서의 모든 자료유형에 대해 생각해 봅시다: + + * product 들의 원본 리스트 + * 사용자가 입력한 검색어 + * 체크박스의 값 + * product 들의 걸러진 리스트 + +어느것이 state 가 될지 따져봅시다. 간단하게 각 자료에 대해 세가지만 생각해 보세요. + + 1. 만약 부모로부터 props 를 이용해 전달됩니까? 그렇다면 이건 state가 아닙니다. + 2. 종종 바뀝니까? 아니라면 이것 역시 state가 아닙니다. + 3. 컴포넌트에 있는 다른 state나 props를 통해서 계산되어질 수 있습니까? 역시 state가 아닙니다. + +product 들의 원본 리스트는 props를 통해서 전달되기 때문에, state가 아닙니다. 검색어와 체크박스의 값은 다른것에 의해 계산될 수 있는 값이 아니고, 시시각각 변하기때문에 state가 맞습니다. 마지막으로 product 들의 걸러진 리스트 역시 state가 아닙니다. 원본 리스트와 검색어, 체크박스의 값등에 의해 연산되어지는 값이기 때문이죠. + +결국, state는 다음과 같습니다: + + * 사용자가 입력한 검색어 + * 체크박스의 값 + +## 4단계: 어디서 state가 유지되어야 하는지 확인하세요. + + + +이제 최소한의 state가 무엇인지 알아 내었습니다. 다음은 어떤 컴포넌트가 이 state를 변형하거나 만들어 낼지 알아내야합니다. + +기억하세요: React는 계층적 아래 컴포넌트로만 향하는 단일방향성 자료 흐름을 가집니다. 지금당장은 어떤 컴포넌트가 자기 자신의 state를 가져야 할지 명확하지 않을겁니다. **이것이 처음 접하는 사람이 가장 이해하기 어려운 부분입니다**. 이제 명확히 하기 위해 다음을 따라봅시다: + +애플리케이션에서 state의 경우: + + * 모든 컴포넌트가 state를 통해 무언가를 그려냅니다. + * 대표 컴포넌트가 뭔지 찾으세요 (계층적으로 다른 컴포넌트들의 단일 상위 컴포넌트는 state를 가질 필요가 있습니다). + * 대표 컴포넌트 혹은 또다른 컴포넌트는 가능한 상위의 컴포넌트가 state를 소유해야합니다. + * 만약 state를 가져야할 컴포넌트가 어느것인지 모르겠으면, 새로운 컴포넌트를 만들어 state를 부여하고 기존의 대표 컴포넌트 위에 추가하세요. + +이 전략을 우리 애플리케이션에 적용해 봅시다. + + * `ProductTable`은 state에 대해 걸러질 필요가 있고, `SearchBar` 역시 검색어 state와 체크박스 state를 보여줄 필요가 있습니다. + * 대표 컴포넌트는 `FilterableProductTable` 입니다. + * 개념적으로 검색어와 체크박스 값은 `FilterableProductTable`에 있어야 한다는게 명확합니다. + +좋습니다. state를 `FilterableProductTable`에서 관리하도록 결정했습니다. 먼저 `getInitialState()` 메서드를 `FilterableProductTable`에 추가하세요. 이 메서드는 애플리케이션의 초기 state를 갖도록 `{filterText: '', inStockOnly: false}`를 반환하면 됩니다. 그리고 `filterText`와 `inStockOnly` 를 `ProductTable`과 `SearchBar`에 prop으로 전달하세요. 마지막으로 이 prop들을 `ProductTable`을 걸러내는데, 그리고 `SearchBar` form fields의 값을 세팅하는데 사용하세요. + +이제 어떻게 애플리케이션이 동작하는지 볼 수 있습니다: `filterText`를 `"ball"`로 설정하고 갱신합니다. 자료 테이블이 제대로 업데이트 되는것을 볼 수 있을겁니다. + +## 5단계: 반대방향 자료 흐름을 추가하세요. + + + +앞서 우리는 계층적으로 아랫방향 흐름의 props, state전달로 잘 동작하는 애플리케이션을 만들었습니다. 이제 다른방향의 자료 흐름을 지원할 시간입니다: form 컴포넌트들은 `FilterableProductTable`의 state를 업데이트할 필요성이 있죠. + +React는 어떻게 이 프로그램이 동작하는지 이해하기 쉽게 이 자료의 흐름을 명시적으로 만들어주지만 전통적인 두 방향의 자료 바인딩보다 다소 입력할 것이 많습니다. React는 이러한 패턴을 양방향 바인딩처럼 편하게 사용할 수 있도록 ReactLink를 제공하지만, 이 글의 목적상 명시적인 방식만 사용했습니다. + +지금 예제에 문자열을 입력하거나 체크박스를 체크하더라도 React가 입력을 무시하는것을 볼 수 있습니다. 의도적으로 `input`의 prop에 `value`를 세팅하면 항상 `state`가 `FilterableProductTable`로부터 전달되어야 합니다. + +우리가 원하는게 뭔지 생각해 봅시다. 사용자가 form을 바꿀때마다 사용자 입력을 반영하기 위해 업데이트 하기를 원하죠. 컴포넌트들이 오직 자기 자신의 state만 업데이트 하더라도 `FilterableProductTable`은 state가 변할때마다 반영되어야할 `SearchBar`에 콜백을 전달할것입니다. 이 알림을 위해서 `onChange`이벤트를 사용할 수 있습니다. 그리고 `FilterableProductTable`으로부터 전달된 콜백은 `setState()`를 호출할 것이고, 애플리케이션은 업데이트 될겁니다. + +많은 코드가 필요한 것 같이 들릴 수 있지만 실제로는 몇 줄 되지 않습니다. 그리고 애플리케이션의 구석구석을 데이터가 어떻게 흘러가는지 매우 명확해집니다. + +## 그리고 + +이 글이 컴포넌트와 React로 애플리케이션을 어떻게 만들지에 대한 아이디어가 되길 바랍니다. 원래 하던 것 보다 조금 더 타이핑이 많을진 모르지만, 코드는 쓰는 경우보다 읽히는 경우가 많고 이 코드는 매우 읽기 편하고 명시적인 코드임을 기억하세요. 컴포넌트로 큰 라이브러리를 만들기 시작했다고 할 때, 이 명시성과 모듈성에 감사하게 되고 쓴 줄을 재사용함에 따라 코드의 양도 줄 것입니다. :) From 4df5b776e7a399e21a5d63ffb97e5c198f9d0db4 Mon Sep 17 00:00:00 2001 From: Taeho Kim Date: Fri, 30 Jan 2015 23:19:49 +0900 Subject: [PATCH 09/52] Create ref-01-top-level-api.ko-KR.md Based on 4f50071de0ac1dd6ce6aeda4f3dd9549fb9e36ba --- docs/ref-01-top-level-api.ko-KR.md | 162 +++++++++++++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 docs/ref-01-top-level-api.ko-KR.md diff --git a/docs/ref-01-top-level-api.ko-KR.md b/docs/ref-01-top-level-api.ko-KR.md new file mode 100644 index 00000000..3ee8697d --- /dev/null +++ b/docs/ref-01-top-level-api.ko-KR.md @@ -0,0 +1,162 @@ +--- +id: top-level-api-ko-KR +title: 최상위 API +permalink: top-level-api.ko-KR.html +next: component-api.ko-KR.html +redirect_from: "/docs/reference.ko-KR.html" +--- + +## React + +`React`는 React 라이브러리의 진입점입니다. 미리 빌드된 패키지를 사용하는 경우 전역 변수로 접근할 수 있습니다. CommonJS 모듈을 사용하는 경우에는 `require()`로 불러올 수 있습니다. + + +### React.createClass + +```javascript +ReactClass createClass(object specification) +``` + +주어진 명세에 따라 컴포넌트 클래스를 만듭니다. 컴포넌트는 단 하나의 자식만을 리턴하는 `render` 메소드를 구현합니다. 그 자식은 임의 깊이의 자식 구조를 가질 수 있습니다. 컴포넌트가 일반적인 프로토타입 기반의 클래스와 다른 점은 생성할 때 `new` 연산자를 사용하지 않아도 된다는 것입니다. 컴포넌트는 (`new` 연산자를 통해) 내부 인스턴스를 만들어 주는 편의 래퍼(wrapper)입니다. + +명세 객체에 대한 자세한 정보는 [컴포넌트 명세와 생명주기](/react/docs/component-specs.ko-KR.html)를 참고하세요. + + +### React.createElement + +```javascript +ReactElement createElement( + string/ReactClass type, + [object props], + [children ...] +) +``` + +주어진 타입의 새 `ReactElement`를 만들고 리턴합니다. `type` 인자는 HTML 태그명 문자열 (예: 'div', 'span' 등) 또는 (`React.createClass`로 만든) `ReactClass`입니다. + + +### React.createFactory + +```javascript +factoryFunction createFactory( + string/ReactClass type +) +``` + +주어진 타입의 ReactElement를 만들어주는 함수를 리턴합니다. `React.createElement`와 마찬가지로 `type` 인자는 HTML 태그명 문자열 (예: 'div', 'span' 등) 또는 `ReactClass`입니다. + + +### React.render + +```javascript +ReactComponent render( + ReactElement element, + DOMElement container, + [function callback] +) +``` + +주어진 ReactElement를 `container` 인자에 넘어온 DOM 안에 렌더링하고 컴포넌트의 레퍼런스를 리턴합니다. + +어떤 ReactElement가 이미 `container`에 렌더링 된 적이 있다면, 그것을 업데이트한 뒤 React 컴포넌트의 최신 상태를 반영하기 위해 꼭 필요한 만큼만 DOM을 변경합니다. + +콜백 인자를 넘기면 컴포넌트가 렌더링되거나 업데이트 된 다음 호출됩니다. + +> 주의: +> +> `React.render()`는 넘어온 컨테이너 노드의 내용을 교체합니다. +> 추후에 기존 자식들을 덮어쓰지 않고 이미 있는 DOM 노드에 컴포넌트를 삽입하는 것도 지원할 가능성이 있습니다. + + +### React.unmountComponentAtNode + +```javascript +boolean unmountComponentAtNode(DOMElement container) +``` + +DOM에 마운트된 React 컴포넌트를 제거하고 이벤트 핸들러 및 state를 정리합니다. 컨테이너에 마운트된 컴포넌트가 없는 경우에는 호출해도 아무 동작을 하지 않습니다. 컴포넌트가 마운트 해제된 경우 `true`를, 마운트 해제할 컴포넌트가 없으면 `false`를 리턴합니다. + + +### React.renderToString + +```javascript +string renderToString(ReactElement element) +``` + +주어진 ReactElement의 최초 HTML을 렌더링합니다. 이 함수는 서버에서만 사용해야 합니다. React가 HTML 문자열을 리턴합니다. HTML을 서버에서 생성하고 마크업을 최초 요청에 내려보내서, 페이지 로딩을 빠르게 하거나 검색 엔진이 크롤링할 수 있도록 하는 SEO 목적으로 이 메소드를 사용할 수 있습니다. + +또한 이 메소드로 서버에서 렌더링한 마크업을 포함한 노드에 `React.render()`를 호출하면, React는 마크업을 보존하고 이벤트 핸들러만 붙이므로 최초 로딩을 매우 빠르게 느껴지게 할 수 있습니다. + + +### React.renderToStaticMarkup + +```javascript +string renderToStaticMarkup(ReactElement element) +``` + +`renderToString`와 비슷하지만 `data-react-id`처럼 React에서 내부적으로 사용하는 추가적인 DOM 어트리뷰트를 만들지 않습니다. 추가적인 어트리뷰트를 제거하면 생성되는 마크업의 용량을 줄일 수 있기 때문에 React를 단순한 정적 페이지 생성기로 사용할 때 유용합니다. + + +### React.isValidElement + +```javascript +boolean isValidElement(* object) +``` + +주어진 객체가 ReactElement인지 확인합니다. + + +### React.DOM + +`React.DOM`은 DOM 컴포넌트에 대해 `React.createElement`의 편의 래퍼(wrapper)를 제공합니다. JSX를 사용하지 않는 경우에만 사용하십시오. 예를 들어, `React.DOM.div(null, 'Hello World!')`와 같이 사용할 수 있습니다. + + +### React.PropTypes + +`React.PropTypes`는 컴포넌트에 넘어오는 props가 올바른지 검사할 수 있는 컴포넌트의 `propTypes` 객체에 들어가는 타입을 가집니다. `propTypes`에 대한 자세한 정보는 [재사용 가능한 컴포넌트](/react/docs/reusable-components.ko-KR.html)를 참고하세요. + + +### React.initializeTouchEvents + +```javascript +initializeTouchEvents(boolean shouldUseTouch) +``` + +React의 이벤트 시스템이 모바일 기기의 터치 이벤트를 처리하도록 설정합니다. + + +### React.Children + +`React.Children`은 불투명한 자료 구조인 `this.props.children`를 다룰 수 있는 유틸리티를 제공합니다. + +#### React.Children.map + +```javascript +object React.Children.map(object children, function fn [, object context]) +``` + +`children`의 바로 밑에 있는 모든 자식에 `fn`을 호출합니다. 이 때 `this`는 `context`로 설정됩니다. `children`이 중첩된 객체나 배열일 경우 그 안의 값을 순회합니다. 따라서 `fn`에 컨테이너 객체가 넘어가는 일은 일어나지 않습니다. `children`이 `null`이거나 `undefined`면 빈 객체 대신 `null` 또는 `undefined`를 리턴합니다. + +#### React.Children.forEach + +```javascript +React.Children.forEach(object children, function fn [, object context]) +``` + +`React.Children.map()`과 비슷하지만 객체를 리턴하지 않습니다. + +#### React.Children.count + +```javascript +number React.Children.count(object children) +``` + +`children`에 들어있는 컴포넌트의 총 갯수를 리턴합니다. 이 갯수는 `map`이나 `forEach`에 넘긴 콜백이 호출되는 횟수와 동일합니다. + +#### React.Children.only + +```javascript +object React.Children.only(object children) +``` + +`children`에 단 하나의 자식이 있을 때 그 자식을 리턴합니다. 그 밖의 경우에는 예외를 발생시킵니다. From 5e56735cd3d8e8b7ab99b6acc89ee0371dbf87d9 Mon Sep 17 00:00:00 2001 From: Taeho Kim Date: Sat, 31 Jan 2015 00:02:44 +0900 Subject: [PATCH 10/52] Create ref-02-component-api.ko-KR.md --- docs/ref-02-component-api.ko-KR.md | 96 ++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 docs/ref-02-component-api.ko-KR.md diff --git a/docs/ref-02-component-api.ko-KR.md b/docs/ref-02-component-api.ko-KR.md new file mode 100644 index 00000000..b0d57545 --- /dev/null +++ b/docs/ref-02-component-api.ko-KR.md @@ -0,0 +1,96 @@ +--- +id: component-api-ko-KR +title: 컴포넌트 API +permalink: component-api.ko-KR.html +prev: top-level-api.ko-KR.html +next: component-specs.ko-KR.html +--- + +## ReactComponent + +React 컴포넌트의 인스턴스는 React가 렌더링 시에 내부적으로 만듭니다. 이때 만들어진 인스턴스는 이후의 렌더링에서 다시 사용되고 컴포넌트의 메소드들에서 `this` 변수로 접근할 수 있습니다. React 외부에서 React 컴포넌트의 핸들을 얻는 방법은 `React.render`의 리턴값을 저장하는 것이 유일합니다. 다른 컴포넌트 안에서 비슷한 결과를 얻으려면 [refs](/react/docs/more-about-refs.ko-KR.html)를 사용해야 합니다. + + +### setState + +```javascript +setState(object nextState[, function callback]) +``` + +`nextState`를 현재 state에 합칩니다. 이벤트 핸들러와 서버 요청 콜백에서 UI 업데이트를 발생시키기 위해 이 메소드를 주로 사용합니다. 콜백 함수를 추가로 넘기면 `setState`가 완료되고 컴포넌트가 다시 렌더링된 다음에 한번 호출됩니다. + +> 주의: +> +> *절대로* `this.state`를 직접 변경하지 마세요. 그 뒤에 `setState()`를 호출하면 그동안 변경했던 것이 교체될 수 있습니다. `this.state`는 변경 불가능한 것으로 생각하시는 것이 좋습니다. +> +> `setState()`를 호출해도 `this.state`가 곧바로 변경되지 않고 대기 중인 state transition이 만들어집니다. 이 메소드를 호출한 직후 `this.state`에 접근하면 바뀌기 전의 값을 리턴할 가능성이 있습니다. +> +> `setState`에 대한 호출이 동기적으로 처리된다는 보장이 없으며, 성능 향상을 위해 배치 처리될 수 있습니다. +> +> `setState()`는 `shouldComponentUpdate()`에 조건부 렌더링 로직이 구현되어 있지 않다면 항상 재렌더링을 발생시킵니다. 변경 가능한 객체를 사용하고 있고 조건부 렌더링 로직을 `shouldComponentUpdate()`에 구현할 수 없는 경우라면 새로운 state가 이전 state와 달라지는 경우에만 `setState()`를 호출하여 불필요한 재렌더링을 피할 수 있습니다. + + +### replaceState + +```javascript +replaceState(object nextState[, function callback]) +``` + +`setState()`와 비슷하지만 기존에 존재하는 state 중 nextState에 없는 키는 모두 삭제됩니다. + + +### forceUpdate() + +```javascript +forceUpdate([function callback]) +``` + +`render()` 메소드가 `this.props`나 `this.state`가 아닌 다른 곳에서 데이터를 읽어오는 경우 `forceUpdate()`를 호출하여 React가 `render()`를 다시 실행하도록 만들 수 있습니다. `this.state`를 직접 변경하는 경우에도 `forceUpdate()`를 호출해야 합니다. + +`forceUpdate()`를 호출하면 해당 컴포넌트와 그 자식들의 `render()` 함수가 호출되지만, React는 마크업이 변경된 경우에만 DOM을 업데이트합니다. + +특별한 경우가 아니면 `forceUpdate()`는 되도록 피하시고 `render()`에서는 `this.props`와 `this.state`에서만 읽어오세요. 그렇게 하는 것이 애플리케이션을 훨씬 단순하고 효율적으로 만들어줍니다. + + +### getDOMNode + +```javascript +DOMElement getDOMNode() +``` + +이 컴포넌트가 DOM에 마운트된 경우 해당하는 네이티브 브라우저 DOM 요소를 리턴합니다. 이 메소드는 폼 필드의 값이나 DOM의 크기/위치 등 DOM에서 정보를 읽을 때 유용합니다. `render`가 `null`이나 `false`를 리턴하였다면 `this.getDOMNode()`는 `null`을 리턴합니다. + + +### isMounted() + +```javascript +bool isMounted() +``` + +`isMounted()`는 컴포넌트가 DOM에 렌더링되었으면 true를, 아니면 false를 리턴합니다. 비동기적으로 `setState()`나 `forceUpdate()`를 호출할 때 이 메소드를 사용하여 오류를 방지할 수 있습니다. + + +### setProps + +```javascript +setProps(object nextProps[, function callback]) +``` + +외부 JavaScript 애플리케이션과 연동하는 경우 `React.render()`로 렌더링된 React 컴포넌트에 변경을 알리고 싶을 때가 있습니다. + +최상위 컴포넌트를 업데이트할 때 `React.render()`를 같은 노드에 다시 호출하는 것이 바람직한 방법이지만, `setProps()`를 호출해서 props를 바꾸고 재렌더링을 발생시킬 수 있습니다. 콜백 함수를 추가로 넘기면 `setProps`가 완료되고 컴포넌트가 다시 렌더링된 다음에 한번 호출됩니다. + +> 주의: +> +> 가능하다면 `React.render()`를 다시 호출하는 선언적인 방법이 더 바람직합니다. 그렇게 하는 편이 업데이트에 대해 생각하는 것을 쉽게 만듭니다. (두가지 방식에 눈에 띄는 성능 차이는 없습니다.) +> +> 이 메소드는 최상위 컴포넌트에만 호출 가능합니다. 다시 말해, `React.render()`에 바로 넘긴 컴포넌트에서만 사용할 수 있고 자식에서는 불가능합니다. 자식 컴포넌트에 `setProps()`를 사용하고 싶다면, 그 대신 반응적인 업데이트의 장점을 활용하여 `render()` 안에서 자식 컴포넌트를 만들 때 새로운 prop을 넘기세요. + + +### replaceProps + +```javascript +replaceProps(object nextProps[, function callback]) +``` + +`setProps()`와 비슷하지만 두 객체를 합치는 대신 이전에 존재하던 props를 삭제합니다. From 11d6c029c5fc6b9c3c8e03a870f88b9c1ab77bcb Mon Sep 17 00:00:00 2001 From: Taeho Kim Date: Sat, 31 Jan 2015 01:01:29 +0900 Subject: [PATCH 11/52] Create ref-03-component-specs.ko-KR.md Based on 08c5e42649c85048b9035b3485c7b675e99ade3c --- docs/ref-03-component-specs.ko-KR.md | 215 +++++++++++++++++++++++++++ 1 file changed, 215 insertions(+) create mode 100644 docs/ref-03-component-specs.ko-KR.md diff --git a/docs/ref-03-component-specs.ko-KR.md b/docs/ref-03-component-specs.ko-KR.md new file mode 100644 index 00000000..f8697c0c --- /dev/null +++ b/docs/ref-03-component-specs.ko-KR.md @@ -0,0 +1,215 @@ +--- +id: component-specs-ko-KR +title: 컴포넌트 명세와 생명주기 +permalink: component-specs.ko-KR.html +prev: component-api.ko-KR.html +next: tags-and-attributes.ko-KR.html +--- + +## 컴포넌트 명세 + +`React.createClass()`를 호출하여 컴포넌트 클래스를 생성할 때, `render` 메소드를 포함한 명세 객체를 제공해야 합니다. 또한 필요한 경우 여기에서 설명하는 다른 생명주기 메소드를 명세 객체에 추가로 제공할 수 있습니다. + + +### render + +```javascript +ReactComponent render() +``` + +`render()` 메소드는 필수 항목입니다. + +호출되면 `this.props`와 `this.state`를 토대로 하나의 자식 컴포넌트를 리턴합니다. 이 자식 컴포넌트는 네이티브 DOM 컴포넌트의 가상 표현 (`
`나 `React.DOM.div()` 등) 또는 직접 정의한 조합(composite) 컴포넌트가 될 수 있습니다. + +아무 것도 렌더링되지 않도록 하려면 `null`이나 `false`를 리턴합니다. React는 지금의 차이 비교 알고리즘이 작동할 수 있도록 내부적으로는 `