あなたがラッパーを置かないとき、それはこれに脱糖するので：

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

これは構文的に意味がありません。 視覚的なマッピングが必要な場合は、 jsxコンパイラページが役立つ場合があります。

そうは言っても、代わりにこれを[div, div]に脱糖することは可能です。 これは難しく、やや物議を醸すものであり、近い将来実装されることはありません。

（特に物議を醸すとは思いませんが、コードが複雑になり、まだ実行されていません。）

IIRC@ syranideはこれについていくつかコメントしています

@chenglouHehe 。

少し前にチェンロウと簡単なチャットをしましたが、今はどちらにも傾いていません。 複合コンポーネントが複数のコンポーネントを返すことを許可することには多くの隠れた危険があり、多くの直感的な仮定を破りますが、これから明らかに恩恵を受ける（現時点では）優れたユースケースはわかりません。

最大で1つのコンポーネントを返すという単純さは、表示される内容について推論するのが非常に簡単であることを意味します。そうでない場合、 <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>コンポーネントをハッキングしましたこれは配列に変換されます（オーバーロードされたReact.render ）...ハッキングを避けたい場合は、 return <NoopComp>...</NoopComp>.props.childrenを実行することもできます。

編集：私の悪い、私はReact.render React.createElementをオーバーロードしました。

アレイの問題は、それらが私たちのデザイナーをつまずかせることです。 カンマ、明示的なキーが必要です。

@gaearonええ、今のところ私の2つの回避策のいずれかを使用してコンマを回避できます（どちらかが許容できる場合）...しかし、明示的なキーで何を意味するのでしょうか？

配列構文を使用する場合は、各要素に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。 しかし、今のところ回避でき、実装が難しく、まれであることを理解できます。

私は（まだ）react internalsについては何も知りませんが、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と競合しないようにネストされたreactidを含む）。 私は、他のフレームワークがこれらの種類のセマンティックジョブに対してコメントを「誤用」するのを見てきました。

@PrinzhornDOM出力とReactのJSXを混同しているのではないかと思います。

役に立つ場合： @PrinzhornがHTMLコメントを使用して「フラグメントコンポーネント」をDOMにマップするという提案は、Knockoutが使用するのと同じアプローチです。 ノックアウトはこれらを「仮想要素」と呼びます。

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

（ノックアウトドキュメントから）

また、これの別の使用例-フレックスボックスを使用する場合、余分なラッピング要素が問題になる可能性があります。

@aldendanielsは絶対に同意します、私はすでにフレックスボックスの問題に遭遇しました。

ドロップダウンが依存するフレックスボックスでこれに遭遇しました。 Aが最初のドロップダウンをレンダリングして管理し、次にAのドロップダウンの値に応じてB、C、またはDが続き、それぞれが適切な数のドロップダウンをレンダリングします。

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

A、B、C、およびDはステートレスであるため、 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>
)
...

また、いくつかのフレックスボックスの問題に遭遇しました。 CSSで解決できないことはありませんが、フレックスボックスの「美しさ」の1つは、レイアウトを機能させるために必要な「ラッパー」要素が少なくて済むことです。コンテナを持つことが理にかなっている場合を除いて、返すものはすべてdiv/divなどでラップします。

ここに示すすべてのユースケースについて、 <BunchOfComponents />を{getBunchOfComponents()}に置き換えることができ、コンポーネントの使用に関連する実用的および技術的な問題を導入することなく、視覚的な出力は同じになると確信しています。ルートとしてのフラグメント。

@syranideですが、コンポーネントの1つが変更されるたびに、すべての兄弟を再計算する必要があります...

また、プレーンなコーヒースクリプトを使用すると、配列を簡単に返すことができるため、jsx表現から機能を切り離してください。
返された要素の配列を処理するのが簡単な場合は、jsxが追いつくのを待たないでください。

@syranideですが、コンポーネントの1つが変更されるたびに、すべての兄弟を再計算する必要があります...

@wmertensはい。ただし、親が他の理由で再レンダリングする必要があるため、または単に小道具を介してデータを受信するため、とにかく多くの場合それがあります。 はい、それは違いですが、それはこのアプローチが正しいことを意味するものではありません。それは最適化であり、それらを達成するための多くの方法があります。

また、プレーンなコーヒースクリプトを使用すると、配列を簡単に返すことができるため、jsx表現から機能を切り離してください。

これは関係ありません。これはJSXの問題ではありません。 大きな問題は、1つのコンポーネント=1つの要素/ノードという技術的で実用的かつ直感的な仮定を失うことです。 私は開発者のために話すことはできませんが、それを喜んで諦めません。それは非常に有用な仮定です。 最適化が人々がこれを望む唯一の理由である場合、設計できる同等に優れた、またはより良い最適化があると確信しています。

@syranide最大の問題は、常にラッピングを使用できるとは限らないことです
テーブル、リスト、フレックスボックス、ヘッドなどのhtmlの要素...回避策
それは醜いコードにつながります。

レンダリングするだけの仮想ラッパー要素に完全に満足します
前に提案したように、コメント。

2015年5月29日金曜日、午後3時56分Andreas [email protected]
書きました：

@syranide https://github.com/syranideですが、毎回
コンポーネントは、すべての兄弟を変更し、再計算する必要があります...

@wmertens https://github.com/wmertensはい、でも何度もそうします
親が他のために再レンダリングする必要があるので、とにかくそれを持っています
理由、または単に小道具を介してデータを受け取るため。 だが
はい、それは違いですが、それはこのアプローチが正しいという意味ではありません、
これは最適化であり、それらを達成するための多くの方法があります。

また、プレーンなコーヒースクリプトを使用すると、配列を簡単に返すことができるので、どうぞ
機能をjsx表現から切り離します。

これは関係ありません。これはJSXの問題ではありません。 大きな問題はそれです
_oneの技術的、実用的、直感的な仮定を失います
コンポーネント=1つの要素/ノード_。 私は開発者のために話すことはできませんが、私はしません
喜んでそれをあきらめる、それは持っていることは非常に有用な仮定です。 私は確信しています
次の場合に設計できる、同等またはそれ以上の最適化があります。
最適化は人々がこれを望む唯一の理由です。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/facebook/react/issues/2127#issuecomment-106810565 。

fwiw、Reactによって子の配列として扱われるReactに「フラグメント」コンポーネントをハッキングするのは比較的簡単です。 キーは自動生成されますが、コンポーネントの初期検証後に発生するため、通常の「キーが提供されていません」というエラーはスローされません。

そうは言っても、そのハックは@gaearonが上で話していたことを解決するだけであり、JSXで醜い配列構文を処理したり、任意のキーを設定したりする必要はなく、コンポーネントのrenderメソッドのルートで複数のノードを返す問題は解決しません。

コンポーネントが1つの「要素/ノード」を返す必要があるという考えに問題があります。 私には、次の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(...)は、（他の必要なサポート機能を含めて）あらゆる面で優れたソリューションです。

コンポーネントが1つの「要素/ノード」を返す必要があるという考えに問題があります。 私には、次のJSX構造には完全に合理的であるように思われます。

コンポーネントは単なる単なるラッパーではなく、目的があります。 私見では、複数の要素を返すと、いくつかの非常に有用な期待が妨げられるようです。 たとえば、 React.renderは将来、要素をレンダリングしてノードを返すコンパニオンを取得します。これにより、代わりにノードの配列を生成する必要があります。

しかし、非常に重要な問題は、IMHOがReactの最大のセールスポイントである読みやすさの問題だと思います。すべてが明確です。

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

それを見て意味がありません、3番目のセルはどこから来ていますか？ おそらくそれは実際には間違っていて、2つまたは4つのセルをレンダリングしているのだろうか、おそらくそれは実際には動的であり、支柱または外部状態に依存しているのだろうか？ この問題には多くのバリエーションがあり、明示的な期待を持っている可能性のある他の非HTMLDOMフロントエンドを検討する場合にのみ厄介になります。 考慮すべきもう1つの点は、要素が不透明であるため、 <tr />を<MyMagicalTr />に置き換えると、個々のセルと相互作用したり、セルの数を推測したりすることができなくなり<MyMagicalTr /> 。 <MyMagicalTd />のみを受け入れる可能性があり、実際にそれらと対話できるという保証はありません。

これには、Reactの根本的な実装の問題のために、開発者が分離された再利用可能なコンポーネントの作成に妥協する必要があります。 私はそれが受け入れられるべきではないと思います。

「これには、開発者が分離することについて妥協する必要があります...」しかし、私に言わせれば、それはまさに問題です。コンポーネントが複数の要素を返すことができる場合、それはもはや分離されておらず、置き換えられ、コンポーネントは親にリークしています。

ハンマー、釘。 根本的な実装の問題であるということは、これを実際に行うべきかどうかとは別の問題です。 それは私の決定ではありませんが、それに伴うトレードオフや他の代替ソリューションを考慮せずに、1つのまれなユースケースがどのように説得力のある議論であるかはわかりません。

私見私は{getBunchOfComponents()}の問題を見ていません、それは明白です、それは私たちが私たちの有用な期待を保つことを可能にします。 パフォーマンスが問題になる場合は、 React.createSmartFragment() （またはw / e）を使用すると、透過的な配列/オブジェクトのような型になりますが、親から独立して更新できます。

繰り返しになりますが、React開発者は（私ではなく）権威ですが、さまざまな副作用を考慮すると、ここでは説得力のある議論は見られません。 たとえそれがサポートされていたとしても、提示されたソリューションが良いパターンであることに同意するかどうかさえわかりません。

編集：明確にするために、おそらく他の明らかに有益なユースケースがあるため、コンポーネントは将来的に複数の要素を返すことができるかもしれません、特に子供を通過するコンテキスト（@thomasboytを示すものなど）では、読みやすさが維持されます。

この会話の哲学的な側面に対応する前に、もう少しコーヒーが必要だと思います（@syranideの非常に良い点に感謝します）が、実装の側面では、この昨夜、どのようにこのスコープの実行可能な変更は、このスパイクにつながります： 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にあります。これは、1つの「ノード」が突然任意の数のノードになる可能性がある場合は機能しません。これは、親を呼び出さずに発生する可能性があります。いくつかのコンポーネントの深さ（ラッピング）。 私が間違っていなければ、数が変わらない限り、Reactに複数のルート要素をサポートさせるのは非常に簡単です。

したがって、Reactで機能させることは特に難しいとは思いませんが、真に適切なソリューションはより問題があり、おそらくmountIndexを削除する必要があります。

@syranideそうです。 私が取り組んでいるソリューションは、実際にはノードの「実際のオフセット」であると思われる新しいnodeIndexを導入します（これは、戻ってmountIndexを削除する必要があることを思い出させます。私のブランチでは現在使用されていないと思います）。

ただし、ご存知のように、ルート要素の数が変更された場合、前の兄弟コンポーネントのノード数が変更されるたびにコンポーネントのnodeIndexを更新する必要があるため、これは問題があります。 それでもその解決策を見つける必要があります。

また、フレックスボックスの問題が発生しました。 @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>を<tbody>でラップすることはできますが、 <tbody>の複数のレイヤーを<tr>の複数のレイヤーでラップすることは望ましくない場合があります。

私が呼びかけたシナリオは、 <head>レンダラーになることなく、 <link> $要素と<script>要素を提供するコンポーネントを作成しようとしたものです。

この号の冒頭にメモを追加しました。 コメントする前に読んでください。 https://github.com/facebook/react/issues/2127#issue -41668009

バンプ...サーバー側で大きなニーズがあります。 <head>セクションがあるため、フラグメントをレンダリングする機能なしで完全なWebページ（doctypeを除く）をレンダリングすることは非常に複雑です。 私は現在、ミックスインと最終レンダリングの小さなロジックを介してこれを回避していますが、複数のコンポーネントのレンダリングがサポートされていれば、はるかに簡単になります。

@impinballは、これらの問題を解決するために、 react-side-effectに基づいてreact-document-titleに似たものを書き込もうとすることができます。 メタタグ、ヘッダー、タイトル、場合によってはリダイレクトについても同じことができました

私もこの問題に直面していますが、当面の回避策はありますか？ {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が隣接していることについて不平を言っていますが、とにかくメインラッパー内にあることになります。 それは私が取り除くことができればいいのに1つのラッパー要素です。

この場合、 @ 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が戻り値として配列を許可している場合は、追加の「フラグメントAPI」は必要ないようです。 JSXは、複数のルート要素を配列に変換できます。これは、他の関数の戻り値に対しても機能します。 したがって、ドキュメントと学習を必要とする追加のAPIサーフェスを導入する代わりに、Reactの制限の1つを取り除くことができます。

これは、少なくとも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で使用されているものです。

これまでのスレッドでこれについて言及されたことはありませんが、これを解決することで構成性も向上すると思います。 たとえば、セルを特定の順序でフェードさせたいグリッドがあるとします。 理想的には、ここで2つのコンポーネントが使用されます。1つはレイアウトを処理し、もう1つはアニメーションを処理します。 次のような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#

次に、インスタンス化された複数のReact要素をマウントします： https ：//github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js#L471

そして、適切な順序で生成されたすべてのマークアップを調整します。

和解プロセスを回避したくないという欠点があると思います。
フラグメントを要素として、またはフラグメントを変換の周りの砂糖構文として使用しますか？

要素としてのフラグメントは大丈夫だと思います。テキストノードや空のノードに似た新しいタイプの内部ノードを作成する必要がありますよね？ どうやって管理するのかわかりませんが。

たとえば、ルートの1つがマウント解除された場合、どのように処理しますか？ 更新を適切に処理するにはどうすればよいですか？
または、DevTools内で複数のルートをどのように管理しますか？ （明白な答え：DevToolsを修正してください...）

フラグメントは複合コンポーネントだと思います。 違いはどこにありますか？
フラグメントを実装するためにコードを複製することになった場合、Reactの内部を「元の状態」に保つために、sugar構文を実装する方がよいでしょうか。

不思議に思っていますが、私はサブツリーの質問（renderSubtreeIntoContainer）の周りでReactの内部をいじっていますが、それはある程度関連しているように感じます。 新しいサブツリーにレンダリングする場合、実際には新しいルートをレンダリングする必要があります。 したがって、ツリーレベルで複数のルートをサポートする場合、毎回新しいルートをレンダリングしますか？

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

2つの「新しいルートにレンダリング」呼び出しが発生します。

ラッパーを使用した場合、1回の呼び出しではなく、そうですか？ パフォーマンスはどうですか？ シンプル？ 正直なところ、私の気持ちは、この状況に対処するためにReactの内部に触れてはいけないということです。 むしろ、JSXでこの偉業を引き出すことができますか？ JSX構文を改善できますか？

（_免責事項_：私は内部のReactに完全に慣れているわけではなく、完全に理解していない、または理解していない部分があるかもしれません。誤解をお詫びします。）

編集：物事の修正/明確化。 また、GitHubは不思議なことにメールのスタイルを設定しているため、コードブロックを再フォーマットする必要がありました... :-(

こんにちは、ミスリルのコアコントリビューター/コミッターです。

TL; DR：APIと内部が
単純。

ちなみに、私は経験から、実装するのが_非常に_難しいことを知っています。 これ
ミスリルにも何度もリクエストされていますが、
まったくの難しさ。 それを実装するすべての試みはで失敗しました
テストスイートの少なくとも3分の1が失敗します。

私はまだ書くことを計画しているvdomライブラリの詳細を検討しています、
そしてそれはすべてを断片として扱いますが、これはあなたが持っているものです
のレンダリング部分を最初から文字通り（再）書き込む。 Reactのように、
DOMから切り離されますが、APIは大幅に異なります
概念的にはレンダリング用です。

フラグメントの落とし穴は次のとおりです。フラグメントを完全に管理する必要があります
内部的に、または適切にそれらを比較しません。 平
document.createContextualFragmentは役に立たない。 例として、
2つのツリーを変換し、レンダリングを省略します。

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

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

このための正しい変換は、 B要素とC要素の両方を置き換え、残りはそのままにしておく必要があります。 それを理解することは簡単ではなく、基本的にフラグメントの子がフラグメント内にあるという事実を無視しながら、フラグメントの子を反復処理する必要があります。

しかし、フラグメントがなくなったら、フックのセマンティクスを処理する必要があります。
shouldComponentUpdate （そのフックのReactの名前を覚えていません）。 それで
それでも、フラグメントを個別に追跡する必要があります。 あなたは彼らを比較します
親フラグメントの一部であるかのようにコンテンツがありますが、まだ
コンポーネントのために、そのフラグメントの位置を追跡します。

言い換えれば、コンポーネントはもはや本質的にそれらにリンクされていません
DOMノード。 代わりに、対応するフラグメントにリンクされています。 Reactは、他のほとんどのvdomライブラリやフレームワークと同様に、予想されるタイプであっても、本質的にコンポーネントをツリー表現に結合します。 これは、diffアルゴリズムを実装する最も簡単な方法です。
コンポーネントを処理します。 それらが分離されているとき、あなたは分離する必要があります
両方の簿記。 初期化するときにコンポーネントを初期化しない
ノード。 これで、2つの完全に別個のプロセスになりました。 するのは難しい
最初は、その後のサポートを追加するのはさらに困難です。

言葉をありがとう。 これは難しいことですが、まだやることリストに載っています。 （熱心に質問しても、@ janryWangが早く実現することはありません。）

@isiahmeadows参考までに、Mithrilの書き換えブランチはフラグメントをサポートしています。

@spicyjまだフォローしていない場合は、実装[1] [2]とテスト[1] [2]をご覧ください。 全体のdiffエンジンは約400LOCしかないので、簡単にフォローできるはずです。

@isiahmeadowsGitHubがあなたのコメントの一部を食べ​​たと思います。 コードブロックが壊れており、 <D />の最初のインスタンスが渡されたことがわかりません。

しかし、電子メールでは問題ないように見えます。 たぶんあなたはGitHubにバグを見つけましたか？

残念ながら、GitHubのマークダウン処理は、コメントが電子メールから送信された場合の動作が異なります。 コメントを編集して空白行を削除しましたが、表示されます。

元のメールをsupport@githubに転送しました。 うまくいけば、彼らはパーサーを修正することができます。 😃

@lhorieフラグメントに配列構文を使用しますか？
DocumentFragmentのポリフィルはありますか？

そして、HTMLコメントのような「疑似」ラッパー要素を使用することはオプションではありませんか？ それがテキストノードが「解決」した方法だと思いました...

そのコメントを修正してくれてありがとう@spicyj

@isiahmeadowsが彼の例で提起した懸念に対処するために、新しいMithrilエンジンは、いくつかの理由で@isiahmeadowsが提案したセマンティクスに「従わない」。

• これらのセマンティクスを実装すると、差分が_大幅に_複雑になります
• キースペースがコンポーネントから、さらには兄弟コンポーネントやサブチャイルドコンポーネントにブリードアウトする可能性があるため、キーおよびキー関連のバグについて推論することは困難です。
• フラグメントのライフサイクルが直感的ではなくなります（たとえば、この例では、 B.barが削除されますが、フラグメントも削除され、Cをラップするために新しいフラグメントが作成されます）。 これは、ライフサイクルが「カスケード」であるという一般原則に違反します。つまり、特定の親ノードが削除された場合、子ノードが削除されたことを確認できなくなります。 前のポイントと同様に、これはコンポーネントのカプセル化機能にリークを引き起こす可能性があります。
• 仮に、これらのセマンティクスに準拠していないdiffエンジンに関連するdiffの問題が発生した場合、アプリケーションスペースのソリューションは、問題のあるノードの周りにフラグメントをラップするのと同じくらい簡単です。

コアチームが上部のメモを拡張できるかどうか興味があります。現在のアーキテクチャではこれが難しい理由です。 ReactとMithrilのレンダリングエンジンが基本的に同じ問題を解決しようとしていること、そしてMithrilが実行可能で有用であると私が信じる程度までフラグメントをサポートしていることを見ると、セマンティクスのさまざまな側面があれば、Reactで実装する方が実行可能かもしれません。 Mithrilで行われたように、個別に評価されます（そして拒否される可能性があります）。

コメントを修正したことに注意してください。 私はいくつかの間違いを犯しました、そしてGitHubは電子メール応答のスタイリングをうまく行いません...：眉をひそめています：

@Primajin私もそう思ったのですが、1つの要素として渡されるのではないかと思います。 フラグメントを構成可能にすることが重要です（上記の私の例を参照）。 ただし、それらを1つのユニットとして扱いたい場合もあります。

おそらく、 React.Children.mapはフラグメントを展開する必要があります。 すべての子（子フラグメントの子を含む）を反復処理する場合は、 Children.mapを使用します。 フラグメントを不透明なボックスとして扱いたい場合は、props.childrenを{array、element}として直接操作します。

@lhorieでも、私は書き直しにあまり関わっていなかったので、その複雑さにはあまり詳しくありません。 今週は決勝が1回、来週は3回あるという事実に忙しく、さらに誰かと協力して大学で必要なインターンシップを設定しています。 また、Techtonicの仕上げにも注力しており、CLIをほぼ実行しています（テストが失敗しているはずですが、失敗しているはずです）。

@isiahmeadowsトピックにとどまるためのフレンドリーなリマインダー。 他のトピックについてチャットしたい場合は、ミスリルギッタールームを自由に使用してください。

@appsforartists

おそらく、React.Children.mapはフラグメントを展開する必要があります

Mithrilの安定版は内部で同様のことを行います（つまり、サブ配列をフラット化します）が、パフォーマンス上の理由（およびキー付きノードとキーなしノードが混在するvnodeリストに関するいくつかの歴史的な頭痛の種）のために、そのモデルから離れています。 考慮すべきことがあるかもしれません。

そして、HTMLコメントのような「疑似」ラッパー要素を使用することはオプションではありませんか？ それがテキストノードが「解決」した方法だと思いました...

数か月間、本番環境でhttps://github.com/mwiencek/react-packagesを使用しています。 このコメントラッパーアプローチを使用しているため、フラグメントを明確にネストできます。

@mwiencekカスタムreactパッケージなしであなたのアプローチを使用することは可能ですか？

@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関数が1つのルート要素/コンポーネントのみを返す限り、機能するはずです。

わかった：

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>

とても悲しいです。 2つの<tr>要素を一度にレンダリングすることはできないため、行スパンのあるテーブルにも同じことが言えます:(

上から：

「私も」と「+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では実際には意味がないため、新しいコアアルゴリズムを完成させ、それを使って適切なソリューションを実行したいということでした。 私はその状況を追っていませんが、それらの計画は変わっていないと思います。 それまでの間、パッケージがお役に立ててうれしいです。

新しいアルゴリズムは現在開発中であり、フラグメントをサポートしています。 しかし、私はそれが今後数ヶ月の生産準備が整うとは思っていません。 これを最初にReactDOMに追加し、後で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);
};

これについては、前回のチームミーティングで詳しく話しました。 コンセンサスは、この特定の実装を採用したくないということです。 ただし、この機能は長期的なコアリライトでサポートされます（現時点ではタイムラインはありません）。

また、書き直しに時間がかかりすぎたり、うまくいかなかったりした場合に、今年の後半に取り組む可能性のあることの1つとして再度検討します。 リストが作成される保証はありませんが、リストが表示された場合はすべて最新の状態に保ちます。

私たちが取り組んでいることをよりよく理解するには、ミーティングノートリポジトリをご覧ください。 これに関する最新のディスカッションは、 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">で囲まれた2つの要素があります。

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>

そして、単一の要素に包まれた2つの要素は不可能です。
お時間をいただきありがとうございます@Primajin

すべてを1レベルシフトするだけです。

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_の例を追加するのか、それともすでに確認されている同じ問題を繰り返すのかを検討するのが礼儀です。 これは既知の制限であり、このスレッドには、制限の詳細と理由に関する詳細な説明が含まれています。 ダンはまた、最終的にはこれをサポートするために修正するつもりであると述べています。 認められた問題の別の例を指摘して、何を達成しようとしていますか？

申し訳ありませんが、その間に誰かが別の解決策を持っているかどうかを知りたかっただけです。
必要に応じて私の投稿を削除できます。

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>

'page'クラスを持たない他のdivで第1レベルの子要素（navbar、searchbar）をラップすることはできません

行のリストを返すコンポーネントがあります

参考までに、私たちが取り組んでいるリライト（＃6170）は、すでにフラグメントをサポートしています。 進捗状況は、＃7925およびhttp://isfiberreadyyet.comで追跡できます。

<table>要素が特定の要素をレンダリングできないという単なる事実は、WebAPIと互換性を持たせるためにこの機能を追加するのに十分な理由です。

編集：ああ、断片！ それらを楽しみにしています。

@trusktr

このスレッドの最初の投稿に記載されているように：

メンテナからのメモ：

私たちはこれが問題であることを知っており、どのような問題を解決できるかを正確に知っています。 これも必要ですが、現在のアーキテクチャでは難しい問題です。 この機能への要望を表す追加のコメントは役に立ちません。

😉

おやおや、やめなきゃ。

私はこれに賛成しましたが、有効なユースケースを共有したいと思いました。 CSSリキッドレイアウト（左、中央、右）が必要な3つのボタンがあるとします。 左ボタンは常に表示されますが、他の2つは条件付きで表示されます。 React（具体的にはReact Native）では、フレックスボックスを使用して次のようにレンダリングしています。

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

中央のボタンと右のボタンは、単一のビューにラップされているため、正しく配置されません。

はい、中央のボタンと右のボタンをそれぞれのメソッドに分割することはできますが、多くの動作を共有するため、多くの冗長なコードが導入されます。

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

上で述べたように、私たちはこの機能のユースケースをすでに認識しており、それをサポートするために懸命に取り組んでいます。 （フレックスボックスの問題を指摘する人はすでに半ダース上にいます。）これ以上の議論は生産的ではないように思われるので、私はこれをロックしています。 新しい実装に関するニュースがありましたら更新します。

これを閉じることができると思います。

今すぐ試すことができるReact16Beta 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.が得られます。

では、この機能は、実際のリストを無関係な要素で囲まないようにする方法でしたか？

では、この機能は、実際のリストを無関係な要素で囲まないようにする方法でしたか？

はい、1つのレンダリングから複数の要素を提供する方法です。 （詳細については、最初の問題の投稿を参照してください。）

すべての配列アイテムが文字列であることがわかっている場合は、それらを結合して1つの文字列を返します。 そうでない場合は、この警告を食べるか、要素でそれらをラップする方法を考えて、JSXの別の要素内に文字列の配列を含めた場合と同じように、DOMの調整を改善するためにキーを設定できます。

@diligiantが['foo', 'bar']を返すことは、この問題とは関係ありません。 return <div>{['foo','bar']}</div>を実行することはできませんし、実行することもできません。配列内の各子には、 <div>などの内部jsxタグ内にあるか、返されるかどうかにかかわらず、「キー」プロップが必要です。 今できることは次のとおりです。

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

それはreactの大きな制限を取り除きます。

ところで、 ['foo', 'bar']を返すと、エラーではなく警告が表示されます。その警告を削除するには、これらの文字列を簡単に結合できます。文字列ではなくjsxタグの場合は、キープロップを追加できます。 したがって、配列を返すことについての制限はありません。

@JesperTreetopありがとうございます。
@sassanh 、あなたの例から、私は「恥ずかしがり屋」で、周囲の（意味的に）役に立たない<div>を避けるために「ただ」キーを使用することができなかったようです。 先に進む必要があり、実際のパフォーマンスの低下はないということですか？ それは確かに本当の改善になるでしょう！

@diligiantパフォーマンスが低下することはないと思いますが、周囲の文字列でない限り、周囲の役に立たないdivは必要ありません。周囲の文字列の場合は、配列をまったく避けて文字列を結合できます。 文字列でない場合は、コンポーネントにキーを追加できます。 たとえば、2つのコンポーネントFooとBarがある場合、 [<Foo key='foo'/>, <Bar key='bar'/>]を返すことができ、コンポーネント（いつものように）も配列も（ありがとう）を囲む必要はありません。この新しいリリースでは、16）の前にアレイを囲む必要がありました。

@sassanhかっこいい。 もちろん、私のユースケースは複数のコンポーネントでした。 幸せ！！ ;）

実際、すべてのアイテムが文字列である場合にキーが欠落していることを警告するのは奇妙に思えます。 私たちがそうすることを期待していません。 文字列がdiv内にある場合、この既存の動作は15にありますか？ そうでない場合は、トップレベルの文字列に対して16で修正する必要があります（キーを与えることができないため）。

@gaearon申し訳ありませんが、私の例は誤解を招くものでした。私はコンポーネントを意味していました。

チェックしたところ、 -beta.5の下で、Reactは複数の文字列を含む配列をレンダリングするときに警告を発行しません。

それでも、周囲のコンポーネントを回避するためだけに配列をレンダリングする場合、 keyの要件に戸惑います。 私は理解していますが、それはおそらくSOに関する多くの質問を提起するでしょう（私は提供するより良いものは何もありませんが…）

そして最後に、ありがとうございました。

この警告は、コンポーネントの配列の他のすべての使用法とまったく同じです。これは、調整機能の「余分な作業」とまったく同じであり、 keyを設定することでまったく同じ潜在的な最適化になるためです。 私にとって驚きは、これに応じてコンポーネントの配列が異なる方法で処理される場合であり、それによってスタックオーバーフローの質問もいくつか発生することになると思います。 言うまでもなく、そもそもそれを追跡するためだけにいくらかのオーバーヘッドが必要になると思います。

..そして、ほとんどの場合、関数から配列を返すので、 keyの警告を表示したいと思います。 警告を望まないのは少数派のようであり、Reactが警告しないことが適切かどうかを知る方法はありません。

キーがないと、パフォーマンスの問題だけでなく、正確性の問題が発生する可能性があるため、警告が必要です。 これは、キーが必要な理由を尋ねる他の多くの問題で説明されているので、キーを検索してそれらの議論を読むことをお勧めします。 私は、ドキュメントがこれについてより明確になる可能性があることに同意します。これは、次にドキュメント変更スプリントを行うときに検討する可能性が高いものです。

レンダリングから直接返される配列とdiv内の配列の間に概念的な違いはありません。 したがって、一方のケースでは重要な警告が発生し、もう一方のケースでは発生しない理由はありません。 キーが欠落している場合、両方が同じ問題の影響を受けるため、これらは同じように機能する必要があります。

とはいえ、静的コンテンツのキーを指定するのは面倒だと理解しています。 子が静的に認識されている（したがって、並べ替えられない）JSX構造を作成するときにキーを指定しないのと同じように、配列を使用してこれを行う方法があると便利です。

将来的には、次のような構文でJSXのフラグメントの明示的なサポートを追加することでこれを解決する可能性があります。

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

配列を生成することはできますが、子に数値インデックスを暗黙的に割り当てます。この場合、子は並べ替えることができないことがわかっているためです。 JSXの子式によって与えられるこの保証は、divに複数の子がある可能性がある通常のJSXコードでキーを指定せずに回避できるものです。

しかし、この構文はまだありません。 したがって、今のところ、これは既知の制限です。

@ JesperTreetop ＆ @ zwily 、 @ gaearonは、私よりもずっとうまく説明してくれました;）

一度知ってしまえば、それは大したことではありませんが、私たち全員がReactを繁栄させたいので、私はただ言っていました…

@gaearon <>構文の提案について、この問題についてさらに議論する代わりに見ることができる別の問題はありますか？ 探し回ったのですが見つかりませんでした。

@smrq +1で質問—私はこれらの厄介な制限（1対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は技術的にはキーがなくても機能する可能性がありますが、リストから1つのアイテムを削除したときに、コンポーネントの半分を更新する必要があることに気付くのはまったく予想外のことです。 キーを使用すると、1つのアイテムのみがアンマウントされます。

@ goto-bus-stop vidomはキーを使用できますが、キーは必須ではなく、キーがないと、多くの更新を伴う非常に大きなケースのみが実際のパフォーマンスの問題を引き起こす可能性があります。

したがって、この部分は、個々のケースでのパフォーマンスの微調整に使用できるオプション（たとえば、 shouldComponentUpdateなど）であると考えています。

キーなしで苦労しているvidomの@vegedの例。

要素を並べ替える必要があるかどうかわからないため、ルートコンポーネントの各レンダリングでインスタンスを破棄します。

仮想ドーム空間に精通している人として[1]。 私はそれを言うことができます：

1. 同様の兄弟の間で予測可能なdomと状態の更新にはキーが必要です。
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