Karena ketika Anda tidak meletakkan bungkusnya, itu akan menjadi ini:

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

Yang tidak masuk akal secara sintaksis. Halaman kompiler jsx mungkin membantu jika Anda memerlukan pemetaan visual.

Karena itu, dimungkinkan untuk mengubah ini menjadi [div, div] sebagai gantinya. Ini sulit, agak kontroversial dan tidak akan diterapkan dalam waktu dekat.

(Saya tidak berpikir itu sangat kontroversial tetapi itu menambah kompleksitas kode dan belum selesai.)

IIRC @syranide memiliki beberapa komentar tentang ini

@chenglou Hehe.

Saya mengobrol singkat tentang hal itu dengan chenglou beberapa waktu yang lalu, saya tidak benar-benar condong ke satu arah atau yang lain saat ini. Saya melihat banyak bahaya tersembunyi dalam mengizinkan komponen komposit untuk mengembalikan banyak komponen dan itu mematahkan banyak asumsi intuitif, tetapi saya tidak tahu ada (saat ini) kasus penggunaan praktik yang baik yang jelas akan mendapat manfaat dari ini.

Kesederhanaan mengembalikan paling banyak satu komponen berarti sangat mudah untuk mempertimbangkan apa yang Anda lihat, jika tidak, <table><TableHeader /></table> sebenarnya dapat merender sejumlah baris, Anda tidak memiliki cara untuk mengetahui selain memeriksa TableHeader dan komponen komposit apa pun yang dikembalikannya.

Saya merasa dapat mengembalikan beberapa komponen hanya memindahkan tanggung jawab membungkus komponen seperlunya dari "komponen komposit" ke "membuat komponen komposit" apa pun. Komponen "yang membuat komponen komposit" jarang memiliki atau harus memiliki pengetahuan tentang apakah akan membungkus komponen komposit atau tidak, sedangkan anak-anak lebih cenderung memiliki pengetahuan tentang orang tuanya.

Tapi mungkin ini hanya masalah tanggung jawab pengembang. Mungkin ada kasus penggunaan yang baik untuk keduanya dan kita harus melihat melewati penyalahgunaan yang tak terhindarkan.

@sebmarkbage Mungkin ada beberapa komentar juga :)

Kami mungkin tidak akan pernah mengizinkan sintaks itu secara implisit. Anda akan membutuhkan pembungkus seperti

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

ATAU

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

Namun, bahkan ini tidak berhasil. Seringkali, itu mungkin yang terbaik. Ini dapat membingungkan untuk mengkonsumsi komponen ketika seorang anak mungkin berkembang menjadi beberapa elemen.

Tapi, sungguh, satu-satunya alasan kami tidak mendukung ini sekarang adalah karena sulit untuk diterapkan. Mudah-mudahan, kami akan dapat mendukungnya suatu saat nanti, tetapi mungkin tidak dalam jangka pendek. Maaf. :/

dapatkah ini tidak memengaruhi hal-hal seperti jquery atau pustaka lain yang menargetkan elemen tertentu, jadi jika Anda melakukan sesuatu seperti $('#id-name').children() , berikut ini:

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

<div> dan <div class="class-name"> akan dipilih dalam kasus ini. (Jika saya memahami ini dengan benar)

Ini juga memengaruhi pemilih css dengan cara yang sama seperti yang diposting @AdamKyle sebelumnya.

Adakah pembaruan tentang masalah ini?

Menghabiskan beberapa menit untuk memahami mengapa komponen saya tidak berfungsi. Saya merasa harus ada pemberitahuan di suatu tempat, mungkin saya melewatkannya? Mungkin jelas salah mencoba :

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 Anda seharusnya mendapatkan kesalahan kompilasi JSX dengan kesalahan "Elemen XJS yang berdekatan harus dibungkus dengan tag penutup"; apakah Anda tidak melihat kesalahannya atau tidak jelas dalam penjelasannya?

Terima kasih atas jawabannya @spicyj. Yah, maksud saya pemberitahuan di dokumentasi React. Ya, konsol memang menunjukkan kesalahan, tetapi kebutuhan untuk membungkus tidak masuk akal bagi saya pada awalnya. Itu sebabnya saya mencari dan sampai di sini.

Saya juga mengalami rasa sakit ini... sangat menyakitkan bagi desainer saya, sebenarnya. Akan lebih baik jika sebuah komponen dapat menampilkan sebuah simpul (oleh karena itu daftar simpul atau fragmen) alih-alih sebuah elemen.

Hanya mengatakan.. Saya tidak menganjurkan mengembalikan banyak anak dari komponen _but_ Saya ingin melakukannya dalam metode render* yang saya ekstrak dari 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>
        }
      </>
    );
  }

Tapi saya mungkin harus diam dan menggunakan key s.

@gaearon Anda sudah bisa melakukannya, Anda hanya perlu mengembalikan array untuk saat ini (yang agak merepotkan ya) ... buuuuut, Anda bisa mengatasinya, saya telah meretas komponen <Frag> saya sendiri yang diterjemahkan ke array (kelebihan React.render ) ... Anda juga bisa melakukan return <NoopComp>...</NoopComp>.props.children Saya berasumsi, jika Anda ingin menghindari peretasan.

EDIT: Buruk saya, saya kelebihan React.createElement bukan React.render .

Masalah dengan array adalah mereka membuat desainer kami tersandung. Perlu koma, kunci eksplisit.

@gaearon Ya, Anda dapat menghindari koma menggunakan salah satu dari dua solusi saya untuk saat ini (jika Anda merasa dapat diterima) ...

Jika saya menggunakan sintaks array, saya perlu menentukan key pada setiap elemen. Bukannya sulit untuk dilakukan, tetapi terasa canggung karena saya tahu mereka tidak pernah berubah.

@gaearon Ah ya, saya memilih untuk mengabaikan peringatan itu secara mental untuk saat ini :), jika Anda benar-benar ingin menghindarinya, Anda dapat melakukan <MyComp children={this.renderWhatever()} /> untuk menghindarinya ( EDIT: meskipun Anda jelas tidak dapat menggunakannya jika Anda memiliki anak yang berdekatan, Anda dapat menggunakan beberapa pembantu perataan ... tapi ya).

Kasus lain yang saya temui dengan kit UI. Saat Anda menempatkan anak-anak di dalam wadah tetap yang dapat digulir seperti:

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

Anak-anak sekarang harus diteruskan sebagai array, tetapi jika kelas komposit dilewatkan, itu juga harus menerapkan gaya tersebut untuk menghindari kerusakan. Hanya menambahkan lapisan kompleksitas. Tapi saya benar-benar bisa mengerti betapa rumitnya untuk membuat perubahan. Hanya melemparkan topi saya untuk dukungan.

Saya memiliki kasus penggunaan lain yang saya jelaskan secara rinci di sini #3415. Tetapi saya dapat mengatasinya untuk saat ini dan memahami bahwa itu sulit untuk diterapkan dan jarang terjadi.

Saya tidak tahu apa-apa tentang reaksi internal (belum), tetapi saya hanya akan memberikan ide bagaimana Anda dapat menandai elemen/fragmen induk virtual di DOM: komentar. Misalnya

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

akan membuat

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

Ini berarti c dan d akan diperlakukan sebagai anak dari sth. (termasuk reaksi bersarang agar tidak bertentangan dengan b dan e). Saya telah melihat kerangka lain "menyalahgunakan" komentar untuk pekerjaan semantik semacam ini.

@Prinzhorn Saya pikir Anda mungkin membingungkan keluaran DOM dengan JSX Bereaksi.

Jika ini berguna: Saran @Prinzhorn untuk menggunakan komentar HTML untuk memetakan "komponen fragmen" ke DOM adalah pendekatan yang sama yang digunakan Knockout. Knockout menyebut ini "elemen virtual".

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

(dari dokumen knockout )

Juga, kasus penggunaan lain untuk ini - elemen pembungkus tambahan dapat menjadi masalah saat menggunakan flexbox.

@aldendaniels sangat setuju, saya sudah mengalami masalah flexbox.

Saya mengalami ini dengan flexbox dengan dropdown dependen. Di mana A akan merender dan mengelola dropdown pertama, diikuti oleh B atau C atau D tergantung pada nilai dropdown A, yang masing-masing akan merender jumlah dropdown yang sesuai, mis.

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

A, B, C, dan D tidak memiliki kewarganegaraan jadi saya mengubahnya dari class B {render(){ this.props }} menjadi function B(props){ return [...]; } .

Dalam hal ini, tidak masalah bagi orang tua bahwa banyak anak dirender, itu hanya untuk menangani CSS saya. Ada beberapa hal yang akan saya lakukan secara berbeda jika ini tidak perlu digunakan kembali (komponen lain membutuhkan B, C, dan D).

Sebagai alternatif, mungkin cara untuk mengungkapnya dari orang tua? Saya tidak punya ide spesifik tentang bagaimana tampilannya.

Saya menemukan skenario hari ini yang menurut saya merupakan kasus penggunaan yang baik untuk fitur ini: Sebuah komponen yang merender beberapa elemen <script> , yang dapat dirender menjadi elemen <head> halaman. Elemen pembungkus apa pun di sana akan menjadi buruk.

Skenario saya ingin memiliki komponen yang bertanggung jawab untuk merender tag <script> baik untuk kode runtime yang diperlukan pada halaman maupun tag <script> lain yang membawa string lokal untuk digunakan oleh kode waktu proses. Sebagai contoh:

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

Dalam hal ini, saya ingin kode ditulis sebagai:

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

Saya juga mengalami beberapa masalah flexbox. Tidak ada yang tidak dapat diselesaikan dalam CSS, tetapi salah satu "keindahan" flexbox adalah Anda membutuhkan lebih sedikit elemen "pembungkus" di mana-mana untuk membuat tata letak Anda berfungsi, tetapi Anda masih akan berakhir dengan elemen pembungkus di mana-mana saat menggunakan Bereaksi sejak Anda selalu membungkus apa pun yang Anda kembalikan dalam div/div atau yang serupa, kecuali jika masuk akal untuk memiliki wadah.

Untuk semua kasus penggunaan yang disajikan di sini, saya cukup yakin Anda dapat mengganti <BunchOfComponents /> dengan {getBunchOfComponents()} dan output visualnya akan sama, tanpa memperkenalkan masalah praktis dan teknis yang terkait dengan memiliki komponen dengan fragmen sebagai root.

@syranide tetapi setiap kali salah satu komponen berubah, semua saudaranya perlu menghitung ulang...

Juga jika Anda menggunakan skrip kopi biasa, mudah untuk mengembalikan array, jadi harap pisahkan fungsionalitas dari representasi jsx.
TKI jika mudah untuk menangani array elemen yang dikembalikan, jangan menunggu jsx untuk mengejar.

@syranide tetapi setiap kali salah satu komponen berubah, semua saudaranya perlu menghitung ulang...

@wmertens Ya, tetapi sering kali Anda tetap memilikinya karena induknya perlu merender karena alasan lain, atau hanya karena Anda tetap menerima data melalui alat peraga. Tapi ya, itulah perbedaannya, tetapi itu tidak berarti pendekatan ini benar, ini adalah pengoptimalan dan ada banyak cara untuk mencapainya.

Juga jika Anda menggunakan skrip kopi biasa, mudah untuk mengembalikan array, jadi harap pisahkan fungsionalitas dari representasi jsx.

Itu tidak relevan dan ini bukan masalah dengan BEJ. Masalah besar adalah Anda kehilangan asumsi teknis, praktis, dan intuitif one component = one element/node . Saya tidak dapat berbicara mewakili para pengembang tetapi saya tidak akan menyerah begitu saja, itu adalah asumsi yang sangat berguna untuk dimiliki. Saya yakin ada pengoptimalan yang sama baiknya atau lebih baik yang dapat dirancang jika pengoptimalan adalah satu-satunya alasan orang menginginkan ini.

@syranide masalah terbesar adalah Anda tidak selalu dapat menggunakan pembungkus
elemen dalam html, seperti di tabel, daftar, flexbox, head... Bekerja di sekitar
yang mengarah ke kode jelek.

Saya akan sangat senang dengan elemen pembungkus virtual yang hanya merender
komentar, seperti yang disarankan sebelumnya.

Pada Jumat, 29 Mei 2015, 15:56 Andreas [email protected]
menulis:

@syranide https://github.com/syranide tetapi setiap kali salah satu dari
komponen berubah semua saudaranya perlu menghitung ulang ...

@wmertens https://github.com/wmertens Ya, tapi berkali-kali Anda akan melakukannya
tetap miliki itu karena orang tua perlu merender untuk yang lain
alasan, atau hanya karena Anda menerima data melalui alat peraga. Tetapi
ya itu bedanya, tapi bukan berarti pendekatan ini benar,
ini adalah pengoptimalan dan ada banyak cara untuk mencapainya.

Juga jika Anda menggunakan skrip kopi biasa, mudah untuk mengembalikan array, jadi tolong
memisahkan fungsionalitas dari representasi jsx.

Itu tidak relevan dan ini bukan masalah dengan BEJ. Masalah besar adalah itu
Anda kehilangan asumsi teknis, praktis, dan intuitif tentang _one
komponen = satu elemen/simpul_. Saya tidak dapat berbicara untuk para pengembang tetapi saya tidak mau
menyerah bahwa rela, itu asumsi yang sangat berguna untuk memiliki. saya yakin
ada pengoptimalan yang sama baiknya atau lebih baik yang dapat dirancang jika
optimasi adalah satu-satunya alasan orang menginginkan ini.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/facebook/react/issues/2127#issuecomment -106810565.

fwiw, Ini relatif mudah untuk meretas komponen "fragmen" ke dalam React yang diperlakukan sebagai larik turunannya oleh React. Ini akan menghasilkan kunci secara otomatis, tetapi karena itu terjadi setelah validasi awal komponen, itu tidak akan menimbulkan kesalahan "tidak ada kunci yang disediakan" yang biasa.

Dengan demikian, peretasan itu hanya menyelesaikan apa yang dibicarakan @gaearon di atas - tidak harus berurusan dengan sintaksis/pengaturan kunci arbitrer array yang jelek di BEJ Anda - dan bukan masalah mengembalikan banyak simpul di akar metode render komponen.

Saya memiliki masalah dengan gagasan bahwa suatu komponen perlu mengembalikan satu "elemen/simpul". Bagi saya, tampaknya sangat masuk akal untuk struktur BEJ dari:

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

untuk berakhir sebagai DOM:

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

Saya tidak berpikir ini adalah pelanggaran prinsip yang paling tidak mengejutkan karena komponen sudah melakukan semua jenis "hal yang mengejutkan" dengan DOM menggunakan kait siklus hidup (lihat saja pola lubang cacing yang umum). Secara umum diterima bahwa sebuah komponen tidak selalu menghasilkan satu elemen yang dibuat, dan itu tidak masalah, karena beberapa kompromi harus dilakukan untuk bekerja dengan DOM.

Ini juga bukan tentang "pengoptimalan", atau bahkan tentang tidak menyukai sintaksis array. Seperti yang telah disebutkan banyak pengguna, _elemen pembungkus merusak gaya dan tata letak dengan cara yang serius_. Tabel adalah yang paling jelas, tetapi Flexbox juga merupakan masalah utama. Saya sudah memiliki CSS yang baru saja menerapkan kembali aturan fleksibel ke elemen pembungkus yang hanya ada karena Bereaksi, dan itu sangat jelek.

Untuk semua kasus penggunaan yang disajikan di sini, saya cukup yakin Anda dapat mengganti dengan {getBunchOfComponents()} dan output visualnya akan sama, tanpa memperkenalkan masalah praktis dan teknis terkait memiliki komponen dengan fragmen sebagai root.

Ini mengharuskan pengembang untuk berkompromi dalam membuat komponen yang terisolasi dan dapat digunakan kembali - semoga membantu jika mereka memutuskan ingin menggunakan kembali kumpulan komponen mereka di tempat lain - karena masalah implementasi yang mendasari di React. Saya tidak berpikir itu harus diterima.

@thomasboyt

EDIT: Kesalahan saya, saya menggabungkan beberapa argumen Anda dengan diskusi tabel di atas, saya sebagian besar setuju dengan apa yang Anda katakan, saya pikir. Tetapi masih ada masalah dengan komponen yang buram, jadi apa yang dimaksudkan sebagai pembungkus transparan yang berguna menjadi buram bagi induknya. Bayangkan <Wrapper1><Wrapper2>...</Wrapper2></Wrapper1> , Wrapper1 tidak dapat melihat anak-anak dari Wrapper2 . Jadi mungkin wrapMyElements(...) hanya merupakan solusi yang lebih baik secara keseluruhan (termasuk fungsi pendukung lain yang diperlukan).

Saya memiliki masalah dengan gagasan bahwa suatu komponen perlu mengembalikan satu "elemen/simpul". Bagi saya, tampaknya sangat masuk akal untuk struktur BEJ dari:

Komponen lebih dari sekadar pembungkus bodoh, mereka memiliki tujuan. IMHO tampaknya mengembalikan beberapa elemen memblokir beberapa harapan yang sangat berguna. Misalnya, React.render akan mendapatkan pendamping di masa mendatang yang merender elemen dan mengembalikan node, ini sekarang harus menghasilkan array node sebagai gantinya.

Tapi saya pikir masalah yang sangat penting adalah keterbacaan yang IMHO adalah nilai jual terbesar dari React, semuanya eksplisit.

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

Melihat itu tidak masuk akal, dari mana sel ke-3 berasal? Mungkin itu sebenarnya salah dan itu merender 2 atau 4 sel, siapa tahu, mungkin itu sebenarnya dinamis dan tergantung pada penyangga atau keadaan eksternal? Ada banyak variasi masalah ini yang hanya mendapatkan harier ketika Anda mempertimbangkan frontend non-HTMLDOM lain yang mungkin memiliki harapan eksplisit. Hal lain yang perlu dipertimbangkan adalah bahwa elemen buram, jadi jika Anda mengganti <tr /> dengan <MyMagicalTr /> maka tidak dapat berinteraksi dengan sel individu atau bahkan menyimpulkan berapa banyak, jadi meskipun <MyMagicalTr /> mungkin hanya menerima <MyMagicalTd /> 's tidak ada jaminan itu benar-benar dapat berinteraksi dengan mereka.

Ini mengharuskan pengembang untuk berkompromi dalam membuat komponen yang terisolasi dan dapat digunakan kembali - semoga membantu jika mereka memutuskan ingin menggunakan kembali kumpulan komponen mereka di tempat lain - karena masalah implementasi yang mendasari di React. Saya tidak berpikir itu harus diterima.

"Ini membutuhkan pengembang untuk berkompromi untuk membuat terisolasi...", tetapi itulah masalahnya jika Anda bertanya kepada saya, jika suatu komponen dapat mengembalikan banyak elemen, itu tidak lagi terisolasi, itu diganti, komponen bocor ke induknya.

Palu, paku. Menjadi masalah implementasi yang mendasarinya adalah masalah terpisah dari apakah ini benar-benar harus dilakukan atau tidak. Itu bukan keputusan saya, tetapi saya tidak melihat bagaimana satu kasus penggunaan yang langka adalah argumen yang meyakinkan tanpa mempertimbangkan pertukaran yang menyertainya atau apa solusi alternatif lain yang ada.

IMHO Saya tidak melihat masalah dengan {getBunchOfComponents()} , itu eksplisit, ini memungkinkan kami untuk menjaga harapan kami yang bermanfaat. Jika kinerja menjadi masalah maka React.createSmartFragment() (atau w/e) untuk menyelamatkan, jenis array/seperti objek transparan tetapi yang dapat diperbarui secara independen dari induknya.

Sekali lagi, pengembang React adalah otoritas (bukan saya), tetapi saya tidak melihat argumen yang meyakinkan di sini mengingat berbagai efek samping. Saya bahkan tidak yakin saya setuju dengan solusi yang disajikan sebagai pola yang baik sama sekali, bahkan jika itu didukung.

EDIT: Untuk memperjelas, mungkin komponen mungkin dapat mengembalikan banyak elemen di masa mendatang karena ada kasus penggunaan lain yang jelas bermanfaat, terutama dalam konteks melewati anak-anak (seperti yang Anda tunjukkan @thomasboyt), keterbacaan dipertahankan.

Saya pikir saya perlu kopi lagi sebelum saya dapat menanggapi sisi filosofis dari percakapan ini (terima kasih untuk poin yang sangat bagus, @syranide), tetapi di sisi implementasi, saya mulai melihat-lihat tadi malam untuk melihat bagaimana caranya. perubahan yang layak dari ruang lingkup ini, mengarah ke lonjakan ini: https://github.com/facebook/react/compare/master...thomasboyt :fragment

Dan memuntahkan sedikit demo di sini: http://www.thomasboyt.com/react-fragment-demo/

Beberapa pengamatan di sisi implementasi:

• Tidak mengherankan, sangat sulit untuk memperbaiki sistem yang mengharapkan "1 komponen = 1 node" untuk mendukung lebih banyak node ;)
• Awalnya saya berpikir untuk mencoba melacak fragmen di sisi operasi DOM, sehingga instruksi mutasi yang dihasilkan ReactMultiChild dapat tetap sama dan memperlakukan fragmen seperti simpul lainnya. Saya tidak bisa memikirkan cara yang baik untuk menambahkan status tentang jumlah node/node mana yang merupakan fragmen ke dalam pelacakan status DOM. Sesuatu seperti komentar anggar yang dicatat @Prinzhorn dapat berfungsi, tetapi saya waspada terhadap apa pun yang memerlukan pencarian DOM, mengingat biaya relatifnya.
• Dengan membuang ide itu, saya menambahkan bidang _nodeCount ke semua anak dari komponen ReactMultiChild , sehingga dapat melacak jumlah simpul akar yang sebenarnya ada dalam sebuah fragmen.

Masalahnya adalah, sementara ini cukup mudah dilakukan pada render awal dengan hanya menghitung anak-anak dari sebuah fragmen, memperbarui jumlah simpul fragmen pada mutasi berikutnya tampaknya lebih sulit. Ini masih belum selesai di cabang saya (lihat https://github.com/thomasboyt/react/issues/2).

• Banyak operasi DOM mengandalkan pengaksesan simpul induk dari suatu elemen, yang dicari oleh ID simpul internal, untuk menambahkan/memindahkan/menghapus elemen (lihat https://github.com/thomasboyt/react/issues/3). Karena siklus updateComponent ReactMultiChild bertanggung jawab untuk meneruskan ID ini, ID ini dapat diubah untuk melakukan pencarian induk terdekat yang memiliki simpul DOM, tetapi kedengarannya mahal. Atau, dimungkinkan untuk memiliki registri internal kunci fragmen ke kunci "node nyata" mereka.

Saya masih tidak yakin bahwa membutuhkan fragmen untuk mempertahankan jumlah node root mereka adalah cara terbaik untuk melakukan ini (meskipun setidaknya itu membawa saya ke demo itu), dan ini semua diretas bersama cukup cepat dan cukup larut malam , jadi jika ada orang lain yang memiliki saran untuk implementasi, jangan ragu untuk bergabung :>

@thomasboyt IIRC hambatan implementasi utama berasal dari React yang mereferensikan node anak dengan mountIndex , ini tidak berfungsi ketika satu "node" tiba-tiba dapat menjadi sejumlah node dan ini dapat terjadi tanpa meminta induk dan mungkin juga terjadi beberapa komponen dalam (pembungkus). Jika saya tidak salah, cukup sepele untuk membuat React mendukung banyak elemen root selama jumlahnya tidak pernah berubah.

Jadi saya tidak berpikir akan sangat sulit untuk membuatnya bekerja di Bereaksi, tetapi solusi yang benar-benar tepat lebih bermasalah dan mungkin harus melibatkan menjatuhkan mountIndex .

@syranide Benar; solusi yang saya kerjakan sebenarnya memperkenalkan nodeIndex baru yang seharusnya menjadi "offset nyata" dari sebuah simpul (yang mengingatkan saya bahwa saya harus kembali dan menghapus mountIndex , karena Saya pikir itu sekarang tidak digunakan di cabang saya).

Namun, seperti yang Anda perhatikan, ini bermasalah jika jumlah elemen akar berubah, karena nodeIndex dari suatu komponen perlu diperbarui setiap kali jumlah simpul komponen saudara sebelumnya berubah. Masih perlu mencari solusi untuk itu.

Saya juga mengalami masalah flexbox. @syranide, bisakah Anda menjelaskan lebih lanjut tentang solusi yang diusulkan "getBunchOfComponents" Anda? Menjadi baru di React, sulit untuk sepenuhnya mendapatkan ide di mana mendefinisikan fungsi ini / bagaimana menerapkannya.

@landabaso

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

Hai,

Saya belum membaca seluruh utasnya, tetapi inilah contoh penggunaan pengoptimalan render yang mungkin memerlukan fitur ini:

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

Jika fitur ini dirilis, ReactCSSTransitionGroup tidak akan membutuhkan simpul pembungkus lagi kan?

@slorber Ya, itu mungkin benar.

Jalankan kebutuhan akan fitur ini setiap hari.

Jika Anda memiliki banyak komponen kecil (yaitu desain yang sangat modular), Anda akhirnya harus membungkus segala macam hal dalam div yang tidak seharusnya. Saya mungkin bingung, tapi saya pikir ini berhubungan dengan masalah ini.

Untuk <div> Anda dapat membungkusnya dalam <div> , tetapi untuk baris tabel elemen <tr> , itu tidak mudah. Anda dapat membungkus <tr> dalam <tbody> , tetapi mungkin tidak diinginkan untuk memiliki banyak lapisan <tbody> membungkus beberapa lapisan <tr> .

Skenario yang saya panggil mencoba memiliki komponen yang menyediakan elemen <link> dan <script> tanpa harus menjadi perender <head> sepenuhnya.

Saya menambahkan catatan ke bagian atas masalah ini. Mohon dibaca sebelum berkomentar. https://github.com/facebook/react/issues/2127#issue -4166809

Bump...Saya memiliki kebutuhan yang besar untuk itu di sisi server. Sangat rumit untuk merender halaman web penuh (tidak termasuk doctype) tanpa kemampuan untuk merender fragmen, karena bagian <head> . Saat ini saya sedang mengerjakannya melalui mixin dan sedikit logika di render akhir, tetapi akan jauh lebih sederhana jika ada dukungan untuk merender beberapa komponen.

@impinball Anda dapat mencoba menulis sesuatu yang mirip dengan react-document-title berdasarkan reaksi-efek samping untuk menyelesaikan masalah ini. Saya dapat melakukan hal yang sama untuk tag meta, header, judul, dan terkadang pengalihan

Saya juga mengalami masalah ini, apakah ada solusi untuk saat ini? Saya tidak dapat membuat {getBunchOfComponents()} berfungsi seperti yang disarankan.

Tidak lain adalah yang sudah disebutkan.

@jonchay Anda bisa membuat komponen yang hanya merender anak-anaknya.

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

dan kemudian menggunakannya:

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

@whatknight Itu tidak akan berfungsi kecuali jika return renderABunchOfComponents(); sudah berfungsi.

  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>
    )
  }

Setidaknya harus ada cara untuk mengembalikan beberapa fragmen saat melakukan interpolasi dan "perakitan". Contoh di atas mengeluh tentang img dan h1 menjadi adiacent tetapi mereka akan tetap berada di dalam pembungkus utama. Itu satu elemen pembungkus yang saya harap bisa saya singkirkan.

@kilianc dalam hal ini, Anda cukup menulis

      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>,
      ]

cara Anda menggunakannya, tidak akan ada bedanya jika masalah ini diselesaikan.

Saya memerlukan fitur ini karena alasan yang sudah disebutkan, jadi coba terapkan wadah <frag></frag> di https://github.com/mwiencek/react/tree/frag-component

Implementasinya tidak terlalu bagus, tetapi jika berhasil untuk orang, saya dapat mengirimkan PR dan membiarkan pengembang React mengobrak-abriknya.

@mwiencek Sepertinya implementasi Anda tidak berfungsi jika jumlah anak dalam fragmen berubah dalam pembaruan (_nestedChildCount hanya disetel di mountComponent)? Ada sedikit trik untuk membuat semuanya bekerja dengan baik. Sepertinya Anda punya awal yang baik sekalipun. Saya sebenarnya telah memikirkan hal ini lagi baru-baru ini dan saya mungkin telah menemukan cara yang kuat untuk mewujudkannya. Saya akan melaporkan kembali jika saya menemukan kesuksesan.

@spicyj yup, Anda benar, saya perlu memeriksanya...

Sangat bersemangat bahwa kita mungkin segera melihat implementasi yang tepat. :) Jangan ragu untuk menyalin tes dari cabang itu jika ada gunanya.

@spicyj Bukankah cara ke depan untuk menggunakan createFragment dan membuat JSX berubah menjadi itu? Atau apakah kita benar-benar ingin fragmen menjadi elemen?

Untuk membangun dan memperluas komentar terakhir @syranide , sepertinya tidak perlu "Fragment API" tambahan jika render mengizinkan array sebagai nilai balik. JSX dapat mengubah beberapa elemen root menjadi array, yang juga akan berfungsi untuk mengembalikan nilai fungsi lainnya. Jadi, alih-alih memperkenalkan permukaan API tambahan, yang memerlukan dokumentasi dan pembelajaran, salah satu batasan React bisa dihilangkan.

Ini setidaknya akan mempengaruhi babel-plugin-transform-react-jsx (implementasi) dan juga babel-plugin-syntax-jsx (menghapus kesalahan parse untuk elemen root yang berdekatan). Meskipun mengubah yang pertama tampaknya cukup aman, saya tidak tahu ruang lingkup/penggunaan yang terakhir dan dampak perubahan yang diusulkan terhadap proyek lain.

Itu masih belum mencakup kasus penggunaan kondisional dengan banyak elemen. Saya tidak menganggap "Gunakan array dan tambahkan secara manual key={...} sewenang-wenang ke setiap elemen" sebagai solusi jangka panjang yang tepat.

setuju dengan @dantman

yup, poin yang bagus. Pembuatan kunci otomatis harus dibangun melalui transformasi. Menggunakan indeks array sebagai kunci sudah cukup, karena item tidak berubah.

Adapun kondisional, ini juga dapat dimasukkan ke dalam transformasi atau sebagai alternatif Anda dapat menggunakan JSX-Control-Statements . Diimplementasikan di sana dengan cara ini, maka idenya.

Untuk menangani pembaruan dengan benar, saya pikir solusi yang dipikirkan @spicyj untuk #5753 mungkin juga berfungsi untuk fragmen (membungkus konten dalam sesuatu seperti <!-- react-frag: 1 --><!-- /react-frag: 1 --> ). Ya, komentarnya agak jelek, tetapi jauh lebih dapat diandalkan daripada apa yang saya coba lakukan dengan _nestedChildCount . Pendekatan itu sekarang digunakan di https://github.com/mwiencek/react/tree/frag-component

Saya belum melihat ini disebutkan di utas sejauh ini, tetapi saya pikir menyelesaikan ini juga meningkatkan komposisi. Misalnya, bayangkan Anda memiliki kisi di mana Anda ingin sel memudar dalam urutan tertentu. Idealnya, ada dua komponen yang berperan di sini: satu untuk menangani tata letak dan satu lagi untuk menangani animasi. Anda akan memiliki API seperti ini:

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

Ini akan memungkinkan Anda beralih ke tata letak yang berbeda, atau animasi yang berbeda, tanpa harus mengetahui detail implementasi yang lain. GridLayout akan menerima daftar anak-anak. FadeAnimator akan mencegat daftar itu, menyuntikkan gaya yang sesuai dan/atau pendengar acara, dan mengembalikan daftar baru untuk digunakan GridLayout . Tidak ada alasan bagi FadeAnimator untuk memperhatikan tata letak grid, kecuali bahwa elemen React tidak dapat mengembalikan Array dari render. Selain itu, tidak ada cara sederhana untuk mengganti kisi dengan, katakanlah, tata letak batu, karena FadeAnimator diperlukan untuk bertindak sebagai wadah untuk anak-anaknya.

Dengan keterbatasan saat ini, saya kira Anda bisa melakukan sesuatu seperti ini:

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

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

tapi itu membuat kodenya kurang jelas, lebih kompleks, dan lebih sulit untuk dibuat.

Tambahkan API fragmen untuk memungkinkan pengembalian beberapa komponen dari render！
Tambahkan API fragmen untuk memungkinkan pengembalian beberapa komponen dari render！
Tambahkan API fragmen untuk memungkinkan pengembalian beberapa komponen dari render！
Tambahkan API fragmen untuk memungkinkan pengembalian beberapa komponen dari render！
Tambahkan API fragmen untuk memungkinkan pengembalian beberapa komponen dari render！
Tambahkan API fragmen untuk memungkinkan pengembalian beberapa komponen dari render！
Tambahkan API fragmen untuk memungkinkan pengembalian beberapa komponen dari render！
Tambahkan API fragmen untuk memungkinkan pengembalian beberapa komponen dari render！

@texttechne saran lebih baik. Alih-alih memperkenalkan API tambahan, reaksi harus menangani beberapa elemen root dalam render.

Menangani beberapa elemen root dalam render akan sulit menurut saya.
Artinya ada: https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js#L1089

Anda akan memiliki array elemen daripada elemen.
Karena ini, sejauh yang saya pahami, Anda sekarang harus membuat instance beberapa elemen React: https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js# L471

Kemudian, pasang beberapa elemen React yang dipakai: https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js#L471

Dan mendamaikan semua markup yang dihasilkan dalam urutan yang baik.

Saya pikir itu datang dengan kelemahan yang mungkin tidak ingin menyiasati proses rekonsiliasi.
Apakah kita ingin memiliki fragmen sebagai elemen atau fragmen sebagai sintaksis gula di sekitar transformasi?

Saya pikir fragmen itu sebagai elemen baik-baik saja, kita hanya perlu membuat jenis simpul internal baru yang mirip dengan simpul teks atau simpul kosong, bukan? Meskipun saya tidak tahu bagaimana kami akan mengelolanya.

Misalnya, bagaimana Anda menangani ketika salah satu akar dilepas? Bagaimana Anda menangani pembaruan dengan benar?
Atau, bagaimana Anda mengelola banyak akar di dalam DevTools? (jawaban yang jelas: perbaiki DevTools...)

Saya pikir fragmen adalah komponen komposit. Di mana perbedaan tepatnya?
Jika kita akhirnya menduplikasi kode untuk mengimplementasikan fragmen, sebaiknya kita menerapkan sintaks gula untuk menjaga React internals "pristine" ?

Saya bertanya-tanya, saya telah bermain-main dengan React internal di sekitar pertanyaan Subtree (renderSubtreeIntoContainer) dan saya merasa itu agak terkait. Saat Anda ingin merender menjadi subpohon baru, Anda sebenarnya harus membuat root baru. Jadi, jika kita mendukung banyak akar pada tingkat pohon, apakah kita membuat akar baru setiap kali:

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

akan menghasilkan dua panggilan "render menjadi root baru".

Daripada satu panggilan jika kita menggunakan pembungkus, kan? Bagaimana dengan kinerja? Kesederhanaan? Sejujurnya, perasaan saya adalah: kita tidak boleh menyentuh React internal untuk menangani situasi ini. Sebaliknya, dapatkah kita melakukan hal ini dengan BEJ? Bisakah kita meningkatkan sintaks JSX?

(_Disclaimer_: Saya tidak sepenuhnya terbiasa dengan React internal, dan mungkin ada beberapa bagian yang tidak sepenuhnya saya pahami atau saya tidak mengerti. Mohon maaf atas kesalahpahaman saya.)

Sunting: memperbaiki/mengklarifikasi hal-hal. Juga, GitHub secara misterius menata email dengan aneh, jadi saya harus memformat ulang blok kode... :-(

Hai, kontributor/pembuat inti Mithril di sini.

TL;DR: Fragmen sangat sulit, bahkan ketika API dan internalnya
sederhana.

Omong-omong, saya tahu dari pengalaman itu _sangat_ sulit untuk diterapkan. Ini
juga telah diminta beberapa kali untuk Mithril, tetapi ditolak karena
kesulitan belaka. Setiap upaya untuk mengimplementasikannya telah gagal dengan
setidaknya sepertiga dari rangkaian tes gagal.

Saya masih mengerjakan detail di perpustakaan vdom yang saya rencanakan untuk ditulis,
dan itu akan memperlakukan semuanya sebagai sebuah fragmen, tetapi ini adalah sesuatu yang Anda miliki
untuk secara harfiah (kembali) menulis bagian rendering dari awal. Seperti Bereaksi,
itu akan dipisahkan dari DOM, tetapi API akan sangat berbeda
konseptual untuk rendering.

Inilah tangkapan dengan fragmen: Anda harus mengelolanya sepenuhnya
secara internal atau Anda tidak membedakannya dengan benar. Bahkan
document.createContextualFragment tidak berguna. Sebagai contoh, yuk
mengubah dua pohon, rendering dihilangkan:

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

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

Transformasi yang benar untuk ini adalah mengganti elemen B dan elemen C , membiarkan sisanya tidak tersentuh. Mencari tahu itu tidak sepele, dan pada dasarnya Anda harus mengulangi anak-anak fragmen sambil mengabaikan fakta bahwa mereka ada di dalam sebuah fragmen.

Tetapi ketika fragmen itu hilang, Anda harus menangani semantik kait, seperti
shouldComponentUpdate (Saya tidak ingat nama React untuk hook itu). Jadi
Anda masih harus melacak fragmen secara mandiri. Anda membedakan mereka
isinya seolah-olah itu adalah bagian dari fragmen induknya, tetapi Anda masih memiliki
untuk melacak posisi fragmen itu demi komponen.

Atau dengan kata lain, komponen tidak lagi secara intrinsik terkait dengan
simpul DOM. Sebaliknya, mereka ditautkan ke fragmen yang sesuai. Bereaksi, seperti kebanyakan pustaka dan kerangka kerja vdom lainnya, secara intrinsik memasangkan komponen ke representasi pohonnya, bahkan dengan tipe yang diharapkan. Ini adalah cara termudah untuk mengimplementasikan algoritma diff yang
menangani komponen. Ketika mereka dipisahkan, Anda harus melakukan pemisahan
pembukuan untuk keduanya. Anda tidak menginisialisasi komponen saat Anda menginisialisasi
simpul. Sekarang dua proses yang benar-benar terpisah. Sulit dilakukan
awalnya, dan bahkan lebih sulit untuk menambahkan dukungan untuk sesudahnya.

Terima kasih semua untuk kata-katanya. Kami tahu ini sulit dan masih ada dalam daftar tugas kami. (Bertanya dengan antusias tidak akan mewujudkannya lebih cepat @janryWang.)

@isiahmeadows FYI, cabang penulisan ulang Mithril mendukung fragmen.

@spicyj Anda dipersilakan untuk melihat implementasi [1] [2] dan menguji [1] [2] jika Anda belum mengikutinya. Seluruh mesin diff hanya sekitar 400 LOC, jadi semoga mudah diikuti

@isiahmeadows Saya pikir GitHub memakan sebagian dari komentar Anda. Blok kode rusak, dan saya tidak dapat melihat instance pertama <D /> .

Terlihat OK di e-mail sekalipun. Mungkin Anda menemukan bug di GitHub?

Sayangnya penanganan penurunan harga GitHub berperilaku berbeda ketika komentar datang dari email. Saya mengedit komentar untuk menghapus baris kosong dan sekarang muncul.

Saya meneruskan email asli ke support@github. Mudah-mudahan, mereka dapat memperbaiki parser. 😃.

@lhorie Anda menggunakan sintaks array untuk fragmen?
apakah anda memiliki polyfill untuk DocumentFragment ?

Dan menggunakan elemen pembungkus "pseudo", seperti komentar HTML bukanlah suatu pilihan? Saya pikir itulah cara simpul teks di mana "diselesaikan" ...

Terima kasih telah memperbaiki komentar itu @spicyj

Untuk mengatasi masalah yang dikemukakan @isiahmeadows dalam contohnya: mesin Mithril baru _tidak_ mengikuti semantik yang disarankan @isiahmeadows karena beberapa alasan:

• menerapkan semantik itu akan membuat diffing _significantly_ lebih kompleks
• itu akan membuat sulit untuk alasan tentang kunci dan bug terkait kunci karena menjadi mungkin untuk ruang kunci untuk keluar dari komponen dan bahkan ke komponen saudara dan sub-anak.
• itu akan membuat siklus hidup fragmen menjadi non-intuitif (misalnya dalam contoh itu, B.bar dihapus, tetapi begitu juga fragmen, dan fragmen baru dibuat untuk membungkus C). Ini melanggar prinsip umum bahwa siklus hidup "berjenjang", yang berarti bahwa Anda tidak dapat lagi memastikan bahwa simpul anak dihapus jika simpul induk tertentu dihapus. Seperti poin sebelumnya, hal ini berpotensi menimbulkan kebocoran pada kemampuan enkapsulasi suatu komponen.
• jika, secara hipotetis, seseorang mengalami masalah diff terkait dengan mesin diff yang tidak mengikuti semantik tersebut, solusi ruang aplikasi sama sepelenya dengan membungkus sebuah fragmen di sekitar simpul yang menyinggung.

Saya akan tertarik jika tim inti dapat memperluas catatan di atas re: _why_ ini sulit dengan arsitektur saat ini. Melihat bahwa React dan mesin rendering Mithril pada dasarnya mencoba untuk memecahkan masalah yang sama, dan bahwa Mithril sekarang mendukung fragmen ke tingkat yang saya yakini layak dan berguna, mungkin mengimplementasikannya di React mungkin lebih layak jika aspek semantik yang berbeda dinilai secara terpisah (dan berpotensi ditolak) seperti yang dilakukan dengan Mithril.

Perhatikan bahwa saya memperbaiki komentar saya. Saya membuat beberapa kesalahan, dan GitHub tidak dapat menata respons email dengan baik... : mengerutkan kening:

@Primajin Saya juga bertanya-tanya, tapi saya curiga mereka akan diteruskan sebagai satu elemen. Sangat penting untuk membuat fragmen dapat dikomposisi (lihat contoh saya di atas ). Namun, mungkin ada saat-saat Anda ingin memperlakukan mereka sebagai satu kesatuan juga.

Mungkin, React.Children.map harus memperluas fragmen. Jika Anda ingin mengulangi setiap anak (termasuk anak-anak dari fragmen anak), gunakan Children.map . Jika Anda ingin memperlakukan fragmen sebagai kotak buram, bekerja langsung dengan props.children sebagai {array, element}.

@lhorie Saya belum pernah terlibat dalam penulisan ulang, jadi saya tidak begitu akrab dengan seluk-beluknya. Saya sibuk dengan kenyataan bahwa saya memiliki satu tugas akhir minggu ini dan tiga minggu depan, ditambah saya bekerja dengan seseorang untuk mengatur magang yang dibutuhkan perguruan tinggi saya. Saya juga fokus menyelesaikan Techtonic, yang _hampir_ menyelesaikan CLI (tes rusak yang seharusnya tidak dilakukan).

@isiahmeadows Hanya pengingat ramah untuk tetap pada topik. Jangan ragu untuk menggunakan ruang mithril gitter jika Anda ingin mengobrol tentang topik lain.

@appsforartists

Mungkin, React.Children.map harus memperluas fragmen

Mithril stable melakukan sesuatu yang serupa secara internal (yaitu meratakan sub-array), tetapi saya beralih dari model itu karena alasan kinerja (dan juga karena beberapa riwayat sakit kepala mengenai daftar vnode yang mencampur node yang dikunci dan yang tidak dikunci). Mungkin sesuatu yang perlu dipertimbangkan.

Dan menggunakan elemen pembungkus "pseudo", seperti komentar HTML bukanlah suatu pilihan? Saya pikir itulah cara simpul teks di mana "diselesaikan" ...

Kami telah menggunakan https://github.com/mwiencek/react-packages dalam produksi selama beberapa bulan. Ini menggunakan pendekatan pembungkus komentar ini, sehingga fragmen dapat bersarang dengan jelas.

@mwiencek Apakah mungkin untuk menggunakan pendekatan Anda tanpa paket reaksi khusus?

@mwiencek apakah pembungkus komentar diperlukan? Saya tidak mengharapkan hal-hal pintar dari fragmen, jika Anda memindahkan elemen dari fragmen ke dalam fragmen saudara atau elemen root, itu hanya dapat dibuat ulang.

Jadi jika Anda mengikuti pohon vdom secara berurutan, Anda tidak perlu komentar, atau bukan?

Bagaimanapun, solusi Anda sepertinya itulah yang dibutuhkan untuk menyelesaikan masalah ini, pada pandangan pertama. 👍

Tidak sepenuhnya, tetapi mereka membuat implementasi lebih sederhana dalam hal ini.

Jadi pada dasarnya saat ini tidak mungkin membuat daftar deskripsi yang tepat <dl> dengan React?

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

@KaiStapel Masalah ini adalah tentang mengembalikan beberapa komponen (atau elemen yang saya kira) dari render() . Selama fungsi render Anda hanya mengembalikan satu elemen / komponen root, itu akan berfungsi.

OKE:

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

Tidak baik:

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 Di-hardcode dengan baik ya, tetapi Anda tidak dapat melakukan:

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

Yang sangat menyedihkan. Hal yang sama juga berlaku untuk tabel dengan rowspans, karena Anda tidak dapat merender dua elemen <tr> sekaligus :(

Dari atas:

"Saya juga" dan "+1" tidak berharga, juga kasus penggunaan yang telah ditulis dalam komentar (misalnya, kami tahu Anda tidak dapat menempatkan elemen <tr> atau <dd> dengan <div>) .

Mengingat bahwa ada solusi yang berfungsi di https://github.com/mwiencek/react-packages , apakah ada kemungkinan ini akan segera menjadi bagian dari React? Atau kita sedang menunggu rekonsiliator baru?

Mengingat bahwa ada solusi yang berfungsi di https://github.com/mwiencek/react-packages

Apakah Anda berhasil menggunakannya dalam proyek nyata?

@mwiencek

Implementasinya tidak terlalu bagus, tetapi jika berhasil untuk orang, saya dapat mengirimkan PR dan membiarkan pengembang React mengobrak-abriknya.

Tentu, silakan kirim PR!

Tentang mengirimkan PR, yang terakhir saya dengar dari @spicyj adalah bahwa mereka ingin menyelesaikan algoritma inti baru dan melakukan solusi yang tepat dengan itu, karena node komentar tidak terlalu masuk akal di React Native. Saya belum mengikuti status itu, tetapi saya tidak berpikir rencana itu telah berubah. Saya senang orang-orang menganggap paket-paket itu berguna untuk sementara waktu.

Algoritma baru sedang bekerja dan mendukung fragmen. Namun saya tidak berharap itu menjadi siap produksi untuk bulan-bulan mendatang. Saya ingin tahu apakah menambahkan ini terlebih dahulu ke React DOM dan kemudian ke React Native terlalu buruk? Kelemahannya adalah ini memecah ekosistem sedikit (permainan kata-kata!), tetapi mungkin memberi kita waktu untuk bereksperimen dengan fitur itu. Kami memiliki pertemuan tim hari ini jadi saya akan mengajukan pertanyaan ini jika kami punya waktu untuk mendapatkan pemahaman yang lebih baik.

@gaearon Bisakah saya menunjukkan bahwa mendukung fragmen sangat sederhana, itu hanya gula, saat ini saya menggunakan <frag> sendiri melalui pembungkus sepele kecil. Apakah mengembalikan banyak anak sebagai root komponen benar-benar penting?

@syranide Saya menggunakan build khusus dengan frag di lingkungan beta, namun saya ingin menggunakan build React resmi sebagai gantinya. Bisakah Anda memberikan pembungkus <frag> Anda? :) Terima kasih

@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);
};

Kami berbicara lebih banyak tentang ini dalam pertemuan tim terakhir. Konsensusnya adalah bahwa kami tidak ingin mengikuti implementasi khusus ini. Namun fitur ini akan didukung dalam penulisan ulang inti jangka panjang (tidak ada garis waktu untuk saat ini).

Kami juga akan mempertimbangkannya lagi sebagai salah satu hal yang berpotensi kami kerjakan untuk paruh kedua tahun ini jika penulisan ulang terlalu lama atau tidak berhasil. Tidak ada jaminan itu akan membuat daftar tetapi kami akan membuat Anda semua diperbarui jika itu muncul.

Untuk mendapatkan ide yang lebih baik tentang apa yang kami kerjakan, silakan lihat repo catatan rapat kami! Anda dapat menemukan diskusi terbaru kami tentang ini di https://github.com/reactjs/core-notes/blob/master/2016-07/july-07.md.

@gaearon Akan menarik dengan daya tarik untuk memiliki setidaknya sintaks frag resmi.

@syranide Terima kasih atas kodenya, tetapi sayangnya sepertinya saya tidak dapat menggunakannya karena saya memerlukan frag sebagai komponen aplikasi root yang sedang dirender oleh metode ReactDOM.render dan metode ini tidak akan menerima fragmen .

Terima kasih, Ini akan berguna bagi orang lain yang tidak membutuhkan frag sebagai root aplikasi.

@amertak Ya itu hanya untuk mengaktifkan sintaks yang lebih masuk akal untuk membuat fragmen, itu tidak menambahkan fitur baru.

@syranide
Saya berpikir Apakah mungkin untuk membuat komentar secara manual dan memperlakukannya sebagai komponen lain (yang mungkin tidak diperlukan)?
Komentar internal ditangani sebagai tipe #comment jadi mungkin bisa menelepon
React.createComponent('#comment', { ... }, children) ?
Hanya sebuah ide. Solusi kecil.

Hal utama yang hilang di sini adalah dapat membuat simpul comment , benar? :)

@gaearon Agak sedih karena ini tidak segera hadir, tapi saya menghargai transparansinya. Selamat menulis!

Solusi alternatif sampai pembaruan?
Bagi saya, saya perlu membuat menu dropdown Botstraap

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

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

Tapi tidak mungkin, ide ?
Terima kasih,

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

Itu jelas dibungkus dalam satu <div class="btn-group"> seperti yang ditunjukkan di Documents

Ya tentu saja, tetapi ada dua elemen yang dibungkus <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>

Dan dua elemen yang dibungkus dalam elemen tunggal tidak mungkin,
Terima kasih atas waktunya @Primajin

Pindahkan saja semuanya satu tingkat:

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
);

Oke, tapi saya punya item lain di orang tua.
Ini hanya akan memindahkan masalah.

<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>

Dan dalam hal ini, React akan menggantikan semua yang ada.
Apakah mungkin untuk melakukan "tambah" tanpa mengganti elemen lainnya?

Terima kasih,

@ rifton007 bukan itu cara kerjanya. Anda dapat memiliki beberapa elemen/komponen sebagai saudara kandung, dibungkus dalam sebuah wadah. Batasannya adalah bahwa komponen tidak dapat return beberapa elemen. Kode yang baru saja Anda posting akan berfungsi.

Karena itu, jika Anda menemukan contoh yang tidak berhasil, adalah sopan untuk membaca seluruh utas dan mempertimbangkan apakah Anda menambahkan contoh _baru_ atau hanya mengulangi masalah yang sama yang telah diakui. Ini adalah batasan yang diketahui, dan utas ini berisi diskusi panjang tentang detail dan alasan pembatasan tersebut. Dan juga menyatakan mereka berniat untuk memperbaiki dukungan ini, pada akhirnya. Apa yang ingin Anda capai dengan menunjukkan contoh lain untuk masalah yang diakui?

Maaf, saya hanya ingin tahu apakah ada yang punya solusi alternatif sementara itu.
Anda dapat menghapus posting saya jika perlu.

Saya membuat aplikasi dengan Framework7 dan React, namun format html framework7 sudah diperbaiki,

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

Saya tidak dapat membungkus elemen anak tingkat pertama (navbar, searchbar) di div lain yang tidak memiliki kelas 'halaman'

Saya memiliki komponen yang mengembalikan daftar baris

FYI, penulisan ulang yang sedang kami kerjakan (#6170) sudah mendukung fragmen. Anda dapat melacak kemajuan kami di #7925 dan di http://isfiberreadyyet.com.

Fakta bahwa elemen <table> tidak dapat merender elemen tertentu adalah alasan yang cukup untuk menambahkan fitur ini agar kompatibel dengan API web.

EDIT: Ah, pecahan! Menantikan mereka.

@trusktr

Seperti yang dicatat dalam posting pertama di utas ini:

Catatan dari pengelola:

Kami tahu ini adalah masalah dan kami tahu persis masalah apa yang bisa diselesaikan . Kami menginginkan ini juga tetapi ini adalah masalah yang sulit dengan arsitektur kami saat ini. Komentar tambahan yang menyatakan keinginan untuk fitur ini tidak membantu.

😉.

Astaga, aku harus berhenti melakukan itu.

Saya memilih ini tetapi ingin membagikan kasus penggunaan yang valid. Misalkan saya memiliki 3 tombol yang saya inginkan tata letak cairan CSS (kiri, tengah, kanan). Tombol kiri selalu terlihat, tetapi dua lainnya terlihat secara kondisional. Di React (khususnya React Native), saya menggunakan flexbox dan merendernya sebagai:

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

Tombol tengah dan kanan tidak diposisikan dengan benar karena terbungkus dalam Tampilan tunggal.

Ya, saya dapat membagi tombol tengah dan kanan ke metode mereka sendiri, tetapi itu akan memperkenalkan banyak kode yang berlebihan karena mereka berbagi banyak perilaku.

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

Seperti yang dikatakan di atas, kami sudah mengetahui kasus penggunaan untuk fitur ini dan sedang bekerja keras untuk mendukungnya. (Sudah ada setengah lusin orang di atas yang membahas masalah flexbox.) Karena sepertinya tidak ada lagi diskusi yang produktif, saya mengunci ini. Kami akan memperbarui ketika kami memiliki berita tentang implementasi baru.

Saya pikir kita bisa menutup ini.

Pengembalian array dari komponen didukung sejak React 16 Beta 1 yang dapat Anda coba sekarang .

Masih ada beberapa batasan (dukungan SSR belum siap) tetapi kami melacaknya di #8854 dan akan memperbaikinya sebelum rilis 16 final.

Terima kasih kepada semua orang atas tanggapan Anda!

TERIMA KASIH DAN

🍾🍾🍾.

🦏.

@gaearon Peningkatan yang luar biasa! Apakah ini mendukung simpul teks murni?

Ya, ini juga mendukung pengembalian string.

Bolehkah saya bertanya bagaimana ini seharusnya bekerja?

Saya berharap itu akan memungkinkan kita untuk membuat 2 elemen XJS yang berdekatan tetapi jika saya melakukan return ["foo", "bar"] (sesuatu yang lebih berguna;), saya mendapatkan bundle.js:66656 Warning: Each child in an array or iterator should have a unique "key" prop. yang diharapkan

Jadi, apakah fitur itu cara untuk tidak mengelilingi daftar nyata dengan elemen asing?

Jadi, apakah fitur itu cara untuk tidak mengelilingi daftar nyata dengan elemen asing?

Ya, cara untuk menyediakan beberapa elemen dari satu render. (Untuk informasi lebih lanjut, lihat posting masalah awal.)

Jika semua item array Anda diketahui sebagai string, gabungkan saja dan kembalikan satu string. Jika tidak, Anda dapat memakan peringatan ini atau mencari tahu apa yang harus dilakukan untuk membungkusnya dalam elemen sehingga mereka dapat dikunci untuk meningkatkan rekonsiliasi DOM, seperti yang akan Anda lakukan jika Anda telah menyertakan sebuah larik string di dalam elemen lain di BEJ.

@rajin mengembalikan ['foo', 'bar'] tidak relevan dengan masalah ini. Anda tidak pernah bisa dan masih tidak bisa melakukan return <div>{['foo','bar']}</div> Setiap anak dalam array harus memiliki prop 'kunci' apakah itu dalam tag jsx internal seperti <div> atau sedang dikembalikan. Yang dapat Anda lakukan sekarang adalah:

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

Ini menghilangkan batasan besar dalam bereaksi.

Btw mengembalikan ['foo', 'bar'] memberi Anda peringatan bukan kesalahan dan untuk menghapus peringatan itu, Anda dapat dengan mudah menggabungkan string tersebut atau jika itu adalah tag jsx dan bukan string, Anda dapat menambahkan kunci prop ke string tersebut. Jadi tidak ada batasan tentang mengembalikan array.

@JesperTreetop terima kasih.
@sassanh , dari contoh Anda, sepertinya saya terlalu "malu" untuk menggunakan kunci "hanya" untuk menghindari <div> yang tidak berguna (secara semantik) di sekitarnya. Apakah maksud Anda saya harus melanjutkan dan tidak ada penalti kinerja yang nyata? Itu memang akan menjadi peningkatan NYATA!

@ rajin Saya ragu itu memperkenalkan penalti kinerja apa pun tetapi Anda tidak memerlukan div yang tidak berguna di sekitarnya kecuali jika itu mengelilingi string dan jika itu mengelilingi string, Anda dapat menghindari array sama sekali dan bergabung dengan string. Jika bukan string, Anda dapat menambahkan kunci ke komponen. Misalnya jika Anda memiliki dua komponen Foo dan Bar Anda dapat mengembalikan [<Foo key='foo'/>, <Bar key='bar'/>] dan Anda tidak perlu mengapit komponen Anda (seperti biasa) maupun array Anda (terima kasih kepada rilis baru ini, Anda perlu mengelilingi array sebelum 16).

@sassanh keren kalau begitu. Tentu saja kasus penggunaan saya dengan banyak komponen. Senang!! ;)

Sebenarnya aneh bagi saya bahwa kami memperingatkan tentang kunci yang hilang ketika semua item adalah string. Saya tidak berharap kita melakukannya. Apakah ini perilaku yang ada di 15 ketika string berada di dalam div? Jika tidak maka kita harus memperbaikinya di 16 untuk string tingkat atas (karena tidak mungkin memberikan kunci kepada mereka).

@gaearon maaf, contoh saya menyesatkan: maksud saya komponen.

Saya memeriksa dan di bawah -beta.5 , React tidak mengeluarkan peringatan saat merender array dengan banyak string.

Meskipun demikian, saya bingung dengan persyaratan key saat merender array hanya untuk menghindari komponen di sekitarnya. Saya mengerti dan tidak ada apa-apa selain itu mungkin akan menimbulkan banyak pertanyaan tentang SO (saya tidak punya yang lebih baik untuk ditawarkan ...)

Dan terakhir, sekali lagi terima kasih.

Peringatan ini sama persis seperti untuk setiap penggunaan array komponen lainnya, karena bermuara pada "pekerjaan ekstra" yang sama persis untuk rekonsiliasi, dan dengan demikian potensi pengoptimalan yang sama persis dengan menetapkan key . Bagi saya kejutannya adalah jika array komponen diperlakukan secara berbeda tergantung pada ini, dan saya membayangkan itu akan memunculkan beberapa pertanyaan Stack Overflow juga. Belum lagi saya pikir itu akan melibatkan beberapa overhead hanya untuk melacaknya sejak awal.

.. dan sebagian besar waktu saya akan mengembalikan array dari suatu fungsi, saya ingin peringatan key di tempat. Tampaknya saat-saat Anda tidak menginginkan peringatan adalah minoritas, dan tidak ada cara bagi Bereaksi untuk mengetahui apakah pantas untuk tidak memperingatkan.

Peringatan diperlukan karena kurangnya kunci dapat menyebabkan masalah kebenaran, bukan hanya masalah kinerja. Ini dijelaskan dalam banyak masalah lain yang menanyakan mengapa kunci diperlukan, jadi saya mendorong Anda untuk mencarinya dan membaca diskusi itu. Saya setuju bahwa dokumen bisa lebih jelas tentang ini, dan itu adalah sesuatu yang mungkin akan kita lihat saat berikutnya kita melakukan sprint perubahan dokumen.

Tidak ada perbedaan konseptual antara array yang langsung dikembalikan dari render, dan array di dalam div. Jadi tidak ada alasan mengapa akan ada peringatan kunci dalam satu kasus tetapi tidak yang lain. Mereka perlu bekerja dengan cara yang sama karena keduanya dipengaruhi oleh masalah yang sama ketika kunci hilang.

Yang mengatakan kami memahami itu menjengkelkan untuk menentukan kunci untuk konten statis . Sama seperti Anda tidak menentukan kunci ketika Anda menulis struktur JSX di mana anak-anak diketahui secara statis (dan dengan demikian tidak pernah menyusun ulang), akan menyenangkan memiliki cara untuk melakukan ini dengan array.

Di masa mendatang, kami mungkin menyelesaikan ini dengan menambahkan dukungan eksplisit untuk fragmen di BEJ dengan sintaks seperti:

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

Itu bisa menghasilkan array tetapi secara implisit menetapkan indeks numerik ke anak-anak karena dalam hal ini kita tahu mereka tidak akan pernah bisa menyusun ulang. Jaminan yang diberikan oleh ekspresi anak JSX inilah yang memungkinkan kami lolos tanpa menentukan kunci dalam kode JSX normal di mana div mungkin memiliki banyak anak.

Tetapi kami belum memiliki sintaks ini. Jadi untuk saat ini, ini adalah batasan yang diketahui.

@JesperTreetop & @zwily , @gaearon menjelaskannya jauh lebih baik daripada yang saya lakukan ;)

Setelah Anda tahu, itu bukan masalah besar tetapi karena kita semua ingin React berkembang, saya hanya mengatakan…

@gaearon Apakah ada masalah lain untuk proposal sintaks <> yang dapat kita tonton daripada diskusi lebih lanjut tentang masalah ini? Saya mencari di sekitar tetapi saya tidak dapat menemukannya.

@smrq +1 untuk mempertanyakan - Saya mengikuti segala sesuatu tentang batasan canggung itu (hasil rendrer() satu-ke-satu, kunci dan sintaks atau fragmen JSX) tetapi satu-satunya tiket yang saya tahu adalah https://github.com/ facebook/jsx/isu/65

Saya juga mengira bahwa serat akan memperbaiki masalah dengan kunci sama sekali — tetapi sepertinya itu mimpi yang tidak terpenuhi

Kunci bukanlah "masalah". :) Mereka adalah bagian mendasar dan penting dari kerangka tampilan apa pun yang memungkinkan Anda membuat daftar dinamis.

Lihat https://facebook.github.io/react/tutorial/tutorial.html#keys untuk penjelasan lebih rinci.

@spicyj sebenarnya ini adalah «masalah» karena menyebabkan pengeluaran energi yang diperpanjang dari pengembang dan ada kemungkinan mendasar untuk memprogram kerangka tampilan tanpa persyaratan seperti itu (misalnya https://github.com/dfilatov/vidom)

ada kemungkinan mendasar untuk memprogram kerangka tampilan tanpa persyaratan seperti itu (misalnya https://github.com/dfilatov/vidom)

vidom memang menggunakan kunci dalam koleksi. Secara teknis mungkin berfungsi tanpanya tetapi kemungkinan akan jauh lebih lambat. React juga secara teknis dapat bekerja tanpa kunci, tetapi akan sangat tidak terduga untuk menemukan bahwa setengah dari komponen Anda harus diperbarui ketika Anda menghapus satu item dari daftar. Dengan kunci, hanya satu item yang dilepas.

@goto-bus-stop vidom dapat menggunakan kunci, tetapi tidak diperlukan dan tanpanya hanya kasus yang sangat besar dengan banyak pembaruan yang dapat menyebabkan masalah kinerja nyata

jadi saya menganggap bagian ini sebagai opsional (seperti, misalnya, shouldComponentUpdate ) yang dapat digunakan untuk tweak ferformance dalam kasus-kasus individual

@veged contoh vidom berjuang tanpa kunci .

Itu tidak tahu itu seharusnya menyusun ulang elemen, jadi itu membuang instance pada setiap render dari komponen root.

sebagai seseorang yang cukup akrab dengan ruang virtual-dom [1]. saya dapat mengatakan bahwa:

1. kunci diperlukan untuk pembaruan dom & status yang dapat diprediksi di antara saudara kandung yang serupa.
2. kunci biasanya bukan optimasi, dan - pada kenyataannya - biasanya sebaliknya.

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

namun, masalah yang tidak ambigu di sini (seperti yang dijelaskan @gaearon ) adalah penggunaan array yang sepenuhnya statis dan perbedaan antara array statis dan fragmen JSX statis

@brigand O tidak ragu bahwa penataan ulang komponen negara-penuh dapat menyebabkan beberapa masalah ;-) tetapi memaksa setiap kasus lain (menurut saya lebih dari mereka) untuk berjuang untuk ini... terlihat kontroversial

Kunci penting untuk Bereaksi. Bahkan jika mereka tampaknya tidak menjadi masalah dalam beberapa kasus (misalnya karena komponen di bawah semuanya stateless) tidak ada yang mencegah Anda atau orang lain dalam tim untuk menambahkan komponen stateful (atau bahkan input DOM biasa) di suatu tempat beberapa tingkat di bawah dalam beberapa bulan. Pada saat itu Anda mungkin lupa bahwa Anda tidak memiliki kunci, dan dengan demikian penyusunan ulang dapat menyebabkan status (atau nilai input) dikaitkan dengan item yang salah.

Inilah mengapa kami mendorong Anda untuk menentukan kunci di mana saja untuk daftar dinamis. Tidak melakukan hal itu menyebabkan bug yang sangat sulit dilacak, dan kami pikir lebih baik menghabiskan sepuluh detik ekstra untuk menentukan kunci daripada sepuluh jam men-debug mengapa status komponen beberapa tingkat di bawah menjadi kacau di beberapa kasus sudut.

Saya sepenuhnya setuju bahwa tidak nyaman untuk menentukan kunci ketika daftar diketahui statis dan tidak pernah menyusun ulang. Anda dipersilakan untuk mendiskusikan hal ini di repo BEJ. Jika Anda tidak dapat menemukan masalah untuk ini, Anda dipersilakan untuk membuat yang baru di sana.

Karena utas ini memiliki banyak pelanggan dan fitur tersebut telah diterapkan, saya ingin menguncinya untuk menghindari mengirim spam ke banyak orang dengan pemberitahuan. Saya harap klarifikasi di atas mengatasi masalah Anda, tetapi jika tidak, Anda dipersilakan untuk membuat masalah baru untuk diskusi lebih lanjut tentang topik tertentu.

@smrq membuat masalah proposal untuk sintaks <> pada repo jsx: https://github.com/facebook/jsx/issues/84.

Kami baru saja merilis dukungan untuk ekspor React.Fragment baru dan sintaks <> terkait:
https://reactjs.org/blog/2017/11/28/react-v16.2.0-fragment-support.html