티스토리 뷰

반응형

JSX 전개 속성

컴포넌트에 배치하려는 모든 속성(props)을 알고 있다면 JSX를 사용하기 쉽습니다:

var component = <Component foo={x} bar={y} />;

가변 Props는 좋지 않습니다

어떤 속성(props)를 설정할지 모르는 경우, props를 나중에 추가하고 싶을 지도 모릅니다:

var component = <Component />; 
component.props.foo = x; // bad 
component.props.bar = y;

이는 나중에까지 올바른 propTypes를 확인할 수 없으므로 안티 패턴입니다. 이는 propTypes 오류가 암호화 스택 추적(cryptic stack trace)으로 끝남을 의미합니다.

이 시점에서 props는 불변으로 간주되어야 합니다. props 객체를 다른 곳에서 변경하면 예기치 않은 결과가 발생할 수 있으므로 이상적으로는 이 시점에서 props는 고정된 객체가 됩니다.

컴포넌트 이전에 props를 구성하세요

먼저 모든 props를 구성한 다음 컴포넌트에 전달해야 한다는 교훈을 얻었습니다.

JSX 초기에는 props 개체를 컴포넌트에 전달할 수 있는 방법이 없었기 때문에 다음과 같은 간단한 함수 호출에 의존해야 했습니다:

var props = {}; 
props.foo = x; 
props.bar = y; 
var component = Component(props); // 내 JSX는 어디로?

전개 속성

지금은 전개 속성이라 불리는 JSX의 새 기능을 사용할 수 있습니다:

var props = {}; 
props.foo = x; 
props.bar = y; 
var component = <Component {...props} />;

전달되는 객체의 속성은 컴포넌트의 props에 복사됩니다.

이를 여러 번 사용하거나 다른 속성과 결합시킬 수 있습니다. 수 있다. 순서 명시가 중요합니다. 뒤에 나오는 속성이 이전 속성보다 우선합니다.

... 표기법이 무엇일까요?

ES6의 배열 에 대해서 이미 ... 연산자(혹은 전개 연산자)를 지원하고 있습니다. ES7에서 객체 속성에 대해서도 전개 연산자를 지원하는 것을 추진하고 있습니다.

여기서 제안서 전문을 확인할 수 있습니다: Object Rest and Spread Properties

JS의 변환 파이프라인 덕분에 우리는 이미 ... 을 실험적 구문으로써 우리 코드 내에서 사용할 수 있습니다:

var oldObj = { foo: 'hello', bar: 'world' }; 
var newObj = { ...oldObj, foo: 'hi' }; 
console.log(newObj.foo); // 'hi'; 
console.log(newObj.bar); // 'world';

두 객체를 합치는 것도 아래와 같이 할 수 있습니다:

var ab = { ...a, ...b }; // 합치기(a, b)

이론적 해석 : JSX의 전개 구문

  • <div props={props} /> 는 안되나요?

이것은 XML의 전통적인 attribute-value 모델에 더 가깝다고 읽히지만 의미론적으로 약간 불명확합니다. 실제로 props 객체 자체 설정을 허용하는 것을 원치 않습니다. 카피가 될 겁니다. 또한 속성 이름을 props로 설정하지 않습니다.

  • <div {props} /> 는 왜 안되나요?

다시 말하지만, 이것은 props객체를 패스하지 않습니다. 우리는 그것을 허용 할 수 없습니다. 따라서이 경우 복사가 발생하는 위치가 명확하지 않습니다. 또한 객체에서 동일한 작업을 수행하려는 경우 다른 전개 구문과 일치하지 않습니다.

  • <div ...props /> 는 왜 안되나요? 왜 {중괄호}가 필요한가요?

모호함을 해결하기 위해 많은 미리보기가 필요한 <div ... x / 5 />와 같은 특정 표현식에서는 모호해집니다. 모든 속성 표현식에서 중괄호 사용을 피하기 위해 표현식의 작은 하위 집합을 허용 할 수 있지만 필요할 때와 필요하지 않을 때가 언제인지 혼란스러울 것입니다.

  • <div ...{props} /> 는 왜 안되나요?

이는 합리적으로 보이지만 미래에 나올 수 있는 JSX의 전개 사용 사례(자식 위치)가 있을 수 있습니다.

<div> prefix {...children} suffix </div>

이것도 속성 위치가 일치하지 않을 수 있습니다. ...는 표현식 앞의 일반 언어로 자주 사용되기 때문에 구문 <div> Hello ... {children} </ div>를 안전하게 사용할 수 없습니다.

  • 객체 위치에서 JS가 허용하는 더 많은 기능을 허용하지 않는 이유는 무엇인가요?

{}가 JS로 이스케이프하고 객체 리터럴에 넣을 수있는 모든 것을 허용하는 것을 상상할 수 있습니다. <div {get x () {}} /> 또는 <div {x} /> 처럼 말이죠. 이렇게 하지 않는 주된 이유는 JSX가 허용하는 구문과 변환되는 의미를 분리하고 싶기 때문입니다. 예를 들어 ...는 속성이 객체 대신 배열로 전달되는 경우에도 유효할 수 있습니다.

게다가 우리는 실제로 getter를 광범위하게 지원하지 않으며 이는 getter가 인라인으로 정의되도록 허용하는 것을 무의마하게 합니다. <div {x} /><div x />와 혼동될 정도로 유사합니다. 첫 번째는 {x : x}로 변환되고 두 번째는 {x : true}로 변환됩니다. 전개를 넘어서는 이 기능은 많이 사용되지 않습니다.

아래 글을 번역한 글입니다.

원문 링크: JSX Spread Attributes

 

JSX Spread Attributes

JSX Spread Attributes. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

 

반응형
댓글
반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함