From 9fd9487df1c46b1347315160fbbee78e5fd3b162 Mon Sep 17 00:00:00 2001 From: Jay Jaeho Lee Date: Tue, 24 Feb 2015 00:56:02 +0900 Subject: [PATCH] Revise Korean translations --- docs/02.1-jsx-in-depth.ko-KR.md | 20 +++---- docs/02.2-jsx-spread.ko-KR.md | 4 +- docs/02.3-jsx-gotchas.ko-KR.md | 8 +-- .../03-interactivity-and-dynamic-uis.ko-KR.md | 20 +++---- docs/04-multiple-components.ko-KR.md | 16 +++--- docs/07-forms.ko-KR.md | 5 +- docs/09-tooling-integration.ko-KR.md | 4 +- docs/10-addons.ko-KR.md | 8 +-- docs/10.6-update.ko-KR.md | 18 +++---- docs/examples.ko-KR.md | 4 +- docs/flux-overview.ko-KR.md | 3 +- docs/flux-overview.md | 1 + docs/flux-todo-list.ko-KR.md | 3 +- docs/flux-todo-list.md | 1 + docs/ref-04-tags-and-attributes.ko-KR.md | 4 +- docs/ref-05-events.ko-KR.md | 6 +-- docs/ref-06-dom-differences.ko-KR.md | 4 +- docs/ref-09-glossary.ko-KR.md | 4 +- docs/thinking-in-react.ko-KR.md | 52 +++++++++---------- docs/tutorial.ko-KR.md | 42 +++++++-------- docs/videos.ko-KR.md | 8 +-- 21 files changed, 117 insertions(+), 118 deletions(-) diff --git a/docs/02.1-jsx-in-depth.ko-KR.md b/docs/02.1-jsx-in-depth.ko-KR.md index 0bd4a06c..962e0837 100644 --- a/docs/02.1-jsx-in-depth.ko-KR.md +++ b/docs/02.1-jsx-in-depth.ko-KR.md @@ -73,12 +73,9 @@ var app = React.createElement( ); ``` -[JSX 컴파일러](/react/jsx-compiler.html)를 사용해보면 JSX에서 어떻게 네이티브 -JavaScript로 변환하는지(desugars) 볼 수 있고, -[HTML에서 JSX 변환기](/react/html-jsx.html)는 이미 있는 HTML을 JSX로 변환해 -줍니다. +[JSX 컴파일러](/react/jsx-compiler.html)를 보면 JSX에서 어떻게 네이티브 JavaScript로 변환(desugars)하는지 볼 수 있고, [HTML-JSX 변환기](/react/html-jsx.html)는 이미 있는 HTML을 JSX로 변환해 줍니다. -JSX를 사용 하시려면, [시작하기](/react/docs/getting-started-ko-KR.html) 가이드에서 어떻게 컴파일을 설정하는지 보실 수 있습니다. +JSX를 사용 하시려면, [시작하기](/react/docs/getting-started-ko-KR.html) 가이드에서 어떻게 컴파일을 하기 위해 설정하는지 보실 수 있습니다. > 주의: > @@ -136,9 +133,9 @@ MyFormComponent.Input = React.createClass({ ... }); ```javascript var App = ( - React.createElement(Form, null, - React.createElement(Form.Row, null, - React.createElement(Form.Label, null), + React.createElement(Form, null, + React.createElement(Form.Row, null, + React.createElement(Form.Label, null), React.createElement(Form.Input, null) ) ) @@ -153,8 +150,7 @@ var App = ( ### 어트리뷰트 표현식 -JavaScript 표현식을 어트리뷰트 값으로 사용하려면, 표현식을 쌍따옴표(`""`)대신 -중괄호(`{}`)로 감싸야 합니다. +JavaScript 표현식을 어트리뷰트 값으로 사용하려면, 표현식을 쌍따옴표(`""`)대신 중괄호(`{}`)로 감싸야 합니다. ```javascript // 입력 (JSX): @@ -168,7 +164,7 @@ var person = React.createElement( ### 자식 표현식 -비슷하게, JavaScript 표현식은 자식을 표현하는 데 사용할 수 있습니다. +비슷하게, JavaScript 표현식을 자식을 표현하는 데 사용할 수 있습니다. ```javascript // 입력 (JSX): @@ -200,5 +196,5 @@ var content = ( ``` > 주의: -> +> > JSX 는 HTML과 비슷하지만 완전히 같지는 않습니다. 중요한 차이점을 보시려면 [JSX gotchas](/react/docs/jsx-gotchas-ko-KR.html)를 보세요. diff --git a/docs/02.2-jsx-spread.ko-KR.md b/docs/02.2-jsx-spread.ko-KR.md index d32a37c7..57828ad9 100644 --- a/docs/02.2-jsx-spread.ko-KR.md +++ b/docs/02.2-jsx-spread.ko-KR.md @@ -28,7 +28,7 @@ next: jsx-gotchas-ko-KR.html ## 스프레드 어트리뷰트 -이제 JSX 새로운 기능 스프레드 어트리뷰트를 사용하실 수 있습니다. +이제 JSX의 새로운 기능인 스프레드 어트리뷰트를 사용하실 수 있습니다. ```javascript var props = {}; @@ -39,7 +39,7 @@ next: jsx-gotchas-ko-KR.html 전달한 객체의 프로퍼티가 컴포넌트의 props에 복사됩니다. -이 것은 여러 번 사용하거나 다른 어트리뷰트와 조합해서 사용할 수 있습니다. 명세 순서는 중요합니다. 나중의 어트리뷰트가 이전 것보다 우선되기 때문입니다. +이렇게 여러 번 사용하거나 다른 어트리뷰트와 조합해서 사용할 수 있습니다. 명세의 순서는 중요합니다. 나중의 어트리뷰트가 이전 것보다 우선되기 때문입니다. ```javascript var props = { foo: 'default' }; diff --git a/docs/02.3-jsx-gotchas.ko-KR.md b/docs/02.3-jsx-gotchas.ko-KR.md index 64880a34..da39cf85 100644 --- a/docs/02.3-jsx-gotchas.ko-KR.md +++ b/docs/02.3-jsx-gotchas.ko-KR.md @@ -6,11 +6,11 @@ prev: jsx-spread-ko-KR.html next: interactivity-and-dynamic-uis-ko-KR.html --- -JSX는 HTML처럼 보이지만 하다 보면 부딪히게 될 몇 가지 중요한 차이점이 있습니다. +JSX는 HTML처럼 보이지만, 작업하다 보면 마주치게 될 몇 가지 중요한 차이점이 있습니다. > 주의: > -> 인라인 `style` 어트리뷰트 같은 DOM 차이점은 [여기](/react/docs/dom-differences-ko-KR.html)를 보세요. +> 인라인 `style` 어트리뷰트 같은 DOM과의 차이점은 [여기](/react/docs/dom-differences-ko-KR.html)를 보세요. ## HTML 엔티티 @@ -20,7 +20,7 @@ JSX의 리터럴 텍스트에 HTML 엔티티를 넣을 수 있습니다.
First · Second
``` -동적 콘텐츠 안에 HTML 엔티티를 표시하려 할 때, React에서는 XSS 공격을 광범위하게 막기 위해 기본적으로 모든 표시하는 문자열을 이스케이프 하기 때문에 더블 이스케이프 문제에 부딪히게 됩니다. +동적 콘텐츠 안에 HTML 엔티티를 표시하려 할 때, React에서는 XSS 공격을 광범위하게 막기 위해서 기본적으로 모든 표시하는 문자열을 이스케이프 하기 때문에 더블 이스케이프 문제에 부딪히게 됩니다. ```javascript // 나쁨: "First · Second"를 표시 @@ -46,7 +46,7 @@ JSX의 리터럴 텍스트에 HTML 엔티티를 넣을 수 있습니다.
{['First ', ·, ' Second']}
``` -최후의 수단으로, 항상 [생 HTML을 삽입](/react/docs/dom-differences-ko-KR.html)할 수는 있습니다. +최후의 수단으로, 항상 [생 HTML을 삽입](/react/docs/dom-differences-ko-KR.html)할 수 있습니다. ```javascript
diff --git a/docs/03-interactivity-and-dynamic-uis.ko-KR.md b/docs/03-interactivity-and-dynamic-uis.ko-KR.md index 5c8b2288..cd9681c3 100644 --- a/docs/03-interactivity-and-dynamic-uis.ko-KR.md +++ b/docs/03-interactivity-and-dynamic-uis.ko-KR.md @@ -40,16 +40,16 @@ React.render( React에서의 이벤트 핸들러는 HTML에서 그러던 것처럼 간단히 카멜케이스 프로퍼티(camelCased prop)로 넘기면 됩니다. React의 모든 이벤트는 통합적인 이벤트 시스템의 구현으로 IE8 이상에서는 같은 행동이 보장됩니다. 즉, React는 사양에 따라 어떻게 이벤트를 일으키고(bubble) 잡는지 알고 있고, 당신이 사용하는 브라우저와 관계없이 이벤트 핸들러에 전달되는 이벤트는 [W3C 사양](http://www.w3.org/TR/DOM-Level-3-Events/)과 같도록 보장됩니다. -React를 폰이나 테블릿같은 터치 디바이스에서 사용하려 한다면, 간단히 `React.initializeTouchEvents(true);`로 터치 이벤트 핸들링을 켜면 됩니다. +React를 폰이나 테블릿같은 터치 디바이스에서 사용하려 한다면, 간단히 `React.initializeTouchEvents(true);`로 터치 이벤트 핸들링을 켜면 됩니다. -## 기본 구현: 오토바인딩과 이벤트 딜리게이션 +## 기본 구현: 오토바인딩과 이벤트 델리게이션 -코드를 고성능으로 유지하고 이해하기 쉽게 하기 위해 React는 안 보이는 곳에서 몇 가지 일을 합니다. +코드를 고성능으로 유지하고 이해하기 쉽게 하기 위해, React는 보이지 않는 곳에서 몇 가지 일을 수행합니다. -**오토바인딩:** 자바스크립트에서 콜백을 만들 때, 보통은 `this`의 값이 정확하도록 명시적으로 메서드를 인스턴스에 바인드해야 합니다. React에서는 모든 메서드가 자동으로 React의 컴포넌트 인스턴스에 바인드됩니다. React가 바인드 메서드를 캐시하기 때문에 매우 CPU와 메모리에 효율적입니다. 타이핑해야 할 것도 적죠! +**오토바인딩:** 자바스크립트에서 콜백을 만들 때, 보통은 `this`의 값이 정확하도록 명시적으로 메서드를 인스턴스에 바인드해야 합니다. React에서는 모든 메서드가 자동으로 React의 컴포넌트 인스턴스에 바인드됩니다. React가 바인드 메서드를 캐시하기 때문에 매우 CPU와 메모리에 효율적입니다. 타이핑해야 할 것도 줄어들죠! -**이벤트 딜리게이션:** React는 실제로는 노드자신에게 이벤트 핸들러를 붙이지 않습니다. React가 시작되면 React는 탑 레벨의 단일 이벤트 리스너로 모든 이벤트를 리스닝하기 시작합니다. 컴포넌트가 마운트되거나 언마운트 될 때, 이벤트 핸들러는 그냥 내부 매핑에서 넣거나 뺄 뿐입니다. 이벤트가 발생하면, React는 이 매핑을 사용해서 어떻게 디스패치할 지를 알게 됩니다. 매핑에 이벤트 핸들러가 남아있지 않으면, React의 이벤트 핸들러는 그냥 아무것도 하지 않습니다. 왜 이 방식이 빠른지 더 알고 싶으시면, [David Walsh의 멋진 블로그 글](http://davidwalsh.name/event-delegate)을 읽어 보세요. +**이벤트 델리게이션:** React는 실제로는 노드자신에게 이벤트 핸들러를 붙이지 않습니다. React가 시작되면 React는 탑 레벨의 단일 이벤트 리스너로 모든 이벤트를 리스닝하기 시작합니다. 컴포넌트가 마운트되거나 언마운트 될 때, 이벤트 핸들러는 그냥 내부 매핑에서 넣거나 뺄 뿐입니다. 이벤트가 발생하면, React는 이 매핑을 사용해서 어떻게 디스패치할 지를 알게 됩니다. 매핑에 이벤트 핸들러가 남아있지 않으면, React의 이벤트 핸들러는 그냥 아무것도 하지 않습니다. 왜 이 방식이 빠른지 더 알고 싶으시면, [David Walsh의 멋진 블로그 글](http://davidwalsh.name/event-delegate)을 읽어 보세요. ## 컴포넌트는 그냥 state 머신일 뿐 @@ -61,7 +61,7 @@ React에서는, 간단히 컴포넌트의 state를 업데이트하고, 이 새 ## state의 동작 원리 -React에게 데이터의 변경을 알리는 일반적인 방법은 `setState(data, callback)`을 호출하는 것입니다. 이 메서드는 `this.state`에 `data`를 머지하고 컴포넌트를 재 렌더링 합니다. 컴포넌트의 재 렌더링이 끝나면, 생략가능한 `callback`이 호출됩니다. 대부분의 경우 React가 UI를 최신상태로 유지해주기 때문에 `callback`을 사용할 필요가 없습니다. +React에게 데이터의 변경을 알리는 일반적인 방법은 `setState(data, callback)`을 호출하는 것입니다. 이 메서드는 `this.state`에 `data`를 머지하고 컴포넌트를 다시 렌더링 합니다. 컴포넌트의 재-렌더링이 끝나면, 생략가능한 `callback`이 호출됩니다. 대부분의 경우 React가 UI를 최신상태로 유지해주기 때문에 `callback`을 사용할 필요가 없습니다. ## 어떤 컴포넌트가 state를 가져야 할까요? @@ -75,12 +75,12 @@ React에게 데이터의 변경을 알리는 일반적인 방법은 `setState(da ## state를 어떻게 *써야* 할까요? -**state는 컴포넌트의 이벤트 핸들러에 의해 UI 업데이트를 트리거할때 변경될 가능성이 있어, 그때 사용할 데이터를 가져야 합니다.** 실제 엡에서는 이 데이터는 매우 작고 JSON 직렬화 가능한 경향이 있습니다. 상태기반 컴포넌트를 만들때, 가능한 작게 state를 서술하고 `this.state`에만 저장하도록 해보세요. 그냥 `render()` 안에서 이 state를 기반으로 다른 모든 정보를 계산합니다. 이 방식으로 애플리케이션을 작성하고 생각하면 가장 최적의 애플리케이션으로 발전해가는 경향이 있다는 것을 발견하게 될것입니다. 장황하거나 계산된 값을 state에 추가하는 것은 렌더가 그것을 계산하는 대신에 명시적으로 그것들을 싱크해야 하는 것을 의미하기 때문이죠. +**state는 컴포넌트의 이벤트 핸들러에 의해 UI 업데이트를 트리거할때 변경될 가능성이 있어, 그때 사용할 데이터를 가져야 합니다.** 실제 앱에서는 이 데이터는 매우 작고 JSON 직렬화 가능한 경향이 있습니다. 상태기반 컴포넌트를 만들때, 가능한 작게 state를 서술하고 `this.state`에만 저장하도록 해보세요. 그냥 `render()` 안에서 이 state를 기반으로 다른 모든 정보를 계산합니다. 이 방식으로 애플리케이션을 작성하고 생각하면 가장 최적의 애플리케이션으로 발전해가는 경향이 있다는 것을 발견하게 될 것입니다. 꼭 필요하지 않은 값이나 계산된 값을 state에 추가하는 것은 render가 그것을 계산하는 대신에 명시적으로 그것들을 맞춰줘야 하는 것을 의미하기 때문이죠. ## state를 어떻게 *쓰지 말아야* 할까요? -`this.state`는 UI의 state를 표현할 최소한의 데이터만 가져야 합니다. 그래서 이런것을들 가지지 말아야 합니다. +`this.state`는 UI의 state를 표현할 최소한의 데이터만을 가져야 합니다. 그래서 이런 것들을 가지지 않게끔 해야 합니다. -* **계산된 데이터:** state에 따라 값을 미리 계산하는 것을 염려하지 마세요. 계산은 모두 `render()`에서 하는 것이 UI의 일관성을 유지하기 쉽습니다. 예를 들어, state에서 list items 배열을 가지고 있고 문자열으로 카운트를 렌더링 할 경우, state에 저장하기보다는 그냥 `render()` 메서드안에서 `this.state.listItems.length + ' list items'`를 렌더하세요. +* **계산된 데이터:** state에 따라 값을 미리 계산하는 것에 대해 염려하지 마세요. 계산은 모두 `render()`에서 하는 것이 UI의 일관성을 유지하기 쉽습니다. 예를 들어, state에서 list items 배열을 가지고 있고 문자열으로 카운트를 렌더링 할 경우, state에 저장하기보다는 그냥 `render()` 메서드안에서 `this.state.listItems.length + ' list items'`를 렌더하세요. * **React 컴포넌트:** 가지고 있는 props와 state로 `render()`안에서 만드세요. -* **props에서 복사한 데이터:** 가능한한 원래의 소스로 props를 사용하도록 해보세요. props를 state에 저장하는 단하나의 올바른 사용법은 이전 값을 알고 싶을 때입니다. props는 시간이 지나면 변경될 수도 있기 때문이죠. +* **props에서 복사한 데이터:** 가능한 한 원래의 소스로 props를 사용하도록 해보세요. props를 state에 저장하는 단 하나의 올바른 사용법은 이전 값을 알고 싶을 때입니다. props는 시간이 지나면 변경될 수도 있기 때문이죠. diff --git a/docs/04-multiple-components.ko-KR.md b/docs/04-multiple-components.ko-KR.md index badfbff5..e9196ffa 100644 --- a/docs/04-multiple-components.ko-KR.md +++ b/docs/04-multiple-components.ko-KR.md @@ -57,7 +57,7 @@ React.render( ## 소유권(Ownership) -위의 예제에서, `Avatar` 인스턴스는 `ProfilePic`과 `ProfileLink`인스턴스를 *가지고* 있습니다. React에서 **소유자는 다른 컴포넌트의 `props`를 설정하는 컴포넌트입니다**. 더 정식으로 말하면, `X` 컴포넌트가 `Y` 컴포넌트의 `render()` 메서드 안에서 만들어졌다면, `Y`가 `X`를 *소유하고* 있다고 합니다. 앞에서 설명한 바와 같이, 컴포넌트는 자신의 `props`를 변경할 수 없습니다. `props`는 언제나 소유자가 설정한 것과 일치합니다. 이와 같은 중요한 성질이 UI가 일관성 있도록 해줍니다. +위의 예제에서, `Avatar` 인스턴스는 `ProfilePic`과 `ProfileLink`인스턴스를 *가지고* 있습니다. React에서 **소유자는 다른 컴포넌트의 `props`를 설정하는 컴포넌트입니다**. 더 정식으로 말하면, `X` 컴포넌트가 `Y` 컴포넌트의 `render()` 메서드 안에서 만들어졌다면, `Y`가 `X`를 *소유하고* 있다고 합니다. 앞에서 설명한 바와 같이, 컴포넌트는 자신의 `props`를 변경할 수 없습니다. `props`는 언제나 소유자가 설정한 것과 일치합니다. 이와 같은 중요한 성질은 UI가 일관성 있도록 해줍니다. 소유(owner-ownee)관계와 부모·자식 관계를 구별하는 것은 중요합니다. 부모·자식 관계가 DOM에서부터 쓰던 익숙하고 이미 알고있던 단순한 것인 한편, 소유관계는 React 고유의 것입니다. 위의 예제에서, `Avatar`는 `div`, `ProfilePic`, `ProfileLink`인스턴스를 소유하고, `div`는 `ProfilePic`과 `ProfileLink`인스턴스의 (소유자가 아닌) **부모**입니다. @@ -73,9 +73,9 @@ React 컴포넌트 인스턴스를 만들 때, 추가적인 React 컴포넌트 `Parent`는 `this.props.children`라는 특수 prop으로 자식들을 읽을 수 있습니다. **`this.props.children` 는 불투명한 데이터 구조이며,** [React.Children 유틸리티](/react/docs/top-level-api-ko-KR.html#react.children)를 사용해 자식들을 관리합니다. -### 자식 Reconciliation +### 자식 Reconciliation (비교조정) -**Reconciliation은 React가 DOM을 각각 새로운 렌더 패스에 업데이트하는 과정입니다.** 일반적으로, 자식은 렌더하는 순서에 따라 비교조정됩니다. 예를 들어, 각각의 마크업을 생성하는 두 랜더 패스가 있다고 해봅시다. +**Reconciliation은 React가 DOM을 각각 새로운 렌더 패스에 업데이트하는 과정입니다.** 일반적으로, 자식은 렌더하는 순서에 따라 비교조정됩니다. 예를 들어, 각각의 마크업을 생성하는 두 개의 랜더 패스가 있다고 해봅시다. ```html // Render Pass 1 @@ -114,7 +114,7 @@ React 컴포넌트 인스턴스를 만들 때, 추가적인 React 컴포넌트 ### 동적 자식 -자식들이 섞이거나(검색의 결과같은 경우) 새로운 컴포넌트가 리스트의 앞에 추가(스트림같은 경우)된다면 상황은 점점 더 까다로워집니다. 이런 때에의 동일성과 각 자식의 상태는 반드시 랜더 패스 간에 유지돼야 합니다. 각 자식에 `key`를 할당 함으로써 독자적으로 식별할 수 있습니다. +자식들이 섞이거나(검색의 결과같은 경우) 새로운 컴포넌트가 리스트의 앞에 추가(스트림같은 경우)된다면 상황은 점점 더 까다로워집니다. 이런 때에의 동일성과 각 자식의 상태는 반드시 랜더 패스 간에 유지돼야 합니다. 각 자식에 `key`를 할당 함으로써 독자적으로 식별할 수 있습니다. ```javascript render: function() { @@ -171,7 +171,7 @@ var MyComponent = React.createClass({ }); ``` -객체를 넘기는 것으로 자식에 키를 할당할 수도 있습니다. 객체 키는 각 값의 `key`로 사용될 것입니다. 하지만 JavaScript가 프로퍼티의 순서의 유지를 보장하지 않는 것을 기억해 두셔야 합니다. 실제 브라우저에서는 32비트의 양의 정수로 해석할 수 있는 프로퍼티를 **제외**하고 프로퍼티의 순서를 유지합니다. 숫자 프로퍼티는 다른 프로퍼티보다 먼저 순차정렬 됩니다. 이런 경우 React는 순서없이 컴포넌트를 렌더합니다. 키에 스트링 접두사를 붙여서 이를 막을 수 있습니다. +객체를 넘기는 것으로 자식에 키를 할당할 수도 있습니다. 객체 키는 각 값의 `key`로 사용될 것입니다. 하지만 JavaScript가 프로퍼티의 순서의 유지를 보장하지 않는 것을 기억해 두셔야 합니다. 실제 브라우저에서는 32비트의 양의 정수로 해석할 수 있는 프로퍼티를 **제외**하고 프로퍼티의 순서를 유지합니다. 숫자 프로퍼티는 다른 프로퍼티보다 먼저 순차정렬 됩니다. 이런 경우 React는 순서없이 컴포넌트를 렌더합니다. 키에 스트링 접두사를 붙여서 이를 막을 수 있습니다. ```javascript render: function() { @@ -199,10 +199,10 @@ React에서 데이터는 위에서 말한 것처럼 `props`를 통해 소유자 ## 성능의 주의점 -소유자가 가지고 있는 노드의 수가 많아지면 데이터의 변화에 반응하는 비용이 증가할 것으로 생각할 수도 있습니다. 좋은 소식은 JavaScript가 빠르고 `render()` 메서드는 꽤 간단한 경향이 있어, 대부분 애플리케이션에서 매우 빠르다는 점입니다. 덧붙여, 대부분의 병목 현상은 JS 실행이 아닌 DOM 변경에서 일어나고, React는 배치와 탐지 변경을 이용해 최적화해 줍니다. +소유자가 가지고 있는 노드의 수가 많아지면 데이터의 변화에 반응하는 비용이 증가할 것으로 생각할 수도 있습니다. 좋은 소식은 JavaScript의 속도는 빠르고 `render()` 메서드는 꽤 간단한 경향이 있어, 대부분 애플리케이션에서 매우 빠르다는 점입니다. 덧붙여, 대부분의 병목 현상은 JS 실행이 아닌 DOM 변경에서 일어나고, React는 배치와 탐지 변경을 이용해 최적화해 줍니다. -하지만, 가끔 성능을 위해 정교하게 제어해야 할 때도 있습니다. 이런 경우,React가 서브트리의 처리를 건너 뛰도록 간단히 `shouldComponentUpdate()`를 오버라이드해 false를 리턴하게 할 수 있습니다. 좀 더 자세한 정보는 [React 참조 문서](/react/docs/component-specs-ko-KR.html)를 보세요. +하지만, 가끔 성능을 위해 정교하게 제어해야 할 때도 있습니다. 이런 경우, React가 서브트리의 처리를 건너 뛰도록 간단히 `shouldComponentUpdate()`를 오버라이드해 false를 리턴하게 할 수 있습니다. 좀 더 자세한 정보는 [React 참조 문서](/react/docs/component-specs-ko-KR.html)를 보세요. > 주의: > -> 데이터가 실제로는 변경되었지만 `shouldComponentUpdate()`가 false를 리턴한다면 React는 UI를 싱크시킬수 없습니다. 이 기능을 사용할 때에는 지금 무엇을 하고 있는지 알고있고, 눈에 띄는 성능 문제가 있을경우에만 사용하세요. JavaScript는 DOM에 비교하여 빠릅니다. 과소평가하지 마세요. +> 데이터가 실제로는 변경되었지만 `shouldComponentUpdate()`가 false를 리턴한다면 React는 UI를 싱크시킬수 없습니다. 이 기능을 사용할 때에는 자신이 지금 무엇을 하고 있는지 알고 있고, 눈에 띄는 성능 문제가 있을 경우에만 사용하세요. JavaScript는 DOM에 비해 빠릅니다. 과소평가하지 마세요. diff --git a/docs/07-forms.ko-KR.md b/docs/07-forms.ko-KR.md index 16d5a2e4..97d379bc 100644 --- a/docs/07-forms.ko-KR.md +++ b/docs/07-forms.ko-KR.md @@ -101,10 +101,9 @@ React에서 ``같은 폼 컴포넌트를 사용하면, 전통적인 폼 H ``` -이렇게 하면 input은 `Untitled` 값으로 *초기화* 됩니다. 사용자가 input을 업데이트할 때, 노드의 value *프로퍼티*가 변경될 것입니다. 하지만, `node.getAttribute('value')`은 여전히 초기화 때 사용했던 값인 `Untitled`를 리턴합니다. +이렇게 하면 input은 `Untitled` 값으로 *초기화* 됩니다. 사용자가 input을 업데이트할 때, 노드의 value *프로퍼티*가 변경될 것입니다. 하지만, `node.getAttribute('value')`은 여전히 초기화 때 사용했던 값인 `Untitled`를 리턴합니다. -HTML과 다르게, React 컴포넌트는 초기화 시점 뿐만 아니라, 어떤 시점이라도 반드시 -뷰의 state를 나타내야 합니다. 예를 들어 React에서 +HTML과 다르게, React 컴포넌트는 초기화 시점 뿐만 아니라, 어떤 시점이라도 반드시 뷰의 state를 나타내야 합니다. 예를 들어 React에서 ```javascript render: function() { diff --git a/docs/09-tooling-integration.ko-KR.md b/docs/09-tooling-integration.ko-KR.md index d214a9dd..d00e9d4f 100644 --- a/docs/09-tooling-integration.ko-KR.md +++ b/docs/09-tooling-integration.ko-KR.md @@ -23,11 +23,11 @@ next: addons-ko-KR.html ### 브라우저에서 JSX 변환 -JSX를 사용하신다면, [다운로드 페이지](/react/downloads.html)에서 브라우저 JSX 변환기를 제공합니다. 간단히 `