래퍼를 넣지 않으면 다음과 같이 설탕이 제거되기 때문입니다.

return React.DOM.div(...)React.DOM.div(...)

구문상 의미가 없습니다. 시각적 매핑이 필요한 경우 jsx 컴파일러 페이지가 도움이 될 수 있습니다.

즉, 이것을 대신 [div, div] 로 디설거하는 것이 가능합니다. 이것은 어렵고 다소 논쟁의 여지가 있으며 가까운 장래에 구현되지 않을 것입니다.

(특별히 논란의 여지가 있다고 생각하지 않지만 코드 복잡성을 추가하고 아직 완료되지 않았습니다.)

IIRC @syranide 에는 이에 대한 몇 가지 의견이 있습니다.

@청루 허허 .

나는 조금 전에 그것에 대해 chenglou와 짧은 대화를 나눴습니다. 저는 현재 어느 쪽으로든 기울어지지 않습니다. 복합 구성 요소가 여러 구성 요소를 반환하도록 허용하는 데는 많은 숨겨진 위험이 있으며 직관적인 가정이 많이 깨져 있지만 분명히 이점을 얻을 수 있는 (현재) 모범 사례 사용 사례는 알지 못합니다.

최대 하나의 구성 요소를 반환하는 단순함은 보이는 것에 대해 추론하기가 매우 쉽다는 것을 의미합니다. 그렇지 않은 경우 <table><TableHeader /></table> 는 실제로 원하는 수의 행을 렌더링할 수 있습니다 TableHeader 를 검사하는 것 외에는 알 수 있는 방법이 없습니다.

여러 구성 요소를 반환할 수 있다는 것은 "복합 구성 요소"에서 "복합 구성 요소 렌더링"으로 필요한 만큼만 구성 요소를 래핑하는 책임을 옮기는 것 같습니다. "복합 구성 요소를 렌더링하는" 구성 요소는 합성 구성 요소를 래핑할지 여부에 대한 지식을 거의 갖고 있지 않거나 가지고 있어야 하는 반면, 자식은 부모에 대한 지식을 가질 가능성이 더 큽니다.

그러나 아마도 그것은 단순히 개발자 책임의 경우일 것입니다. 둘 다 좋은 사용 사례가 있을 수 있으며 불가피한 오용은 지나쳐야 합니다.

@sebmarkbage 아마 댓글도 몇 개 있을 겁니다 :)

우리는 아마도 그 구문을 암시적으로 허용하지 않을 것입니다. 다음과 같은 래퍼가 필요합니다.

<>
  <div className="col-md-8">
  </div>
  <div className="cold-md-4">
  </div>
</>

또는

[
  <div className="col-md-8">
  </div>,
  <div className="cold-md-4">
  </div>
]

그러나 이마저도 작동하지 않습니다. 종종 그것은 아마도 최선일 것입니다. 자식이 여러 요소로 확장될 수 있는 경우 구성 요소를 사용하는 것이 혼란스러울 수 있습니다.

그러나 실제로 지금 지원하지 않는 유일한 이유는 구현하기 어렵기 때문입니다. 바라건대, 우리는 미래에 그것을 지원할 수 있지만 아마도 단기간은 아닐 것입니다. 죄송합니다. :/

이것은 jquery 또는 특정 요소를 대상으로 하는 다른 라이브러리와 같은 것에 영향을 미치지 않을 수 있습니까? 따라서 $('#id-name').children() 와 같은 작업을 수행하면 다음과 같습니다.

<div id="id-name">
  <div>
    <div class="class-name">
    </div>
  </div>
</div>

이 경우 <div> 및 <div class="class-name"> 가 선택됩니다. (제가 제대로 이해했다면)

@AdamKyle 이 이전에 게시한 것과 동일한 방식으로 CSS 선택자에도 영향을 줍니다.

이 문제에 대한 업데이트가 있습니까?

내 구성 요소가 작동하지 않는 이유를 이해하는 데 몇 분을 보냈습니다. 어딘가에 공지가 있어야 할 것 같은데, 놓친 건 아닐까? 시도하는 것이 분명히 잘못된 것일 수 있습니다.

var Optimistic = React.createClass({
  render: function() {
    return ( 
      <h1>{this.props.name} loves React</h1>
      <p>React doesn’t. Idea: sprinkle some divs here and there.</p>
    );
  }
});

React.render(
  <Optimistic name="Peter" />,
  document.getElementById('myContainer')
);

@gabssnake "인접한 XJS 요소는 둘러싸는 태그로 래핑되어야 합니다"라는 오류와 함께 JSX 컴파일 오류가 발생했어야 합니다. 오류를 보지 못했거나 설명에서 명확하지 않았습니까?

@spicyj 답변 감사합니다. 글쎄요, 나는 React 문서에 있는 공지를 의미했습니다. 예, 콘솔에 오류가 표시되었지만 처음에는 랩핑의 필요성이 이해되지 않았습니다. 그래서 검색해서 여기까지 왔습니다.

저도 이 고통을 겪었습니다. 사실 제 디자이너에게 특히 고통스러웠습니다. 구성 요소가 요소 대신 노드(따라서 노드 목록 또는 조각)를 출력할 수 있다면 좋을 것입니다.

그냥 .. 구성 요소에서 여러 자식을 반환하는 것을 옹호하는 것이 아닙니다. 하지만 render 에서 추출한 render* 메서드에서 그렇게 하고 싶습니다.

  render: function () {
    return (
      <div className={this.getClassName()}
           style={{
             color: this.props.color,
             backgroundColor: this.props.backgroundColor
           }}>
        {condition ?
          this.renderSomething() :
          this.renderOtherThing()
        }
      </div>
    );
  },

  renderSomething() {
    return (
      <>
        <div className='AboutSection-header'>
          <h1>{this.props.title}</h1>
          {this.props.subtitle &&
            <h4>{this.props.subtitle}</h4>
          }
        </div>,

        {hasChildren &&
          <div className='AboutSection-extra'>
            {this.props.children}
          </div>
        }
      </>
    );
  }

하지만 나는 아마 그냥 닥치고 key 를 사용해야 할 것입니다.

@gaearon 당신은 이미 그것을 할 수 있지만, 당신은 지금 배열을 반환해야합니다 (그래도 약간 번거롭습니다) ... buuuuut, 당신은 그것을 해결할 수 있습니다, 나는 내 자신의 <Frag> 구성 요소를 해킹했습니다 이것은 배열로 변환됩니다(overloaded React.render ) ... 해킹을 피하고 싶다면 return <NoopComp>...</NoopComp>.props.children 할 수도 있습니다.

편집: 내 나쁜, 나는 React.render React.createElement 를 오버로드했습니다.

배열의 문제는 디자이너를 넘어지게 한다는 것입니다. 쉼표, 명시적 키가 필요합니다.

@gaearon 예, 지금은 두 가지 해결 방법 중 하나를 사용하여 쉼표를 피할 수 있습니다.

배열 구문을 사용하는 경우 각 요소에 key 를 지정해야 합니다. 그게 어렵다는 게 아니라, 변하지 않는다는 걸 알기에 어색하게 느껴져요.

@gaearon 아 예, 지금은 그 경고를 정신적으로 무시하기로 선택했습니다. :), 정말로 그것을 피하고 싶다면 <MyComp children={this.renderWhatever()} /> 를 사용하여 피할 수 있습니다( 편집: 분명히 그것을 사용할 수는 없지만 인접한 자녀가 있는 경우 평평하게 하는 도우미를 사용할 수 있습니다. 하지만 예).

UI 키트와 관련된 또 다른 경우입니다. 다음과 같이 고정 스크롤 가능 컨테이너 안에 자식을 배치할 때:

return (
  <div style={{
    position: fixed
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    overflow-y: scroll;
  }}>
    {this.props.children}
  </div>
);

이제 자식은 배열로 전달되어야 하지만 복합 클래스가 전달되는 경우 클래스가 손상되지 않도록 해당 스타일도 구현해야 합니다. 복잡성의 레이어를 추가할 뿐입니다. 그러나 변경을 수행하는 것이 얼마나 복잡한지 충분히 이해할 수 있습니다. 지원을 위해 모자를 던질 뿐입니다.

여기 #3415에서 자세히 설명한 또 다른 사용 사례가 있습니다. 그러나 지금은 해결할 수 있으며 구현하기 어렵고 드물다는 것을 이해합니다.

나는 (아직) 내부 반응에 대해 아무 것도 모르지만 DOM에서 이러한 가상 부모 요소/조각을 표시할 수 있는 방법에 대해 설명하겠습니다. 예

<A>
    <B></B>
    <Fragment>
        <C></C>
        <D></D>
    </Fragment>
    <E></E>
</A>

렌더링 할 것입니다

<a>
    <b></b>
    <!--<fragment data-reactid="">-->
        <c></c>
        <d></d>
    <!--</fragment>-->
    <e></e>
</a>

이것은 c와 d가 sth의 자식으로 취급된다는 것을 의미합니다. (b 및 e와 충돌하지 않는 중첩 반응 ID 포함). 나는 이러한 종류의 의미론적 작업에 대해 다른 프레임워크가 "오용" 설명을 하는 것을 보았습니다.

@Prinzhorn DOM 출력을 React의 JSX와 혼동할 수 있다고 생각합니다.

유용한 경우: "조각 구성 요소"를 DOM에 매핑하기 위해 HTML 주석을 사용 하라는 @Prinzhorn 의 제안은 Knockout이 사용하는 것과 동일한 접근 방식입니다. 녹아웃은 이러한 "가상 요소"를 호출합니다.

<!-- ko component: "message-editor" -->
<!-- /ko -->

( 녹아웃 문서 에서)

또한 이에 대한 또 다른 사용 사례 - flexbox를 사용할 때 추가 래핑 요소가 문제가 될 수 있습니다.

@aldendaniels 는 절대적으로 동의합니다. 저는 이미 flexbox 문제에 직면했습니다.

종속 드롭다운이 있는 flexbox로 이 문제에 부딪쳤습니다. 여기서 A는 첫 번째 드롭다운을 렌더링하고 관리하고 A의 드롭다운 값에 따라 B 또는 C 또는 D가 뒤따릅니다. 각 드롭다운은 적절한 수의 드롭다운을 렌더링합니다.

<A>
 <Drop />
 <C><Drop /><Drop /></C>
</A>

A, B, C, D는 stateless 이므로 class B {render(){ this.props }} 에서 function B(props){ return [...]; } 로 변경했습니다.

이 경우 여러 자식이 렌더링되는 것은 부모에게별로 중요하지 않으며 내 CSS를 처리하는 것입니다. 재사용할 필요가 없는 경우 다르게 수행할 작업이 있습니다(다른 구성 요소에는 B, C 및 D가 필요함).

대안으로 부모로부터 그것을 풀 수 있는 방법이 있을까요? 어떻게 보일지에 대한 구체적인 아이디어가 없습니다.

저는 오늘 이 기능의 좋은 사용 사례라고 생각하는 시나리오를 보았습니다. 여러 <script> 요소를 렌더링하는 구성 요소로, 페이지의 <head> 요소로 렌더링될 수 있습니다. 거기에 있는 모든 래퍼 요소는 나쁠 것입니다.

내 시나리오는 페이지에 필요한 런타임 코드에 대한 <script> 태그와 사용할 현지화 문자열을 전달하는 또 다른 <script> $ 태그 모두에 대한 렌더링을 담당하는 구성 요소를 원합니다. 런타임 코드. 예를 들어:

<html>
    <head>
        <script language="runtime.resources.en-us.js"></script>
        <script language="runtime.js"></script>
    </head>
    <body>
    ...
    </body>
</html>

이 경우 코드를 다음과 같이 작성하고 싶습니다.

var RuntimeScripts = require('./Runtime')
...
return (
    <html>
        <head>
            <RuntimeScripts language="en-us" />
        </head>
    </html>
)
...

나는 또한 몇 가지 flexbox 문제에 부딪쳤습니다. CSS에서 해결할 수 없는 것은 없지만 flexbox의 "아름다움" 중 하나는 레이아웃이 작동하도록 하기 위해 모든 곳에서 "래퍼" 요소가 덜 필요하지만 React를 사용할 때 여전히 모든 곳에서 래퍼 요소로 끝납니다. 컨테이너를 갖는 것이 합리적이지 않는 한 항상 div/div 또는 이와 유사한 것으로 반환하는 모든 것을 래핑합니다.

여기에 제시된 모든 사용 사례에 대해 <BunchOfComponents /> 를 {getBunchOfComponents()} 로 바꿀 수 있으며 시각적 출력은 구성 요소와 관련된 실용적이고 기술적인 문제를 도입하지 않고 동일할 것이라고 확신합니다. 루트로 조각.

@syranide 하지만 구성 요소 중 하나가 변경될 때마다 모든 형제는 다시 계산해야 합니다...

또한 일반 coffeescript를 사용하는 경우 배열을 반환하기 쉽기 때문에 jsx 표현에서 기능을 분리하십시오.
반환된 요소 배열을 처리하기 쉬운 경우 jsx가 따라잡을 때까지 기다리지 마십시오.

@syranide 하지만 구성 요소 중 하나가 변경될 때마다 모든 형제는 다시 계산해야 합니다...

@wmertens 예, 하지만 부모가 다른 이유로 다시 렌더링해야 하거나 단순히 props를 통해 데이터를 수신하기 때문에 여러 번 어쨌든 그렇게 할 수 있습니다. 그러나 예, 그것은 차이점입니다. 그러나 이것이 이 접근 방식이 옳다는 것을 의미하는 것은 아니며 최적화이며 이를 달성하는 많은 방법이 있습니다.

또한 일반 coffeescript를 사용하는 경우 배열을 반환하기 쉽기 때문에 jsx 표현에서 기능을 분리하십시오.

그것은 관련이 없으며 이것은 JSX의 문제가 아닙니다. 큰 문제는 하나의 구성 요소 = 하나의 요소/노드 라는 기술적이고 실용적이며 직관적인 가정을 잃는다는 것입니다. 개발자를 대변할 수는 없지만 기꺼이 포기하지는 않을 것입니다. 이는 매우 유용한 가정입니다. 최적화가 사람들이 이것을 원하는 유일한 이유라면 설계할 수 있는 동등하게 좋거나 더 나은 최적화가 있다고 확신합니다.

@syranide 가장 큰 문제는 항상 래핑을 사용할 수 없다는 것입니다.
테이블, 목록, 플렉스박스, 헤드와 같은 html의 요소...
그것은 추악한 코드로 이어집니다.

렌더링만 하는 가상 래퍼 요소로 완벽하게 만족할 것입니다.
이전에 제안된 대로 의견.

2015년 5월 29일 금요일 오후 3시 56분 Andreas Svensson [email protected]
썼다:

@syranide https://github.com/syranide 하지만 매번
구성 요소는 모든 형제를 변경하여 다시 계산해야 합니다...

@wmertens https://github.com/wmertens 예, 하지만 여러 번
부모가 다른 사람을 위해 다시 렌더링해야 하기 때문에 어쨌든 가지고 있습니다.
이유 또는 단순히 props를 통해 데이터를 수신하기 때문입니다. 하지만
예, 차이가 있지만 이 접근 방식이 옳다는 의미는 아닙니다.
그것은 최적화이며 이를 달성하는 방법에는 여러 가지가 있습니다.

또한 일반 커피 스크립트를 사용하면 배열을 쉽게 반환할 수 있으므로
jsx 표현에서 기능을 분리합니다.

그것은 관련이 없으며 이것은 JSX의 문제가 아닙니다. 큰 문제는
당신은 _one의 기술적이고 실용적이며 직관적인 가정을 잃습니다.
구성 요소 = 하나의 요소/노드_. 나는 개발자를 위해 말할 수 없지만 나는하지 않을 것입니다
그것을 기꺼이 포기하는 것은 매우 유용한 가정입니다. 확실해
다음과 같은 경우 설계할 수 있는 동등하게 우수하거나 더 나은 최적화가 있습니다.
최적화는 사람들이 이것을 원하는 유일한 이유입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/facebook/react/issues/2127#issuecomment -106810565.

fwiw, React에서 자식의 배열로 취급되는 "fragment" 컴포넌트를 React로 해킹하는 것은 비교적 쉽습니다 . 키를 자동 생성하지만 구성 요소의 초기 유효성 검사 후에 발생하므로 일반적인 "키가 제공되지 않음" 오류가 발생하지 않습니다.

즉, 그 해킹은 @gaearon 이 위에서 말한 것만 해결합니다. JSX에서 못생긴 배열 구문을 처리하거나 임의의 키를 설정할 필요가 없으며 구성 요소의 렌더링 메서드 루트에서 여러 노드를 반환하는 문제는 아닙니다.

구성 요소가 하나의 "요소/노드"를 반환해야 한다는 아이디어에 문제가 있습니다. 나에게는 다음과 같은 JSX 구조에 대해 완벽하게 합리적으로 보입니다.

<Main>
  <Foo />
  <Fragment>
    <Bar />
    <Baz />
  </Fragment>
</Main>

DOM으로 끝내려면:

<div>
  <div>Foo</div>
  <div>Bar</div>
  <div>Baz</div>
</div>

구성 요소가 이미 수명 주기 후크를 사용하여 DOM에서 모든 종류의 "놀라운 일"을 수행하기 때문에 이것이 최소한의 놀라움의 원칙 위반이라고 생각하지 않습니다(일반적인 웜홀 패턴 참조). 일반적으로 구성 요소가 단일 요소를 생성하지 않아도 된다는 것은 일반적으로 인정되며 DOM과 함께 작동하려면 몇 가지 타협이 이루어져야 하기 때문에 괜찮습니다.

이것은 "최적화"에 관한 것이거나 배열 구문을 좋아하지 않는 것에 관한 것이 아닙니다. 많은 사용자가 언급했듯이 _wrapper 요소는 스타일과 레이아웃을 심각한 방식으로 깨뜨립니다_. 테이블이 가장 분명하지만 Flexbox도 주요 문제입니다. 나는 이미 React 때문에 존재하는 래퍼 요소에 플렉스 규칙을 다시 적용하는 CSS를 가지고 있는데, 꽤 보기 흉합니다.

여기에 제시된 모든 사용 사례에 대해 다음을 대체할 수 있다고 확신합니다. {getBunchOfComponents()}를 사용하면 조각이 있는 구성 요소를 루트로 사용하는 것과 관련된 실용적이고 기술적인 문제가 발생하지 않고 시각적 출력이 동일합니다.

이를 위해서는 개발자가 격리되고 재사용 가능한 구성 요소를 만드는 데 타협해야 합니다. React의 기본 구현 문제로 인해 구성 요소를 다른 곳에서 재사용하기로 결정한 경우 하늘이 도와줍니다. 나는 그것이 받아들여져야 한다고 생각하지 않는다.

@thomasboyt

편집 : 내 실수는 위의 테이블 토론과 귀하의 주장 중 일부를 통합했으며 귀하가 생각하는 바에 대체로 동의합니다. 그러나 불투명한 구성 요소에는 여전히 문제가 있으므로 유용한 투명 래퍼로 의도된 것이 부모에게 불투명하게 됩니다. <Wrapper1><Wrapper2>...</Wrapper2></Wrapper1> , Wrapper1 가 Wrapper2 의 자식을 볼 수 없다고 상상해보십시오. 따라서 wrapMyElements(...) 는 여전히 모든 면에서 더 나은 솔루션입니다(다른 필요한 지원 기능 포함).

구성 요소가 하나의 "요소/노드"를 반환해야 한다는 아이디어에 문제가 있습니다. 나에게는 다음과 같은 JSX 구조에 대해 완벽하게 합리적으로 보입니다.

구성 요소는 단순한 래퍼 이상이며 목적이 있습니다. IMHO 여러 요소를 반환하면 매우 유용한 기대가 차단되는 것 같습니다. 예를 들어, React.render 는 미래에 요소를 렌더링하고 노드를 반환하는 컴패니언을 얻게 되며, 이제 대신 노드 배열을 생성해야 합니다.

하지만 IMHO가 React의 가장 큰 장점인 가독성이 매우 중요한 문제라고 생각합니다. 모든 것이 명시적입니다.

<table>
  <tr>
    <td />
    <td />
    <td />
  </tr>
  <tr>
    <Columns1 />
    <Columns2 />
  </tr>
</table>

말도 안 되는 걸 보니 3차 전지는 어디에서 오는 걸까요? 아마도 그것은 실제로 잘못되었고 2개 또는 4개의 셀을 렌더링하고 있을 것입니다. 누가 알겠습니까? 실제로 동적이며 소품 또는 외부 상태에 따라 달라질 수 있습니다. 명시적인 기대치를 가질 수 있는 다른 비 HTMLDOM 프런트엔드를 고려할 때만 더 어려워지는 이 문제의 많은 변형이 있습니다. 고려해야 할 또 다른 사항은 요소가 불투명하다는 것입니다. 따라서 <tr /> 를 <MyMagicalTr /> 로 바꾸면 개별 셀과 상호 작용할 수 없거나 셀 수를 추론할 수 없으므로 <MyMagicalTr /> 는 <MyMagicalTd /> 만 수락할 수 있으며 실제로 상호 작용할 수 있다는 보장은 없습니다.

이를 위해서는 개발자가 격리되고 재사용 가능한 구성 요소를 만드는 데 타협해야 합니다. React의 기본 구현 문제로 인해 구성 요소를 다른 곳에서 재사용하기로 결정한 경우 하늘이 도와줍니다. 나는 그것이 받아들여져야 한다고 생각하지 않는다.

"이것은 개발자가 격리를 만드는 데 타협해야 합니다..." 그러나 구성 요소가 여러 요소를 반환할 수 있으면 더 이상 격리되지 않고 대체되며 구성 요소가 상위 요소로 누출되고 있는 것입니다.

망치, 못. 근본적인 구현 문제는 이것이 실제로 수행되어야 하는지 여부와 별개의 문제입니다. 내 결정은 아니지만, 그에 수반되는 절충안이나 다른 대안 솔루션을 고려하지 않고 드문 사용 사례가 얼마나 설득력 있는 주장인지 알 수 없습니다.

IMHO 나는 {getBunchOfComponents()} 의 문제를 보지 못했습니다. 명시적이며 유용한 기대치를 유지할 수 있습니다. 성능이 문제인 경우 React.createSmartFragment() (또는 w/e)를 사용하여 투명 어레이/객체와 유사한 유형이지만 상위 항목과 독립적으로 업데이트할 수 있습니다.

다시 말하지만, React 개발자가 권위자입니다(제가 아닙니다). 그러나 여기에서 다양한 부작용을 고려할 때 설득력 있는 주장을 볼 수 없습니다. 나는 제시된 솔루션이 지원되더라도 좋은 패턴이라는 데 동의하는지 확신할 수 없습니다.

편집: 명확히 하자면, 다른 분명히 유익한 사용 사례가 있기 때문에 아마도 구성 요소가 미래에 여러 요소를 반환할 수 있을 것입니다. 특히 @thomasboyt를 표시하는 것과 같이 자식을 통과하는 맥락에서 가독성이 유지됩니다.

이 대화의 철학적 측면에 응답하기 전에 커피가 조금 더 필요하다고 생각합니다. 이 범위의 실행 가능한 변경은 이 스파이크로 이어집니다. https://github.com/facebook/react/compare/master...thomasboyt :fragment

그리고 여기에 약간의 데모를 던졌습니다: http://www.thomasboyt.com/react-fragment-demo/

사물의 구현 측면에 대한 몇 가지 관찰:

• 당연히 더 많은 노드를 지원하기 위해 "1 구성 요소 = 1 노드"를 기대하는 시스템을 개조하는 것이 매우 까다롭습니다 ;)
• 처음에는 DOM 작업 측에서 조각을 추적하여 ReactMultiChild 생성된 변형 명령이 동일하게 유지되고 다른 노드처럼 조각을 처리할 수 있도록 하려고 생각했습니다. 노드 수/어떤 노드가 조각인지에 대한 상태를 DOM 상태 추적에 추가하는 좋은 방법이 생각나지 않았습니다. @Prinzhorn 이 언급한 주석 펜싱과 같은 것이 작동할 수 있지만 상대 비용을 고려하면 DOM 조회가 필요한 모든 것에 주의합니다.
• 그 아이디어를 버리고 ReactMultiChild 구성 요소의 모든 자식에 _nodeCount 필드를 추가하여 조각에 실제로 포함된 루트 노드 수를 추적할 수 있습니다.

문제는 이것이 초기 렌더에서 단편의 자식을 계산하여 수행할 수 있을 만큼 쉽지만 후속 돌연변이에서 단편의 노드 수를 업데이트하는 것이 더 까다로워 보인다는 것입니다. 이것은 여전히 ​​내 지점에서 수행되지 않습니다(https://github.com/thomasboyt/react/issues/2 참조).

• 많은 DOM 작업은 요소를 추가/이동/제거하기 위해 내부 노드 ID로 조회된 요소의 상위 노드에 액세스하는 데 의존합니다(https://github.com/thomasboyt/react/issues/3 참조). ReactMultiChild 의 updateComponent 주기는 이 ID를 전달하는 역할을 하므로 DOM 노드가 있는 가장 가까운 부모를 조회하도록 변경할 수 있지만 비용이 많이 듭니다. 또는 "실제 노드" 키에 대한 조각 키의 내부 레지스트리를 가질 수 있습니다.

나는 여전히 루트 노드의 수를 유지하기 위해 조각을 요구하는 것이 이것을 수행하는 가장 좋은 방법이라고 확신하지 못합니다(최소한 데모에 참여하게 되었지만). 그리고 이것은 모두 아주 빠르고 아주 늦은 밤에 함께 해킹되었습니다. , 따라서 다른 사람이 구현에 대한 제안 사항이 있으면 언제든지 알려주세요.>

@thomasboyt IIRC 주요 구현 장애물은 mountIndex 로 자식 노드를 참조하는 React에서 발생합니다. 하나의 "노드"가 갑자기 임의의 수의 노드가 될 수 있고 이는 부모를 호출하지 않고 발생할 수 있으며 발생할 수도 있는 경우에는 작동하지 않습니다. 여러 구성 요소 깊이(래핑). 내가 실수한 것이 아니라면 숫자가 절대 변경되지 않는 한 React가 여러 루트 요소를 지원하도록 하는 것은 매우 간단합니다.

따라서 React에서 작동하게 하는 것이 특히 어려울 것이라고 생각하지 않지만 진정으로 적절한 솔루션은 더 문제가 많으며 아마도 mountIndex 삭제를 포함해야 할 것입니다.

@syranide 오른쪽; 내가 작업하고 있는 솔루션은 실제로 노드의 "실제 오프셋"이 되어야 하는 새로운 nodeIndex 를 소개합니다(이는 내가 돌아가서 mountIndex 를 제거해야 함을 상기시켜줍니다. 나는 그것이 지금 내 지점에서 사용되지 않는다고 생각합니다).

그러나 이전 형제 구성 요소의 노드 수가 변경될 때마다 구성 요소의 nodeIndex 를 업데이트해야 하므로 루트 요소 수가 변경되면 문제가 됩니다. 여전히 이에 대한 해결책을 찾아야 합니다.

flexbox 문제도 겪었습니다. @syranide "getBunchOfComponents" 제안 솔루션에 대해 좀 더 자세히 설명해 주시겠습니까? React가 처음이기에 이 함수를 정의할 위치/적용 방법을 완전히 이해하기 어렵습니다.

@landabaso

function getBunchOfComponents(...) {
  return [<ColumnA key="a" />, <ColumnB key="b" />];
}

이봐,

전체 스레드를 읽지는 않았지만 다음은 이 기능이 필요할 수 있는 렌더 최적화 사용 사례입니다.

http://stackoverflow.com/questions/30976722/react-performance-rendering-big-list-with-purerendermixin

이 기능이 출시되면 ReactCSSTransitionGroup은 더 이상 래퍼 노드가 필요하지 않겠죠?

@slorber 예, 아마도 사실일 것입니다.

매일 이 기능이 필요합니다.

많은 작은 구성 요소가 있는 경우(즉, 매우 모듈식으로 설계), 모든 종류의 항목을 div에 포함해서는 안 되는 모든 항목을 래핑해야 합니다. 의아해 할 수 있지만 이 문제와 관련이 있다고 생각합니다.

<div> 의 경우 <div> 로 래핑할 수 있지만 테이블 행 <tr> 요소의 경우 쉽지 않습니다. <tr> in <tbody> 로 래핑할 수 있지만 <tbody> 의 여러 레이어를 <tr> 의 여러 레이어로 래핑하는 것은 바람직하지 않을 수 있습니다.

내가 말한 시나리오는 완전히 <head> 렌더러가 되지 않고도 <link> 및 <script> 요소를 제공하는 구성 요소를 가지려고 했습니다.

이 문제의 맨 위에 메모를 추가했습니다. 댓글을 읽기 전에 읽어주세요. https://github.com/facebook/react/issues/2127#issue -41668009

범프 ... 서버 측에서 크게 필요합니다. <head> 섹션 때문에 조각을 렌더링할 수 있는 기능 없이 전체 웹 페이지(doctype 제외)를 렌더링하는 것은 매우 복잡합니다. 현재 최종 렌더링에서 믹스인과 약간의 논리를 통해 이 문제를 해결하고 있지만 여러 구성 요소 렌더링에 대한 지원이 있다면 훨씬 간단할 것입니다.

@impinball 당신은 이러한 문제를 해결하기 위해 반응 부작용을 기반으로 반응 문서 제목 과 유사한 것을 작성하려고 시도할 수 있습니다. 메타 태그, 헤더, 제목 및 때때로 리디렉션에 대해 동일한 작업을 수행할 수 있었습니다.

저도 이 문제를 겪고 있는데 당분간 해결 방법이 없을까요? 제안한 대로 {getBunchOfComponents()} 을(를) 사용할 수 없습니다.

이미 언급된 것 외에는 없습니다.

@jonchay 자식만 렌더링하는 구성 요소를 만들 수 있습니다.

function statelessWrapper(props) {
   return props.children;
}

그리고 그것을 사용하려면:

render() {
   return (  
      <statelessWrapper>
         {renderABunchOfComponents()}
      </statelessWrapper>
    );
}

@whatknight return renderABunchOfComponents(); 가 이미 작동하는 경우를 제외하고는 작동하지 않습니다.

  render () {
    let user = this.state.user
    let profile = user.get('data')
    let view = null

    if (user.get('status') === 'fetched') {
      view = (
        <h1>{profile.get('login')}</h1>
        <img src={profile.get('avatar_url')} />
        <dl>
          <dt>email</dt>
          <dd>{profile.get('email')}</dd>
        </dl>
      )
    } else if (user.get('status') === 'fetching') {
      view = <h1>fetching</h1>
    } else if (user.get('status') === 'error') {
      view = <h1>{profile.message}</h1>
    }

    return (
      <div className={className}>
        {view}
      </div>
    )
  }

보간 및 "어셈블리"를 수행하는 동안 여러 조각을 반환하는 방법이 최소한 있어야 합니다. 위의 예는 img와 h1이 단호하다고 불평하지만 어쨌든 메인 래퍼 안에 있게 될 것입니다. 그것은 내가 제거할 수 있기를 바라는 하나의 래퍼 요소입니다.

@kilianc 이 경우 간단히 작성할 수 있습니다.

      view = [
        <h1 key={0}>{profile.get('login')}</h1>,
        <img key={1} src={profile.get('avatar_url')} />,
        <dl key={2}>
          <dt>email</dt>
          <dd>{profile.get('email')}</dd>
        </dl>,
      ]

이 문제가 해결되면 문제가 해결되지 않습니다.

이미 언급한 이유로 이 기능이 필요하므로 https://github.com/mwiencek/react/tree/frag-component 에서 <frag></frag> 컨테이너 구현을 시도했습니다.

구현은 그다지 아름답지 않지만 사람들에게 효과가 있다면 PR을 제출하고 React 개발자가 그것을 분해하도록 할 수 있습니다.

@mwiencek 업데이트에서 조각의 자식 수가 변경되면 구현이 작동하지 않는 것 같습니다(_nestedChildCount는 mountComponent에서만 설정됨)? 모든 것이 잘 작동하도록 하려면 약간의 교묘함이 있습니다. 그래도 시작을 잘 한 것 같습니다. 나는 실제로 최근에 이것에 대해 다시 생각하고 있으며 이것을 가능하게 하는 강력한 방법을 알아냈을 수도 있습니다. 성공하면 다시 보고하겠습니다.

@spicyj 네 맞아요 그건 좀 조사해봐야겠네요...

그러나 곧 적절한 구현을 볼 수 있다는 사실에 매우 기뻐했습니다. :) 유용하다면 해당 분기에서 테스트를 자유롭게 복사하십시오.

@spicyj createFragment 를 사용하고 JSX를 그렇게 변환하는 방법이 아닌가요? 아니면 정말로 조각이 요소가 되기를 원하는가?

@syranide 의 마지막 주석을 빌드하고 확장하기 위해 render가 반환 값으로 배열을 허용한다면 추가 "Fragment API"가 필요하지 않은 것 같습니다. JSX는 여러 루트 요소를 배열로 변환할 수 있으며, 이는 다른 함수의 반환 값에서도 작동합니다. 따라서 문서화 및 학습이 필요한 추가 API 표면을 도입하는 대신 React의 제한 사항 중 하나를 제거할 수 있습니다.

이것은 최소한 babel-plugin-transform-react-jsx (구현) 및 babel-plugin-syntax-jsx (인접 루트 요소에 대한 구문 분석 오류 제거)에 영향을 미칩니다. 전자를 변경하는 것이 상당히 안전한 것처럼 보이지만 후자의 범위/용도 및 제안된 변경이 다른 프로젝트에 미치는 영향을 모르겠습니다.

여러 요소가 있는 조건부의 사용 사례는 여전히 다루지 않습니다. 나는 "배열을 사용하고 각 요소에 임의의 key={...} 를 수동으로 추가"하는 것이 장기적인 해결책이라고 생각하지 않습니다.

@dantman 에 동의

네, 좋은 지적입니다. 자동 키 생성은 변환을 통해 내장되어야 합니다. 항목이 변경되지 않기 때문에 배열 인덱스를 키로 사용하면 충분합니다.

조건부의 경우 이는 변환에 빌드하거나 JSX-Control-Statements 를 사용할 수도 있습니다. 이런 식으로 구현했으므로 아이디어입니다.

업데이트를 올바르게 처리하기 위해 @spicyj 가 #5753에 대해 생각한 솔루션이 조각에서도 작동할 수 있다고 생각했습니다(내용을 <!-- react-frag: 1 --><!-- /react-frag: 1 --> 와 같은 것으로 래핑). 네, 댓글이 약간 못생겼지만 _nestedChildCount 로 하려고 했던 것보다 훨씬 안정적입니다. 그 접근 방식은 이제 https://github.com/mwiencek/react/tree/frag-component 에서 사용되는 것입니다.

지금까지 스레드에서 언급한 것을 본 적이 없지만 이를 해결하면 구성 가능성도 향상된다고 생각합니다. 예를 들어, 셀이 특정 순서로 흐려지기를 원하는 그리드가 있다고 상상해 보십시오. 이상적으로는 여기에 두 가지 구성 요소가 있어야 합니다. 하나는 레이아웃을 처리하고 다른 하나는 애니메이션을 처리합니다. 다음과 같은 API가 있습니다.

<GridLayout
  columns = { 3 }
>
  <FadeAnimator
    springConfig = { springConfig }
  >
    { ...cells }
  </FadeAnimator>
</GridLayout>

이렇게 하면 다른 쪽의 구현 세부 정보를 알 필요 없이 다른 레이아웃이나 다른 애니메이션으로 전환할 수 있습니다. GridLayout 는 자녀 목록을 받을 것으로 예상합니다. FadeAnimator 는 해당 목록을 가로채서 적절한 스타일 및/또는 이벤트 리스너를 삽입하고 GridLayout 가 사용할 새 목록을 반환합니다. React 요소가 렌더링에서 배열을 반환할 수 없다는 점을 제외하고 FadeAnimator 가 그리드 레이아웃에 관심을 가질 이유가 없습니다. 게다가 그리드를 석조 레이아웃으로 교체하는 간단한 방법은 없습니다. 왜냐하면 FadeAnimator 는 자식을 위한 컨테이너 역할을 해야 하기 때문입니다.

현재 제한 사항으로 다음과 같이 할 수 있다고 가정합니다.

<FadeAnimator
  wrapper = {
    <GridLayout
      columns = { 3 }
    />
  }
  springConfig = { springConfig }
>
  { ...cells }
</FadeAnimator>

// FadeAnimator
render() {
  return React.cloneElement(
    props.wrapper,
    null,
    props.children
  );
}

그러나 이는 코드를 덜 명확하고 복잡하며 작성하기 어렵게 만듭니다.

렌더에서 여러 구성 요소를 반환할 수 있도록 프래그먼트 API 추가!
렌더에서 여러 구성 요소를 반환할 수 있도록 프래그먼트 API 추가!
렌더에서 여러 구성 요소를 반환할 수 있도록 프래그먼트 API 추가!
렌더에서 여러 구성 요소를 반환할 수 있도록 프래그먼트 API 추가!
렌더에서 여러 구성 요소를 반환할 수 있도록 프래그먼트 API 추가!
렌더에서 여러 구성 요소를 반환할 수 있도록 프래그먼트 API 추가!
렌더에서 여러 구성 요소를 반환할 수 있도록 프래그먼트 API 추가!
렌더에서 여러 구성 요소를 반환할 수 있도록 프래그먼트 API 추가!

@texttechne 제안이 더 좋습니다. 추가 API를 도입하는 대신 react는 렌더링에서 여러 루트 요소를 처리해야 합니다.

렌더에서 여러 루트 요소를 처리하는 것은 어려울 것이라고 생각합니다.
https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js#L1089

요소가 아닌 요소의 배열이 있습니다.
이 때문에 내가 이해하는 한 여러 React 요소를 인스턴스화해야 합니다. https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js# L471

그런 다음 여러 인스턴스화된 React 요소를 마운트합니다. https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js#L471

그리고 좋은 순서로 생성된 모든 마크업을 조정합니다.

화해 과정을 우회하고 싶어하지 않는 단점이 있다고 생각합니다.
조각을 요소로 사용하고 싶습니까, 아니면 변형에 대한 설탕 구문으로 조각을 원합니까?

요소로서의 프래그먼트는 괜찮다고 생각합니다. 텍스트 노드나 빈 노드와 유사한 새로운 유형의 내부 노드를 생성하기만 하면 됩니다. 그렇죠? 우리가 그들을 어떻게 관리할지 모르지만.

예를 들어, 루트 중 하나가 마운트 해제되면 어떻게 처리합니까? 업데이트를 올바르게 처리하는 방법은 무엇입니까?
또는 DevTools 내에서 여러 루트를 어떻게 관리합니까? (명백한 답변: DevTools 수정...)

프래그먼트는 복합 구성 요소라고 생각합니다. 차이점은 정확히 어디에 있습니까?
조각을 구현하기 위해 코드를 복제하게 되면 React 내부를 "원래" 상태로 유지하기 위해 설탕 구문을 구현하는 것이 더 낫습니까?

궁금해서, 나는 Subtree 질문(renderSubtreeIntoContainer)과 관련하여 React 내부를 가지고 놀았고 그것이 다소 관련이 있다고 느낍니다. 새 하위 트리로 렌더링하려면 실제로 새 루트를 렌더링해야 합니다. 따라서 트리 수준에서 여러 루트를 지원하는 경우 매번 새 루트를 렌더링합니까?

<p>Hi</p>
<p>There</p>

두 개의 "render into new root" 호출이 발생합니다.

래퍼를 사용하면 한 번 호출하는 것보다 그렇지 않습니까? 성능은 어떻습니까? 간단? 솔직히 말해서, 내 느낌은: 우리는 이 상황을 처리하기 위해 React 내부를 건드려서는 안 됩니다. 오히려 JSX로 이 위업을 끌어낼 수 있습니까? JSX 구문을 개선할 수 있습니까?

(_면책 조항_: 저는 React 내부에 완전히 익숙하지 않으며, 완전히 이해하지 못하거나 이해하지 못한 부분이 있을 수 있습니다. 오해에 대해 사과드립니다.)

편집: 수정/명확한 것. 또한 GitHub는 이상하게 이메일 스타일을 이상하게 지정하므로 코드 블록을 다시 포맷해야 했습니다... :-(

안녕하세요, 핵심 Mithril 기여자/커미터입니다.

TL;DR: 프래그먼트는 API와 내부가
단순한.

그건 그렇고, 경험을 통해 구현하기가 _매우_ 어렵다는 것을 압니다. 이
또한 Mithril에 대해 여러 번 요청되었지만 다음으로 인해 거부되었습니다.
순전히 어려움. 구현하려는 모든 시도가 에서 실패했습니다.
테스트 스위트의 1/3 이상이 실패합니다.

나는 여전히 작성할 계획인 vdom 라이브러리에 대한 세부 사항을 작업 중입니다.
그리고 그것은 모든 것을 조각으로 취급할 것이지만 이것은 당신이 가지고 있는 것입니다
말 그대로 처음부터 렌더링 부분을 (다시) 작성합니다. 리액트처럼,
DOM에서 분리되지만 API는 크게 다릅니다.
개념적으로 렌더링합니다.

다음은 프래그먼트의 문제점입니다. 완전히 관리해야 합니다.
내부적으로 또는 제대로 구분하지 않습니다. 조차
document.createContextualFragment 는 쓸모가 없습니다. 예를 들자면
두 트리 변환, 렌더링 생략:

// Before
A {}
fragment {
  B[class="foo"] {}
  B[class="bar"] {}
}
C {}
D {}

// After
A {}
B[class="foo"] {}
fragment {
  C {}
}
D {}

이에 대한 올바른 변환은 B 요소와 C 요소를 모두 교체하고 나머지는 그대로 두는 것입니다. 그것을 알아내는 것은 사소한 일이 아니며 기본적으로 조각의 자식이 조각에 있다는 사실을 무시하면서 기본적으로 조각의 자식을 반복해야 합니다.

그러나 조각이 사라지면 다음과 같은 후크 의미를 처리해야 합니다.
shouldComponentUpdate (그 후크에 대한 React의 이름이 기억나지 않습니다). 그래서
여전히 조각을 독립적으로 추적해야 합니다. 당신은 그들의
내용이 마치 부모 조각의 일부인 것처럼 보이지만 여전히
구성 요소를 위해 해당 조각의 위치를 ​​추적합니다.

즉, 구성 요소는 더 이상 본질적으로 해당 구성 요소에 연결되어 있지 않습니다.
DOM 노드. 대신 해당 조각에 연결됩니다. 대부분의 다른 vdom 라이브러리 및 프레임워크와 마찬가지로 React는 예상 유형이 있더라도 본질적으로 구성 요소를 트리 표현에 연결합니다. 이것은 diff 알고리즘을 구현하는 가장 쉬운 방법입니다.
구성 요소를 처리합니다. 분리되면 따로 작업을 해야 합니다.
둘 다에 대한 부기. 초기화할 때 구성 요소를 초기화하지 않습니다.
노드. 이제 완전히 별개의 두 프로세스가 되었습니다. 하기 어렵다
처음에는 지원을 추가하기가 더 어렵습니다.

모든 말씀 감사합니다. 우리는 이것이 어렵다는 것을 알고 여전히 우리의 할 일 목록에 있습니다. (열심히 구한다고 해서 빨리 되지는 않습니다 @janryWang.)

@isiahmeadows 참고로 Mithril의 재작성 분기는 조각을 지원합니다.

@spicyj 아직 구현하지 않았다면 구현 [1] [2] 및 테스트 [1] [2] 를 살펴보는 것을 환영합니다. 전체 diff 엔진은 약 400 LOC에 불과하므로 쉽게 따라할 수 있기를 바랍니다.

@isiahmeadows GitHub가 귀하의 의견을 일부 먹었다고 생각합니다. 코드 블록이 깨져 <D /> 의 첫 번째 인스턴스가 전달된 것을 볼 수 없습니다.

그래도 이메일로는 괜찮아 보입니다. GitHub에서 버그를 찾았나요?

불행히도 GitHub의 마크다운 처리는 이메일에서 댓글이 올 때 다르게 작동합니다. 주석을 편집하여 빈 줄을 제거했는데 이제 표시됩니다.

원본 이메일을 support@github로 전달했습니다. 바라건대, 그들은 파서를 고칠 수 있습니다. 😃

@lhorie 조각에 배열 구문을 사용합니까?
DocumentFragment에 대한 폴리필이 있습니까?

HTML 주석과 같은 "의사" 래퍼 요소를 사용하는 것은 옵션이 아닌가요? 나는 그것이 "해결 된"텍스트 노드라고 생각했습니다 ...

@spicyj 댓글을 수정해주셔서 감사합니다.

@isiahmeadows 가 그의 예에서 제기한 문제를 해결하기 위해: 새로운 Mithril 엔진은 @isiahmeadows 가 몇 가지 이유로 제안한 의미 체계를 따르지 _않습니다_:

• 이러한 의미론을 구현하면 diffing이 _상당히_ 더 복잡해집니다.
• 키 공간이 구성 요소에서, 심지어 형제 및 하위 구성 요소로 흘러 들어갈 수 있기 때문에 키 및 키 관련 버그에 대해 추론하기가 어렵습니다.
• 조각 수명 주기를 직관적이지 않게 만듭니다(예: 이 예에서 B.bar 가 제거되지만 조각도 제거되고 C를 래핑하기 위해 새 조각이 생성됨). 이는 수명 주기가 "계단식"이라는 일반 원칙에 위배됩니다. 즉, 주어진 부모 노드가 제거되면 자식 노드가 제거되는지 더 이상 확신할 수 없습니다. 이전 요점과 마찬가지로 이는 구성 요소의 캡슐화 기능에 누수가 발생할 가능성이 있습니다.
• 가설적으로, 이러한 의미 체계를 준수하지 않는 diff 엔진과 관련된 diff 문제가 발생하면 애플리케이션 공간 솔루션은 문제가 되는 노드 주위에 조각을 래핑하는 것만큼 간단합니다.

핵심 팀이 맨 위에 있는 메모를 확장할 수 있는지 관심이 있습니다. _이유는 현재 아키텍처에서는 어렵습니다. React와 Mithril의 렌더링 엔진이 근본적으로 동일한 문제를 해결하려고 노력하고 있고 Mithril이 이제 실현 가능하고 유용하다고 생각하는 정도로 단편을 지원한다는 것을 알면 의미론의 다른 측면이 있는 경우 React에서 구현하는 것이 더 실현 가능할 수 있습니다. Mithril에서와 같이 개별적으로 평가되고 잠재적으로 거부됩니다.

내 의견을 수정했습니다. 나는 몇 가지 실수를 저질렀고 GitHub는 이메일 응답을 잘 스타일링하지 못했습니다... : 인상을 찌푸리며:

@Primajin 저도 그게 궁금했는데 하나의 요소로 전달되었을 것 같아요. 조각을 구성 가능하게 만드는 것이 중요합니다(위의 예 참조 ). 그러나 그것들을 하나의 단위로 취급하고 싶을 때가 있을 것입니다.

아마도 React.Children.map 는 조각을 확장해야 합니다. 모든 자식(자식 조각의 자식 포함)을 반복하려면 Children.map 를 사용하십시오. 프래그먼트를 불투명한 상자로 처리하려면 props.children을 {array, element}로 직접 사용하세요.

@lhorie 나는 재작성에 관여하지 않았기 때문에 그 복잡성에 익숙하지 않습니다. 이번 주에 기말고사가 1회, 다음 주에 3회가 있다는 사실로 바빴습니다. 게다가 대학에서 요구하는 인턴십을 준비하기 위해 누군가와 함께 일하고 있습니다. 나는 또한 _거의_ CLI를 완료한 Techtonic을 마무리하는 데 집중했습니다(테스트가 중단되어서는 안 됩니다).

@isiahmeadows 주제에 대한 친절한 알림입니다. 다른 주제에 대해 이야기하고 싶다면 mithril gitter room을 자유롭게 이용하세요.

@appforartists

아마도 React.Children.map은 조각을 확장해야 합니다.

Mithril stable은 내부적으로 유사한 작업을 수행하지만(즉, 하위 배열 병합) 성능상의 이유로 해당 모델에서 멀어지고 있습니다. 고려해야 할 사항일 수 있습니다.

HTML 주석과 같은 "의사" 래퍼 요소를 사용하는 것은 옵션이 아닌가요? 나는 그것이 "해결 된"텍스트 노드라고 생각했습니다 ...

우리는 몇 달 동안 프로덕션에서 https://github.com/mwiencek/react-packages 를 사용해 왔습니다. 이 주석 래퍼 접근 방식을 사용하므로 조각을 명확하게 중첩할 수 있습니다.

@mwiencek 맞춤형 반응 패키지 없이 접근 방식을 사용할 수 있습니까?

@mwiencek 주석 래퍼가 필요합니까? 나는 조각에서 영리한 것을 기대하지 않을 것입니다. 조각에서 요소를 형제 조각이나 루트 요소로 이동하면 다시 만들 수 있습니다.

따라서 vdom 트리를 순서대로 따르면 주석이 필요하지 않습니까?

어쨌든, 귀하의 솔루션은 언뜻 보기에 이 문제를 해결하는 데 필요한 것처럼 보입니다. 👍

엄격하게는 아니지만 이 경우 구현을 더 간단하게 만들었습니다.

따라서 본질적으로 현재 React로 적절한 설명 목록 <dl> 을 만드는 것이 불가능합니까?

<dl>
  <dt>Def 1</dt>
  <dd>Some description</dd>
  <dt>Def 2</dt>
  <dd>Some other description</dd>
</dl>

@KaiStapel 이 문제는 render() 에서 여러 구성 요소(또는 내가 추측하는 요소)를 반환하는 것에 관한 것입니다. render 함수가 하나의 루트 요소/구성 요소만 반환하는 한 작동해야 합니다.

좋아요:

render() {
  return (
    <dl>
      <dt>Def 1</dt>
      <dd>Some description</dd>
      <dt>Def 2</dt>
      <dd>Some other description</dd>
    </dl>
  )
}

정상이 아님:

render() {
  return (
    <h2>my list</h2>
    <dl>
      <dt>Def 1</dt>
      <dd>Some description</dd>
      <dt>Def 2</dt>
      <dd>Some other description</dd>
    </dl>
  )
}

@GGAlanSmithee 하드 코딩되어 있지만 할 수는 없습니다.

<dl>
   loop here and print out dt/dd pairs
</dl>

매우 슬프다. 한 번에 두 개의 <tr> 요소를 렌더링할 수 없기 때문에 rowspan이 있는 테이블도 마찬가지입니다.

상단에서:

"Me too" 및 "+1"은 가치가 없으며 이미 주석에 작성된 사용 사례도 아닙니다(예: <tr> 또는 <dd> 요소를 <div>와 함께 넣을 수 없다는 것을 알고 있습니다). .

https://github.com/mwiencek/react-packages 에 작동하는 솔루션이 있다는 점을 감안할 때 이것이 곧 React의 일부가 될 가능성이 있습니까? 아니면 새로운 조정자를 기다리고 있습니까?

https://github.com/mwiencek/react-packages 에 작동하는 솔루션이 있다고 가정하면

실제 프로젝트에서 성공적으로 사용하고 있습니까?

@mwiencek

구현은 그다지 아름답지 않지만 사람들에게 효과가 있다면 PR을 제출하고 React 개발자가 그것을 분해하도록 할 수 있습니다.

물론, PR을 보내주세요!

PR 제출에 관해 @spicyj 로부터 마지막으로 들은 것은 그들이 새로운 핵심 알고리즘을 완성하고 이에 적절한 솔루션을 하고 싶다는 것이었습니다. 왜냐하면 주석 노드는 React Native에서 실제로 의미가 없기 때문입니다. 나는 그 상태를 따르지 않았지만 그 계획이 변경되었다고 생각하지 않습니다. 그 동안 사람들이 패키지가 유용하다는 것을 알게 되어 기쁩니다.

새로운 알고리즘 은 작업 중이며 단편을 지원합니다. 그러나 나는 그것이 앞으로 몇 달 동안 생산 준비가 될 것이라고 기대하지 않습니다. 이것을 React DOM에 먼저 추가하고 나중에 React Native에 추가하는 것이 너무 나쁜 것인지 궁금합니다. 단점은 생태계를 약간 조각화한다는 것입니다. 우리는 오늘 팀 회의가 있으므로 더 잘 이해할 시간이 있으면 이 질문을 제기하겠습니다.

@gaearon 지원하는 프래그먼트가 매우 간단하고 설탕일 뿐이라는 점을 지적할 수 있습니까? 저는 현재 작은 사소한 래퍼를 통해 직접 <frag> 를 사용하고 있습니다. 여러 자식을 구성 요소 루트로 반환하는 것이 실제로 그렇게 중요한가요?

@syranide 베타 환경에서 frag와 함께 사용자 정의 빌드를 사용하고 있지만 대신 공식 React 빌드를 사용하고 싶습니다. <frag> 래퍼를 제공할 수 있습니까? :) 감사 해요

@amertak

import React from 'react';
import createFragment from 'react-addons-create-fragment';

let nativeCreateElement = React.createElement;

React.createElement = function() {
  if (arguments[0] !== 'frag') {
    return nativeCreateElement.apply(this, arguments);
  }

  let length = arguments.length;
  if (length <= 2) {
    return null;
  }

  let children = {};
  for (let i = 2; i < length; i++) {
    children['~' + (i - 2)] = arguments[i];
  }

  return createFragment(children);
};

우리는 지난 팀 회의에서 이에 대해 더 많이 이야기했습니다. 합의는 우리가 이 특정 구현을 원하지 않는다는 것입니다. 그러나 이 기능은 장기적인 핵심 재작성에서 지원될 것입니다(현재로서는 이에 대한 일정 없음).

또한 다시 작성하는 데 시간이 너무 오래 걸리거나 제대로 작동하지 않을 경우 올해 하반기에 작업할 수 있는 작업 중 하나로 다시 고려할 것입니다. 목록에 포함될 것이라는 보장은 없지만 올라오면 계속 업데이트하겠습니다.

우리가 무엇을 하고 있는지 더 잘 이해하려면 회의록 리포지토리를 참조하세요! https://github.com/reactjs/core-notes/blob/master/2016-07/july-07.md에서 이에 대한 최신 토론을 찾을 수 있습니다.

@gaearon 적어도 공식적인 frag-syntax를 가지고 있다는 것은 흥미로울 것입니다.

@syranide 코드 감사합니다. 하지만 불행히도 ReactDOM.render 메소드로 렌더러되는 루트 앱 구성 요소로 frag 가 필요하고 이 메소드는 프래그먼트를 허용하지 않기 때문에 사용할 수 없는 것 같습니다. .

어쨌든 감사합니다. frag 앱 루트가 필요하지 않은 다른 사람들에게 유용할 것입니다.

@amertak 예, 조각을 생성하기 위한 보다 합리적인 구문을 활성화하기 위한 것일 뿐이며 새로운 기능을 추가하지 않습니다.

@syranide
수동으로 주석을 렌더링하고 처리가 다른 구성 요소로 간주되는 경우(필요하지 않을 수 있음) 생각하고 있었습니다.
내부적으로 주석은 #comment 유형으로 처리되므로 호출할 수 있습니다.
React.createComponent('#comment', { ... }, children) ?
그냥 아이디어입니다. 작은 해결 방법.

여기서 빠진 핵심은 comment 노드를 렌더링할 수 있다는 것입니다. 맞습니까? :)

@gaearon 이게 빨리 오지 않아 조금 아쉽긴 하지만 투명하게 봐주셔서 감사합니다. 잘 쓰세요!

업데이트까지 대체 솔루션?
나를 위해 Botstraap 의 드롭다운 메뉴를 렌더링해야 합니다.

render(){
    return (
        <ButtonNotification/>
        <ul className="dropdown-menu">
            {this.state.items.map(this.addItem)}
        </ul>
    );
}

ReactDOM.render(
    React.createElement(NotificationHandler, null),
    document.getElementById("listNotification")
);

그러나 불가능하다, 아이디어?
감사 해요,

http://getbootstrap.com/components/#btn -dropdowns-single

문서에 표시된 대로 단일 <div class="btn-group"> 로 명확하게 래핑됩니다.

예, 하지만 <div class="btn-group"> 에 래핑된 두 개의 요소가 있습니다.

render(){
    return (
        <ButtonNotification/> //ELEMENT 1
        <ul className="dropdown-menu"> //ELEMENT 2
            {this.state.items.map(this.addItem)}
        </ul>
    );
}

ReactDOM.render(
    React.createElement(NotificationHandler, null),
    document.getElementById("listNotification") //is DIV#listNotification
);

<div id="listNotification" class="btn-group"><!--wrap-->
    <a href="#">button notification</a> <!--ELEMENT1-->
    <ul> <!--ELEMENT2-->
        <li></li>
        <li></li>
    </ul>
</div>

그리고 단일 요소에 두 개의 요소를 래핑하는 것은 불가능하며,
시간 내주셔서 감사합니다 @Primajin

모든 것을 한 단계 이동하십시오.

render(){
    return (
        <div className="btn-group"> //WRAP
            <ButtonNotification/> //ELEMENT 1
            <ul className="dropdown-menu"> //ELEMENT 2
                {this.state.items.map(this.addItem)}
            </ul>
        </div>
    );
}

ReactDOM.render(
    React.createElement(NotificationHandler, null),
    document.getElementById("listWrapper") //or whatever your list is called
);

알겠습니다. 하지만 상위 항목에 다른 항목이 있습니다.
이렇게 하면 문제만 이동합니다.

<div ...> <--!listWrapper-->
    <div class="btn-group">....</>
    <div class="btn-group">....</>
    <--!React-->
    <div class="btn-group"> //WRAP
        <ButtonNotification/> //ELEMENT 1
        <ul className="dropdown-menu"> //ELEMENT 2
            {this.state.items.map(this.addItem)}
        </ul>
    </div>
    <--!React-->
    <div class="btn-group">....</>
</div>

그리고 이 경우 React는 포함된 모든 것을 대체합니다.
다른 요소를 교체하지 않고 "추가"를 수행할 수 있습니까?

감사 해요,

@rifton007 작동 방식이 아닙니다. 컨테이너에 래핑된 여러 요소/구성 요소를 형제로 가질 수 있습니다. 제한 사항은 구성 요소가 여러 요소를 return 할 수 없다는 것입니다. 방금 게시한 코드가 작동합니다.

즉, 작동하지 않는 예제를 생각해 냈다면 전체 스레드를 읽고 _new_ 예제를 추가할지 아니면 이미 확인된 동일한 문제를 반복할지 여부를 고려하는 것이 예의입니다. 이것은 알려진 제한 사항이며 이 스레드에는 제한 사항에 대한 자세한 내용과 추론이 포함되어 있습니다. Dan은 또한 궁극적으로 이 지원을 수정할 계획이라고 밝혔습니다. 확인된 문제에 대한 다른 예를 지적하여 무엇을 달성하려고 합니까?

죄송합니다. 그동안 다른 솔루션이 있으신 분이 있는지 알고 싶었습니다.
필요한 경우 내 게시물을 삭제할 수 있습니다.

Framework7 및 React로 앱을 생성하지만 framework7 html 형식은 고정되어 있습니다.

<div class="page"><div class="navbar"></div><div class="searchbar"></div><div class="page-content"></div><div class="toolbar"></div></div>

'페이지' 클래스가 없는 다른 div의 첫 번째 수준 하위 요소(navbar, searchbar)를 래핑할 수 없습니다.

행 목록을 반환하는 구성 요소가 있습니다.

참고로, 우리가 작업 중인 재작성(#6170)은 이미 조각을 지원합니다. #7925 및 http://isfiberreadyyet.com에서 진행 상황을 추적할 수 있습니다.

<table> 요소가 특정 요소를 렌더링할 수 없다는 사실만으로도 Web API와 호환되도록 이 기능을 추가할 수 있습니다.

편집: 아, 파편! 그들을 기대합니다.

@trusktr

이 스레드의 첫 번째 게시물에서 언급했듯이:

유지 관리자의 참고 사항:

우리는 이것이 문제 라는 것을 알고 있으며 어떤 문제 세트를 해결할 수 있는지 정확히 알고 있습니다 . 우리도 이것을 원하지만 현재 아키텍처에서는 어려운 문제입니다. 이 기능에 대한 욕구를 표현하는 추가 의견은 도움이 되지 않습니다.

😉

젠장, 그만해야겠어.

나는 이것을 찬성했지만 유효한 사용 사례를 공유하고 싶었습니다. CSS 유동 레이아웃(왼쪽, 가운데, 오른쪽)을 원하는 3개의 버튼이 있다고 가정합니다. 왼쪽 버튼은 항상 표시되지만 다른 두 버튼은 조건부로 표시됩니다. React(특히 React Native)에서 flexbox를 사용하고 다음과 같이 렌더링합니다.

[ Left ] { renderCenterAndRightButtons(this.state.someFlag) }

중앙 및 오른쪽 버튼은 단일 보기로 래핑되기 때문에 올바르게 배치되지 않습니다.

예, 중앙 및 오른쪽 버튼을 고유한 방법으로 분할할 수 있지만 많은 동작을 공유하기 때문에 중복 코드가 많이 발생합니다.

[ Left ] { renderCenterButton(this.state.someFlag) } { renderRightButton(this.state.someFlag) }

위에서 말했듯이 우리는 이미 이 기능의 사용 사례를 알고 있으며 지원하기 위해 열심히 노력하고 있습니다. (위에서 이미 6명의 사람들이 플렉스박스 문제를 언급하고 있습니다.) 더 이상의 논의가 생산적이지 않을 것 같아서 잠그고 있습니다. 새로운 구현에 대한 소식이 있으면 업데이트하겠습니다.

우리가 이것을 닫을 수 있다고 생각합니다.

구성 요소에서 배열을 반환하는 것은 지금 시도할 수 있는 React 16 Beta 1 부터 지원됩니다.

아직 몇 가지 제한 사항(SSR 지원이 준비되지 않음)이 있지만 #8854에서 이를 추적하고 있으며 최종 16 릴리스 전에 수정될 것입니다.

피드백을 주신 모든 분들께 감사드립니다!

댄 감사합니다

🍾🍾🍾

🦏

@gaearon 멋진 개선! 순수 텍스트 노드를 지원합니까?

예, 반환 문자열도 지원합니다.

이것이 어떻게 작동하는지 여쭤봐도 될까요?

2개의 인접한 XJS 요소를 렌더링할 수 있기를 바랐지만 return ["foo", "bar"] (더 유용한 것 ;)를 수행하면 예상되는 bundle.js:66656 Warning: Each child in an array or iterator should have a unique "key" prop. 를 얻습니다.

그렇다면 이 기능은 외부 요소로 실제 목록을 둘러싸지 않는 방법이었습니까?

그렇다면 이 기능은 외부 요소로 실제 목록을 둘러싸지 않는 방법이었습니까?

예, 하나의 렌더에서 여러 요소를 제공하는 방법입니다. (자세한 내용은 초기 발행 게시물을 참조하십시오.)

모든 배열 항목이 문자열로 알려져 있는 경우에는 이들을 결합하고 단일 문자열을 반환하기만 하면 됩니다. 그렇지 않은 경우 이 경고를 확인하거나 JSX의 다른 요소 내부에 문자열 배열을 포함했을 때와 마찬가지로 DOM 조정을 개선하기 위해 키를 지정할 수 있도록 요소에 요소를 래핑하기 위해 수행할 작업을 수행할 수 있습니다.

['foo', 'bar'] 를 반환 하는 @diligiant 는 이 문제와 관련이 없습니다. return <div>{['foo','bar']}</div> <div> 와 같은 내부 jsx 태그에 있든 반환 중이든 배열의 각 자식에는 'key' 소품이 있어야 합니다. 지금 할 수 있는 일은 다음과 같습니다.

return [<div key='1'>foo</div>, <span key='2'>bar</span>];

반응의 큰 제한을 제거합니다.

['foo', 'bar'] 를 반환하는 Btw는 오류가 아닌 경고를 제공하며 해당 경고를 제거하려면 해당 문자열을 쉽게 조인하거나 문자열이 아닌 jsx 태그인 경우 키 소품을 추가할 수 있습니다. 따라서 배열을 반환하는 데 제한이 없습니다.

@JesperTreetop 감사합니다.
@sassanh , 귀하의 예에서 나는 주변의 (의미상) 쓸모없는 <div> 를 피하기 위해 "그냥" 키를 사용하기에는 너무 "부끄러워"한 것 같습니다. 계속 진행해야 하며 실제 성능 저하가 없다는 것을 의미합니까? 그것은 정말로 진정한 개선이 될 것입니다!

@diligiant 성능 저하가 발생하는지 의심스럽지만 주변 문자열이 아니고 주변 문자열이 아니면 배열을 전혀 피하고 문자열을 결합할 수 없다면 주변의 쓸모없는 div 가 필요하지 않습니다. 문자열이 아닌 경우 구성 요소에 키를 추가할 수 있습니다. 예를 들어 Foo 및 Bar 두 개의 구성 요소가 있는 경우 [<Foo key='foo'/>, <Bar key='bar'/>] 를 반환할 수 있으며 구성 요소(항상 그렇듯이)나 배열(덕분에 이 새 릴리스에서는 16) 이전에 어레이를 둘러싸야 했습니다.

@sassanh 그럼 멋져요. 물론 내 사용 사례는 여러 구성 요소에 대한 것이었습니다. 행복하다!! ;)

사실 모든 항목이 문자열일 때 누락된 키에 대해 경고하는 것이 이상하게 보입니다. 나는 우리가 그렇게 할 것이라고 기대하지 않을 것입니다. 문자열이 div 안에 있을 때 15의 기존 동작입니까? 그렇지 않은 경우 최상위 문자열에 대해 16에서 수정해야 합니다(키를 제공하는 것이 불가능하기 때문에).

@gaearon 죄송합니다. 제 예는 오해의 소지가 있습니다. 구성 요소를 의미했습니다.

확인하고 -beta.5 아래에서 React는 여러 문자열이 있는 배열을 렌더링할 때 경고를 발행하지 않습니다.

그럼에도 불구하고 주변 구성 요소를 피하기 위해 배열을 렌더링할 때 key 요구 사항에 의아해합니다. 나는 이해하고 아무 것도 아니지만 아마도 SO에 대한 수많은 질문을 제기할 것입니다.

그리고 마지막으로 다시 한 번 감사드립니다.

이 경고는 조정자에 대해 정확히 동일한 "추가 작업"으로 요약되고 따라서 key 를 설정하여 완전히 동일한 잠재적 최적화로 요약되기 때문에 구성 요소 배열의 다른 모든 사용과 정확히 동일합니다. 나에게 놀라운 것은 구성 요소 배열이 이것에 따라 다르게 처리되어야 하고 스택 오버플로 질문도 발생할 수 있다는 것입니다. 말할 것도 없이 처음부터 그것을 추적하는 데 약간의 오버헤드가 포함될 것이라고 생각합니다.

.. 대부분의 경우 함수에서 배열을 반환할 것이므로 key 경고가 표시 되기를 원합니다. 경고를 원하지 않는 경우는 소수이며 React가 경고하지 않는 것이 적절한지 알 수 있는 방법이 없습니다.

키가 없으면 성능 문제뿐만 아니라 정확성 문제가 발생할 수 있으므로 경고가 필요합니다. 이것은 왜 키가 필요한지 묻는 다른 많은 문제에 설명되어 있으므로 해당 토론을 검색하여 읽어보시기 바랍니다. 나는 문서가 이것에 대해 더 명확할 수 있다는 데 동의하고, 다음에 문서 변경 스프린트를 할 때 살펴볼 것입니다.

render에서 직접 반환된 배열과 div 내부의 배열 사이에는 개념적 차이가 없습니다. 따라서 한 경우에는 주요 경고가 표시되고 다른 경우에는 표시되지 않을 이유가 없습니다. 키가 없을 때 둘 다 동일한 문제의 영향을 받기 때문에 동일한 방식으로 작동해야 합니다.

즉, 정적 콘텐츠에 키를 지정하는 것이 짜증난다는 것을 이해합니다. 자식이 정적으로 알려진(따라서 재정렬되지 않음) JSX 구조를 작성할 때 키를 지정하지 않는 것과 마찬가지로 배열을 사용하여 이 작업을 수행하는 방법이 있으면 좋을 것입니다.

미래에는 다음과 같은 구문을 사용하여 JSX의 조각에 대한 명시적 지원을 추가하여 이 문제를 해결할 수 있습니다.

return (
  <>
    <div>child 1</div>
    <div>child 2</div>
  </>
);

배열을 생성할 수 있지만 암시적으로 숫자 인덱스를 자식에 할당할 수 있습니다. 이 경우 순서를 변경할 수 없다는 것을 알고 있기 때문입니다. JSX 자식 표현식이 제공하는 이러한 보장 덕분에 div에 여러 자식이 있을 수 있는 일반 JSX 코드에서 키를 지정하지 않고도 빠져나갈 수 있습니다.

하지만 아직 이 구문이 없습니다. 따라서 현재로서는 이것이 알려진 제한 사항입니다.

@JesperTreetop & @zwily , @gaearon 이 저보다 훨씬 잘 설명했습니다 ;)

아시다시피, 그것은 큰 문제가 아니지만 우리 모두는 React가 번성하기를 원하기 때문에 저는 단지…

@gaearon <> 구문 제안에 대해 이 문제에 대한 추가 논의 대신 지켜볼 수 있는 또 다른 문제가 있습니까? 이리저리 검색했지만 찾을 수 없었습니다.

@smrq +1 질문 — 저는 그 어색한 제한(일대일 rendrer() 결과, 키 및 JSX 구문 또는 조각)에 대한 모든 것을 따르지만 제가 아는 유일한 티켓은 https://github.com/ 입니다.

나는 또한 섬유가 키 문제를 전혀 해결할 것이라고 생각하지만 실현되지 않은 꿈처럼 보입니다.

키는 "문제"가 아닙니다. :) 그것들은 동적 목록을 생성할 수 있게 해주는 모든 보기 프레임워크의 기본적이고 필수적인 부분입니다.

자세한 설명은 https://facebook.github.io/react/tutorial/tutorial.html#keys 를 참조하세요.

@spicyj 실제로 개발자의 에너지 지출을 늘리고 이러한 요구 사항 없이 보기 프레임워크를 프로그래밍할 수 있는 근본적인 가능성이 있기 때문에 «문제»입니다(예: https://github.com/dfilatov/vidom).

이러한 요구 사항 없이 보기 프레임워크를 프로그래밍할 수 있는 근본적인 가능성이 있습니다(예: https://github.com/dfilatov/vidom).

vidom은 컬렉션에서 키를 사용합니다. 기술적으로 없이는 작동할 수 있지만 훨씬 느릴 것입니다. React는 기술적으로 키 없이도 작동할 수 있지만 목록에서 단일 항목을 제거할 때 구성 요소의 절반이 업데이트되어야 한다는 것을 발견하는 것은 매우 예상치 못한 일입니다. 키를 사용하면 하나의 항목만 마운트 해제됩니다.

@goto-bus-stop vidom은 키를 사용할 수 있지만 필수는 아니며 업데이트가 많은 정말 큰 경우에만 실제 성능 문제가 발생할 수 있습니다.

그래서 나는 이 부분을 개별 경우에 성능 조정에 사용할 수 있는 가능한 선택 사항(예: shouldComponentUpdate )으로 간주합니다.

@veged 키 없이 고군분투하는 vidom의 예 .

요소를 재정렬해야 한다는 사실을 알지 못하므로 루트 구성 요소의 각 렌더링에서 인스턴스를 버립니다.

가상 돔 공간 [1]에 아주 익숙한 사람으로서. 나는 말할 수 있습니다 :

1. 키는 유사한 형제 간에 예측 가능한 dom 및 state 업데이트에 필요합니다.
2. 키는 일반적으로 최적화가 아니며 실제로는 일반적으로 그 반대입니다.

[1] https://github.com/leeoniya/domvm

그러나 여기서 명확한 문제( @gaearon 이 설명함)는 어레이의 완전한 정적 사용법과 정적 어레이와 정적 JSX 조각 간의 차이점입니다.

@brigand O는 상태 전체 구성 요소를 재정렬하면 몇 가지 문제가 발생할 수 있다는 데 의심의 여지가 없습니다. ;-) 그러나 다른 모든 경우(내 생각에는 더 많은 경우)가 이를 위해 고군분투해야 합니다... 논란의 여지가 있어 보입니다.

키 는 React에서 중요합니다. 어떤 경우에는 중요하지 않은 것처럼 보이더라도(예: 아래 구성 요소가 모두 상태 비저장이기 때문에) 귀하 또는 팀의 다른 누군가가 몇 수준 아래에 상태 저장 구성 요소(또는 일반 DOM 입력)를 추가하는 것을 방해하는 것은 없습니다. 몇 달 안에. 그때쯤이면 키가 없다는 사실을 잊어버릴 수 있으므로 재정렬로 인해 상태(또는 입력 값)가 잘못된 항목과 연결될 수 있습니다.

이것이 동적 목록에 대해 모든 곳에서 키를 지정하도록 권장하는 이유입니다. 그렇게 하지 않으면 추적하기 매우 어려운 버그가 발생합니다. 우리는 10시간 동안 키를 지정하는 것보다 추가로 10초를 보내는 것이 코너의 경우 여러 수준 아래에 있는 구성 요소의 상태가 엉망이 되는 이유를 디버깅하는 것보다 낫다고 생각합니다.

목록이 정적이고 재정렬되지 않는 것으로 알려졌을 때 키를 지정하는 것이 불편하다는 데 전적으로 동의합니다. JSX 리포지토리에서 이에 대해 논의할 수 있습니다. 이에 대한 문제를 찾을 수 없는 경우 새 문제를 만들 수 있습니다.

이 스레드는 구독자가 많고 기능이 구현되었으므로 많은 사람들에게 알림으로 스팸을 보내지 않도록 잠그고 싶습니다. 위의 설명이 귀하의 우려 사항을 해결하기를 희망하지만 그렇지 않은 경우 특정 주제에 대한 추가 토론을 위해 새 문제를 생성할 수 있습니다.

@smrq 는 jsx 저장소 https://github.com/facebook/jsx/issues/84 에서 <> 구문에 대한 제안 문제를 만들었습니다.

새로운 React.Fragment 내보내기 및 관련 <> 구문에 대한 지원을 방금 출시했습니다.
https://reactjs.org/blog/2017/11/28/react-v16.2.0-fragment-support.html