Aku suka ini. Mengurangi ukuran bundel dan prop "kelas" adalah perubahan yang akan sangat disambut.

Kerja bagus!

🙂.

Bentuk perhatian penulis perpustakaan! 🤣.

Besar!

className → class itu fantastis

Bagaimana dengan yang lainnya? Tampaknya aneh masih melakukan clipPath , htmlFor , tabIndex , dll.

Mengadopsi class merupakan terobosan besar dalam membuat perpustakaan lebih ramah untuk pemula. Selamat.

Ini luar biasa. Saya sangat ingin tahu bagaimana perpindahan ke class benar-benar berhasil dengan props.

Sepertinya ({ class }) => <div class={class} /> awalnya akan menghadirkan masalah kata kunci yang dipesan?

Ini adalah berita yang luar biasa, terima kasih @gaearon!

Saya menyukai setiap poin ini, kecuali perubahan className . Tampaknya benar-benar bertentangan dengan tujuan yang dikejar oleh poin lain (menyelaraskan dengan DOM API). React mengikat ke properti DOM, bukan atribut HTML (ini bahkan diartikulasikan di poin pertama). Properti Elemen DOM diberi nama className , bukan class . Jadi mengapa diberi nama class di React?

Fantastis! Apakah Anda memiliki tujuan untuk pengurangan ukuran bundel?

👏.

Bagaimana dengan yang lainnya? Tampaknya aneh masih melakukan clipPath, htmlFor, tabIndex, dll.

Saya terbuka untuk berdiskusi tetapi saya berpendapat bahwa perubahan ini tidak sepadan (kecuali for mungkin).

Saya pikir penulisan ulang sistem acara adalah aspek yang paling menarik dari ini. Ada peluang signifikan untuk mengurangi ukuran bundel dan memudahkan kontribusi komunitas.

Ayo lakukan!

Saya ingin tahu apakah akan bermanfaat untuk juga bekerja pada rilis JSX 2.0 pada saat yang sama? Orang-orang akan perlu mempelajari kembali beberapa hal. Mungkin lebih baik harus mempelajari kembali banyak hal sekaligus daripada beberapa hal dua kali selama periode waktu tertentu? Hanya sebuah pemikiran yang muncul ketika saya membaca ini.

Saya suka setiap poin ini, kecuali perubahan className. Tampaknya benar-benar bertentangan dengan tujuan yang dikejar oleh poin lain (menyelaraskan dengan DOM API). React mengikat ke properti DOM, bukan atribut HTML (ini bahkan diartikulasikan di poin pertama).

Namun jika kita melewati pasangan kunci/nilai yang tidak diketahui itu akan diperlakukan sebagai atribut sejak Bereaksi 16. Jadi kita sudah tidak konsisten. Juga, komentar saya adalah tentang pengguna yang salah dalam mengharapkan React untuk mengatur atribut value . Apakah React API menggunakan nama atribut atau nama properti dalam API -nya sepenuhnya ortogonal.

Saya telah membela sisi Anda dari argumen ini selama bertahun-tahun, tetapi saya pikir sekarang ini adalah gesekan yang tidak sepadan. Anda tidak mendapatkan apa-apa darinya. Membiarkan orang menggunakan class tidak memiliki efek negatif kecuali tidak bekerja dengan perusakan, dan biaya migrasi. Semua orang mengeluh tentang hal itu ketika mereka belajar Bereaksi. Saya pikir melakukan apa yang orang harapkan dalam kasus ini lebih penting daripada bertele-tele. Dan karena kita tetap mengubah hal-hal DOM lainnya, mari kita gabungkan ini bersama-sama.

Selama React Fire berkobar cepat.... 👍

Semua perubahan ini fantastis. Saya sangat bersemangat tentang ini dan implikasinya untuk react-testing-library . Secara khusus, peristiwa yang terikat ke root reaksi (atau bahkan mungkin menghapus delegasi acara sama sekali karena mungkin tidak diperlukan lagi di lingkungan modern?), berpotensi menghapus/menulis ulang peristiwa sintetis, dan onChange -> onInput akan secara serius meningkatkan implementasi react-testing-library dan pengalaman dalam menggunakan alat ini.

Saya ingin memberikan umpan balik tentang ini saat sedang diterapkan.

bahkan mungkin membatalkan delegasi acara sama sekali karena mungkin tidak diperlukan lagi di lingkungan modern

Kami mempertimbangkan ini tetapi berpikir ini mungkin penyederhanaan yang berlebihan. Delegasi acara memungkinkan kita menghindari penyiapan sekelompok pendengar untuk setiap node pada render awal. Dan menukarnya dengan pembaruan. Aspek-aspek itu tidak boleh diabaikan. Ada kemungkinan lebih banyak pembandingan yang harus dilakukan di sana.

@tannerlinsley ({ class: className }) => <div class={className} /> sayangnya ini akan membunuh jsx 2.0 objek notasi tangan pendek ( <div class /> ), tapi biarlah ...

Akan sangat, sangat bagus jika class akhirnya bisa mengambil objek dan array btw di sebelah string.

Apakah Anda memiliki tujuan untuk pengurangan ukuran bundel?

Menjatuhkan sepertiga dari React DOM akan menyenangkan. Kita lihat saja nanti. Sulit untuk mengatakan lebih awal tetapi kami akan melakukan yang terbaik.

Wow, ini adalah enumerasi dari hampir semua keputusan desain yang saya sebutkan ketika orang bertanya kepada saya tentang React kontra.

Cinta arah ini pergi.

Apa yang akan menjadi jalur pemutakhiran untuk pustaka yang menggunakan className dan ingin mendukung beberapa versi React?

@gaearon Mungkin itu bukan masalah besar, hari ini bagus untuk mengatakan "alat peraga adalah properti DOM bukan atribut HTML", sekarang akan menjadi "kecuali className, yang itu adalah nama HTML". Saya juga ingin dapat menyalin/menempel SVG tanpa 10 menit bermain-main dengan atribut untuk dicocokkan dengan React's

Bagaimana dengan htmlFor ?

Sepertinya transisi className -> class harus dilakukan dengan sangat hati-hati, mungkin dalam jangka waktu yang lama. Ini akan menyebabkan banyak masalah bagi ekosistem, karena hampir setiap komponen perlu diubah - bahkan yang sangat sepele. Ini sebagian besar baik-baik saja jika Anda "memiliki" kode dan ada codemod, tetapi ketika Anda bergantung pada perpustakaan pihak ke-3, Anda sebagian besar bergantung pada pengelola.

Perubahan lainnya tampaknya berisiko relatif rendah dari sudut pandang ekosistem, tetapi menghilangkan className benar-benar akan menyebabkan banyak kesulitan. Sepertinya mungkin untuk membaginya menjadi masalah terpisah dan merilisnya pada jadwal yang berbeda dengan perubahan lainnya.

Saya setuju dengan @felixfbecker
Semuanya terdengar luar biasa dan akan meningkatkan kualitas untuk pengembang dan pengguna, tetapi className berubah.

Mampu mendekonstruksi semua properti tetapi yang satu pasti akan menyebabkan lebih banyak kebingungan dan lebih sulit untuk dijelaskan kepada pengguna baru daripada yang mereka butuhkan untuk menggunakan className karena class adalah kata kunci (yang dapat mereka lihat dengan jelas ketika kesalahan dibuat, karena warnanya berbeda) . Bekerja di sekitar kelas dalam mendekonstruksi memerlukan pengenalan sintaks baru atau cara yang sama sekali berbeda untuk membaca properti spesifik yang hanya akan berfungsi sampai Anda perlu menggunakan properti istirahat.
Ini menciptakan banyak masalah hanya untuk menyelamatkan empat karakter.

@felixfbecker mungkinkah class / for di JSX dan className / htmlFor di versi JS?

<label class="foo" for="bar">..</label>

akan menjadi

React.createElement('label', {className: 'foo', htmlFor: 'bar'}, '..')

Rencana yang bagus! Bagus untuk di sini itu! 👏👏👏.

Ini luar biasa, saya tidak sabar untuk menggali hal-hal baru.

Sederhanakan sistem acara secara drastis (#4751).

Sekarang reaksi tidak dapat mendelegasikan penangan ke elemen khusus, tanpa memperluas definisi ReactDOM. https://github.com/facebook/react/issues/9242

Artinya React tidak dapat mengatur handler kustom pada elemen kustom seperti <x-component onMyEvent={ev => {...}} />

@gaearon
Apakah Anda punya rencana tentang ini?

Semua perubahan ini sangat bagus tetapi perubahan meta terbesar dari semuanya adalah pengurangan ukuran menurut saya. React memiliki DX rata-rata, tetapi cukup gemuk sehingga mengunduh dan menguraikannya di jaringan rata-rata dan khususnya seluler menjadi masalah.

Kita bisa memiliki semuanya!

Akan menulis ulang delegasi acara membuka pintu untuk memperbaiki #1254; di mana beberapa peristiwa menurunkan kinerja untuk simpul yang dilampirkan (yang untuk React berarti seluruh aplikasi).

Juga, sebagai jangka panjang, apakah Anda mempertimbangkan untuk memiliki alat peraga dataSet sintetis? Tidak dapat mengetik props HTML yang diizinkan (karena data-*) menyebabkan banyak bug saat meneruskan props ke node DOM. Komponen React yang saat ini diketik harus memilih antara tipe yang tepat untuk props dan mengizinkan atribut data.

saya senang

@ryanflorence Agak aneh tapi agak menyedihkan bahwa tidak ada seorang pun (sejauh yang saya tahu) memiliki ide untuk membuat html/css/svg -> jsx transfomer untuk memudahkan migrasi ke Bereaksi dengan begitu banyak perubahan sepele untuk memetakan HTML attrs ke React props. Begitu banyak jam kerja yang terbuang untuk melakukan sebagian besar cari-dan-ganti :(

Sangat aneh melihat yang berikut ini dalam masalah yang sama (dan komentar):

Tujuan kami adalah membuat React lebih selaras dengan cara kerja DOM
namakelas → kelas
Tampaknya aneh masih melakukan clipPath, htmlFor, tabIndex, dll.

Ketika semua ini adalah rekan langsung dari DOM API

Dan argumen ini tidak lolos:

Saya telah membela sisi Anda dari argumen ini selama bertahun-tahun, tetapi saya pikir sekarang ini adalah gesekan yang tidak sepadan. Anda tidak mendapatkan apa-apa darinya. Membiarkan orang menggunakan kelas saja tidak memiliki efek negatif kecuali itu

React selalu menjadi lapisan yang sangat tipis di atas JS. Jadi segala sesuatu yang lain selain kurung sudut JSX adalah JS _and_ memiliki padanan langsung di DOM API untuk hal-hal yang berhubungan langsung dengan DOM: className , clipPath , htmlFor , tabIndex dll. dll dll.

Dengan keputusan untuk memperkenalkan class React berhenti menjadi lapisan tipis ( class adalah kata yang dicadangkan di JS) dan melepaskan diri dari tujuan yang dinyatakan untuk menjadi lebih kompatibel dengan DOM API.

Sangat mengejutkan melihat Anda ingin "Bermigrasi dari onChange ke onInput" karena tidak konsisten dengan DOM _dan_ menjadi tidak konsisten dengan DOM dengan bermigrasi className -> class .

Selain itu, ini membuka sekaleng penuh cacing, karena orang akan menuntut (dan sudah menuntut) perubahan ke bagian lain. Hanya di komentar: mengapa kita menggunakan dataset bukannya data-* ? Mungkin karena data-* bukan JS yang valid (seperti class ) dan karena konsisten dengan DOM API ? Mengapa kita tidak mengubah htmlFor ? Karena for adalah kata yang dicadangkan dan htmlFor ada di DOM API? dll. dll. dll.

Namun jika kita melewati pasangan kunci/nilai yang tidak diketahui itu akan diperlakukan sebagai atribut sejak Bereaksi 16. Jadi kita sudah tidak konsisten.

@gaearon yang juga merupakan alasan mengapa React adalah satu-satunya perpustakaan yang mendapat skor buruk pada tes interop CustomElements Everywhere: https://custom-elements-everywhere.com/
Dan ada banyak masalah yang meminta untuk mengubahnya: https://github.com/facebook/react/issues/11347 , https://github.com/facebook/react/issues/7249 , https://github.com/facebook /reaksi/masalah/9230

Ini mungkin bukan masalah, tetapi apakah kesamaan React Fire dengan React Fiber akan membingungkan bagi penutur bahasa Inggris non-pribumi? Saya sering berpikir bahwa Stasiun Newark Penn dan Stasiun Penn New York berada di jalur kereta yang sama di sini di NYC adalah lelucon yang sangat kejam bagi turis.

Jika itu benar-benar mengkhawatirkan, Anda bisa menyebutnya React Flame dan tetap menyalakan emoji.

Akan menulis ulang delegasi acara membuka pintu untuk memperbaiki #1254; di mana beberapa peristiwa menurunkan kinerja untuk simpul yang dilampirkan (yang untuk React berarti seluruh aplikasi).

Memperbaiki #1254 dalam beberapa bentuk jelas merupakan sesuatu yang ingin saya lihat.

Juga, sebagai jangka panjang, apakah Anda mempertimbangkan untuk memiliki alat peraga dataSet sintetis?

Saya tidak ingin berkomitmen untuk sesuatu seperti ini sekarang karena ada permukaan yang lebih besar. Antarmuka yang lebih kaya untuk DOM ( ariaSet , dataSet , classList ) masuk akal tetapi tidak jelas berapa banyak yang ingin kami investasikan di React DOM, versus perpustakaan tingkat yang lebih tinggi yang memberi Anda DOM API yang lebih kaya. Karena perubahan ini lebih bersifat kosmetik tetapi memiliki luas permukaan yang tinggi, saya akan menundanya.

React Blazing

@ryanflorence Agak aneh tapi agak menyedihkan bahwa tidak ada seorang pun (sejauh yang saya tahu) memiliki ide untuk membuat html/css/svg -> jsx transfomer untuk memudahkan migrasi ke Bereaksi dengan begitu banyak perubahan sepele untuk memetakan HTML attrs ke React props. Begitu banyak jam kerja yang terbuang untuk melakukan sebagian besar cari-dan-ganti :(

@jxub
https://transform.now.sh/html-to-jsx/

Sangat bersemangat untuk perubahan baru, Anda manusia dari Facebook membuat sejarah dengan migrasi ini. 50k komponen akan dimigrasikan ke React Fire ?
Suite pengujian Anda harus sangat ketat <3

apakah kesamaan React Fire dengan React Fibre akan membingungkan bagi yang bukan penutur asli bahasa Inggris?

mungkin juga untuk orang yang mengalami gangguan pendengaran (atau mereka yang memiliki kondisi lain yang memengaruhi diskriminasi kata)

Terima kasih telah berbagi @gaearon , itu amasing!

Saya ingin melihat rilis JSX 2.0 memecahkan masalah spasi dan baris baru yang terjadi saat kami mengkompilasi kode kami dengan Babel dan TypeScript.

Ada masalah berbeda yang dibuka dan saya mencoba untuk berkontribusi tetapi diberitahu karena tim React perlu meninjau segala sesuatu di sekitar JSX.

Masalah ini berkaitan dengan dom, karena cara kami menerjemahkan jsx ke js tidak memungkinkan apa yang dikatakan w3c.

Ini masalahnya https://github.com/facebook/jsx/issues/19

Komentar saya ada di bagian paling akhir.

Saya pikir, className tidak apa-apa. Biarlah apa adanya. Jangan menambahkan penghinaan pada cedera.

Adakah yang bisa menjelaskan bagaimana ini memengaruhi penangan yang ada?

Berhenti mencerminkan nilai input dalam atribut nilai

Akankah React masih memiliki input terkontrol dengan pembaruan event.target.value yang akurat di penangan, atau apakah ini hanya memengaruhi nilai pembacaan dari referensi dan Node DOM?

@nickmccurdy itu memengaruhi apa yang Anda lihat di browser devtools

@tomdale React Ember

Bagus! Saya menunggu untuk melihat daftar lengkap perubahan di React 17.
Saya percaya ini akan menjadi era baru ReactJS. ️

@tomdale Hmm: Benang, Serat, Kain; mungkin istilah lain yang berhubungan dengan pakaian bisa digunakan? 😆.

Namun jika kita melewati pasangan kunci/nilai yang tidak diketahui itu akan diperlakukan sebagai atribut sejak Bereaksi 16. Jadi kita sudah tidak konsisten.

@gaearon yang juga merupakan alasan mengapa React adalah satu-satunya perpustakaan yang mendapat skor buruk pada tes interop CustomElements Everywhere: https://custom-elements-everywhere.com/

Tidak, bukan itu alasannya (elemen khusus dan normal adalah jalur kode yang sepenuhnya terpisah). Alasannya adalah kami sudah memiliki perilaku lama dan tidak ingin mundur ke belakang kecuali jika perilaku baru itu solid. Saya pikir masuk akal untuk menangani interop elemen kustom yang lebih baik sebagai bagian dari payung ini.

apakah kesamaan React Fire dengan React Fibre akan membingungkan bagi yang bukan penutur asli bahasa Inggris?

Keduanya adalah nama kode internal dan tidak terlalu penting setelah proyek selesai. React Fire hanyalah upaya untuk membuat React DOM lebih baik — dan pada saat siap produksi, React DOM hanya akan menjadi React DOM.

Akankah React masih memiliki input terkontrol dengan pembaruan event.target.value yang akurat di penangan, atau apakah ini hanya memengaruhi nilai pembacaan dari referensi dan DOM Node?

Ya, karena event.target.value adalah properti . Kita berbicara tentang berhenti memperbarui atribut . Yang tidak dilakukan perpustakaan populer lainnya (AFAIK) dan yang menyebabkan banyak masalah. Seharusnya tidak memengaruhi kode Anda kecuali Anda mengandalkan pemilih CSS pada nilainya (yang mungkin buruk ).

Bagus! Saya menunggu untuk melihat daftar lengkap perubahan di React 17.

Perhatikan bahwa kami tidak berkomitmen untuk ini siap pada 17. Mungkin 18. Atau 19.

Sangat menyenangkan melihat perkembangan yang stabil di perpustakaan yang bagus seperti React. class akan membuat kegunaan jauh lebih baik, it's worth it imo

@gaearon

elemen kustom dan normal adalah jalur kode yang sepenuhnya terpisah

Itu sendiri sepertinya sesuatu yang harus diperbaiki juga. Apakah ada alasan untuk tidak memperlakukan semua elemen dengan sama? Itulah maksud dari spesifikasi HTML dan DOM.

@justinfagnani Seperti yang telah dibahas sebelumnya, alasan kami tidak melakukannya saat itu adalah karena tidak ada konvensi tentang cara menentukan apakah akan menetapkan properti atau atribut — dan ada risiko bahwa dengan menggunakan cek kami berisiko membuatnya tidak mungkin bagi platform web untuk menambahkan properti baru ke prototipe. Saya pikir sekarang sudah ada semacam konsensus di RFC dan PR yang sedang dikerjakan @robdodson , dan kita mungkin bisa mengambilnya dari sana.

👍

React Fire juga memungkinkan kita untuk menerapkan beberapa pengoptimalan kinerja cerdas yang dimiliki Inferno – tetapi belum dapat diterapkan karena melanggar perubahan. Saat-saat yang menyenangkan :)

LGTM

Terkait dengan rename className -> class yang diusulkan: Saya ingin properti classes yang menggunakan array string. Itu akan menyelamatkan saya dari banyak manipulasi string (atau penggunaan classnames ) di komponen saya.

Saya pikir satu-satunya kelemahan dari prop classes adalah bahwa array yang berisi string yang sama dalam urutan yang sama akan menyebabkan rendering ulang dalam komponen murni, sedangkan string dari kelas CSS yang sama tidak. Jujur saja, sepertinya masalah kecil. Saya pikir sebagian besar pengembang Bereaksi sudah mengetahui pengorbanan array & objek dalam alat peraga.

@gaearon punya rencana untuk kompatibilitas ke belakang? Mungkin mengikuti jalur yang sama dengan React Fiber, menambahkan peringatan tentang perubahan dan memberikan waktu untuk pembaruan basis kode besar tanpa kehilangan pembaruan baru.

https://www.youtube.com/watch?v=F1U0qvtQnE8

Mengenai class dan className .

Saya tahu kita tidak akan mendapatkan kesepakatan yang luas tentang hal ini ke mana pun kita pergi. Orang-orang memiliki pendapat yang sangat kuat tentang yang satu ini. Saya ingin berbagi bagaimana saya memikirkannya, dengan harapan dapat membantu.

API Komponen Seharusnya Terasa Idiomatik

Ada argumen umum bahwa Bereaksi "cocok dengan JavaScript" dan karenanya className lebih disukai. Saya pikir pernyataan ini disalahpahami secara halus, jadi saya ingin sedikit fokus padanya.

Di React, pertama dan terpenting, kami peduli bahwa menggunakan komponen React harus terasa seperti JavaScript idiomatik . Ini berarti bahwa jika saya menggunakan komponen hipotetis <Table> , saya berharap props-nya adalah camelCase:

<Table
  rowHeight={10}
  headerBorderInset={5}
  renderRow={this.renderRow}
/>

Saya tidak berharap melihat nama prop seperti row_height atau row-height di API publik komponen . Alat peraga komponen adalah objek (seperti "tas pilihan"), dan kami biasanya mengharapkan opsi tersebut menjadi camelCase . Ini mungkin tidak selalu idiomatis di DOM, tetapi DOM tidak terlalu konsisten di banyak tempat. Bereaksi selaras dengan ekosistem JavaScript yang sangat banyak menggunakan camelCase .

Tapi bagaimana dengan DOMnya? Di sinilah ia menjadi berduri.

Properti DOM Bukan Hanya "Atribut di JS"

Di DOM, kami memiliki atribut dan properti. Atribut adalah hal-hal yang biasanya Anda lihat di HTML. Properti adalah hal-hal yang biasanya Anda atur dari JS. Tapi yang terpenting, DOM API ada baik untuk menyetel properti maupun untuk menyetel atribut — dan mereka bahkan tidak selalu menyetel hal yang sama.

node.value = 10; // setting a property
node.setAttribute('value', '10'); // setting an attribute

Dalam banyak kasus itu tidak masalah. Dalam beberapa kasus memang demikian. Tapi mungkin tidak seperti yang orang pikirkan saat menggunakan React (yang memiliki satu abstraksi atas keduanya).

Bereaksi Bukan Hanya Mengatur Properti

Kesalahpahaman yang umum adalah karena React saat ini menggunakan konvensi camelCase untuk sebagian besar props DOM, itu berarti React sedang mengatur properti DOM. Ini salah.

Faktanya, React saat ini menggunakan atribut untuk hampir semua props yang didukungnya. Dalam beberapa kasus, seperti value , ini menyebabkan masalah (yang seperti yang saya diskusikan, kami ingin kembalikan). Dalam kasus lain, ini sebenarnya bagus — karena kita tidak harus menyertakan daftar properti yang didukung ke dalam bundel React. Menggunakan atribut di bawah tenda adalah apa yang memungkinkan pengurangan ukuran besar di React 16.

Maksud saya di sini adalah apakah React menggunakan properti atau atribut secara internal adalah detail implementasi — dan tidak ada hubungannya dengan apakah elemen DOM React _API_ harus menggunakan nama properti, nama atribut, atau bahkan beberapa nama lain yang masuk akal.

Tetap, Mari Kita Gunakan Nama Properti saja?

Oke, properti dan atribut adalah detail implementasi. Tetapi mengapa tidak menstandarisasikan penggunaan nama properti DOM saja karena itu dibuat khusus "untuk JavaScript"? Bukankah itu bagaimana React API dirancang hari ini?

Yah, tidak cukup. Hanya satu dari props yang disebutkan di bawah ini yang sesuai dengan properti objek DOM yang sebenarnya:

<div
  tabIndex={1}
  data-id="123"
  aria-live="polite"
  nopin="nopin"
  itemType="http://schema.org/Movie"
  onClick={function() { alert('hi') }}
/>

Ironisnya, satu-satunya prop di atas yang memiliki properti DOM aktual dengan nama yang sama yang sesuai dengannya ( tabIndex jika Anda tidak yakin) sebenarnya disetel oleh React sebagai atribut!

Jadi pada titik ini Anda mungkin melihatnya tidak jelas dan tidak konsisten. Dalam beberapa kasus properti tidak ada (seperti untuk kustom, atribut non-standar), dalam beberapa kasus React dapat menyediakan API yang lebih kaya ( data- vs dataSet ) tetapi saat ini tidak.

Dalam beberapa kasus, React sengaja memilih untuk menyimpang ( onClick di properti React vs onclick DOM) karena lebih masuk akal untuk komponen React kustom. Ini karena komponen React sering kali mengekspos event handler yang lebih kompleks seperti onItemClick . Akan sangat tidak konsisten jika Anda menulis <Button onclick> tetapi <Table onItemClick> . Dan <Table onitemclick> bukan camelCase, yang ingin kami hindari di API komponen.

Di atas, saya menjelaskan bahwa React sudah tidak konsisten tentang "selalu menggunakan nama properti DOM", bahwa React bahkan tidak benar-benar menggunakan properti secara internal (sehingga aturan praktisnya juga tidak menjelaskan mekanisme sebenarnya), dan dalam banyak hal kasus properti DOM sama sekali tidak ada jadi kami harus tetap mengizinkan nama atribut.

Kalau Bukan Nama Properti, Mari Konsisten dan Gunakan Nama Atribut?

Jadi mengapa tidak menggunakan nama atribut saja ? Ini bisa masuk akal. Tapi sekarang kita bertemu dengan pertimbangan pertama yang kita kemukakan. Menggunakan komponen React akan terasa seperti idiomatic JavaScript . Namun seringkali komponen meneruskan setidaknya beberapa props ke elemen DOM yang mendasarinya.

<Button
  borderColor='red'
  tabIndex={1}
 />

 // renders...

 <button
   tabIndex={1}
/>

Akan canggung jika Button kustom menerima properti dengan kapitalisasi yang tidak konsisten:

<Button
  borderColor='red'
  tabindex={1}
 />

Ini memaksa konsumen untuk selalu mengingat jika penyangga tertentu adalah penyangga DOM yang sebenarnya, atau hanya bagian dari kontrak komponen. Bahkan perbedaan itu kabur — komponen dapat memilih untuk melewati prop tertentu terlebih dahulu, tetapi kemudian benar-benar mulai menggunakannya untuk beberapa logika tambahan. Di mana Anda meletakkan batas antara "alat peraga DOM" dan "alat peraga lainnya"?

Saya pikir ini adalah alasan utama mengapa props seperti tabIndex , cellSpacing diinginkan, dan sebagian besar props terkait DOM lainnya untuk mengikuti konvensi camelCase. Itu karena mereka sering berakhir di API komponen.

Kami ingin memudahkan komponen khusus seperti Button untuk membungkus dan meneruskannya tanpa "menerjemahkan" mereka ke nama atribut pada titik di mana mereka mengalir ke DOM, dan tanpa memasukkan props non-camelCase ke dalam API komponen khusus.

Ini juga menjelaskan mengapa alat peraga seperti data-* , aria-* , dan atribut khusus adalah pengecualian yang masuk akal (meskipun kami dapat membuat API yang lebih kaya untuk mereka). Mereka jarang diteruskan ke komponen khusus. Biasanya, mereka terlalu digabungkan ke DOM untuk berguna dalam komponen khusus — dan sebagai gantinya, mereka menjadi detail implementasi dari sesuatu seperti <Modal> atau <Button> dengan API camelCase yang lebih kaya.

Properti Bereaksi Sudah Tidak Cocok dengan Properti DOM

Jika konvensi "nama properti DOM" tidak berhasil, kami memerlukan sesuatu yang lain. Apa itu? Mungkinkah "versi camelCase dari nama atribut"? Sepertinya ini hampir selalu sudah selesai.

Jika ini terdengar terlalu radikal, pertimbangkan bahwa kita sudah melakukan ini. Kami mendukung sesuatu yang disebut srcSet . Tetapi nama properti DOM untuknya adalah srcset . Kami memiliki autoCapitalize tetapi properti DOM disebut autocapitalize . Kami memiliki autoFocus tetapi properti DOM adalah autofocus .

Kami sudah menyimpang dari nama properti DOM ketika mereka tidak cocok dengan konvensi JavaScript camelCase. Yang membawa kita ke class .

Akhirnya: className vs class

Bagian dari pembenaran awal untuk membuatnya className adalah karena React sedang menyetel properti DOM, dan className adalah nama properti DOM.

Namun, seperti yang saya jelaskan di atas, React tidak menggunakan properti lagi kecuali tiga atau empat kasus khusus. Lebih penting lagi, React bahkan tidak secara konsisten menggunakan nama properti DOM — melainkan, menggunakan nama yang akan terlihat alami saat digunakan dari JavaScript, terlepas dari inkonsistensi penamaan internal baik dalam atribut DOM maupun nama properti. Dan itu karena React paling peduli tentang menjaga nama prop untuk komponen kustom terasa "JavaScripty". Dalam hal ini, tabindex bukan "JavaScripty" — tetapi class dan className keduanya .

Argumen lain terhadap class sejak awal adalah bahwa kode seperti ini bukan ES3 yang valid (relevan untuk IE8):

// Not valid in ES3
// Valid in ES5
var props = { class: 'foo' };

Tapi kebanyakan tidak menulis ES3 lagi. Entah Anda menggunakan toolchain seperti Babel atau Anda mungkin menargetkan IE9+ — React bahkan tidak mendukung IE8 sekarang.

Jadi satu-satunya ketidaknyamanan yang tersisa dengan class adalah Anda tidak dapat menulis ini:

// Not valid at all :-(
const class = props.class;
const { class } = props;

Tapi saya pikir seiring berjalannya waktu, argumen ini tidak cukup kuat dengan sendirinya. React tidak memaksa Anda untuk menggunakan destructuring atau menggunakan nama variabel khusus ini, dan menulis sesuatu seperti

// Valid
const {class: cls} = foo;
const cls = props.class;

bukankah itu lebih banyak usaha.

Biasanya orang menurunkan class jauh lebih sering daripada membacanya karena banyak komponen berisi lebih dari satu <div> atau elemen host lainnya. Jadi Anda akhirnya menulis <div className> lebih sering daripada ingin merusak class . Dan dengan demikian perubahan ke class akan menghemat lebih banyak pengetikan keyboard daripada yang akan diperkenalkan.

Ada poin penting lainnya di sini.

Melewati class melalui banyak level bukanlah pola yang bagus dengan sendirinya. Ini diperlukan untuk perpustakaan, tetapi dalam kode aplikasi sering mengarah ke komponen yang rapuh. Yang gayanya rusak sepanjang waktu karena ada seratus situs panggilan berbeda yang masing-masing menambahkan kelas yang berbeda, menyebabkan bug kaskade. Jadi tidak jelas betapa berharganya mendorong perusakan class sejak awal. Saya pikir tidak apa-apa Anda perlu menulis satu baris kode lagi untuk membacanya dari props (atau Anda bisa menggunakan props.class dan tidak memikirkannya).

Jika Anda menulis sebuah komponen yang sangat dekat dengan DOM (dan dengan demikian masuk akal untuk menggunakan class sebagai prop), Anda mungkin ingin meneruskan props lain juga. Jadi, Anda dapat menggunakan sintaks istirahat dalam destrukturisasi:

// Valid in ES2018

function Button({ color, ...rest }) {
  const buttonClass = rest.class +  ' Button-' + color;
  return <button {...rest} class={buttonClass} />
}

Dan jika Anda tidak perlu mengubahnya, Anda bisa meneruskan {...rest} bahkan tanpa membaca class darinya. Jadi batasan destrukturisasi dapat membantu mendorong desain komponen yang lebih baik.

Mengapa tidak keduanya?

Akhirnya, tidak bisakah kita mendukung class dan className ? Di satu sisi, kami sudah melakukannya, tetapi React meneriaki Anda untuk itu dengan peringatan. Ada alasan untuk ini.

Jika kami mendukung keduanya tanpa peringatan, maka komunitas akan terpecah mana yang akan digunakan. Setiap komponen pada npm yang menerima prop kelas harus ingat untuk meneruskan keduanya. Jika satu komponen di tengah tidak bermain bersama dan hanya mengimplementasikan satu prop, kelas akan hilang — atau Anda berisiko berakhir dengan class dan className di bagian bawah "tidak setuju" dengan masing-masing lainnya, tanpa ada cara bagi React untuk menyelesaikan konflik tersebut. Jadi kami pikir itu akan lebih buruk daripada status quo, dan ingin menghindari ini.

Ringkasan

Jika React adalah open source hari ini, sepertinya pro dari mengizinkan class (secara konseptual lebih dekat dengan apa yang diharapkan kebanyakan orang, lebih sedikit mengetik untuk prop yang paling umum digunakan) lebih besar daripada kerugiannya (sedikit lebih banyak mengetik untuk mencegatnya — di kasus mana Anda mungkin hanya menginginkan operator spread).

Apa yang dulu kami lihat sebagai kerugian (tidak konsisten dengan properti DOM) diperdebatkan karena kami tidak menetapkan properti DOM lagi, atau bahkan berusaha untuk konsisten dengannya. Alih-alih, kami bertujuan untuk memiliki API berbasis atribut tetapi camelCase di sisi konsumsi komponen React — yang hampir konsisten kami lakukan. Dan class="Button" jelas lebih nyaman daripada className="Button" . Faktanya, jika DOM API dirancang hari ini, Anda mungkin dapat menetapkan properti .class secara tepat karena pembatasan penggunaan class dalam tugas seperti ini telah dicabut di ES5 — hampir sepuluh tahun yang lalu.

Satu-satunya kelemahan besar yang tersisa adalah biaya migrasi. Kami akan menilai ini dengan hati-hati. Tetapi jika kita tetap melakukan banyak perubahan, kita mungkin dapat membuat yang ini juga dan memperbaikinya untuk selamanya. Kami tidak menganggap enteng hal ini dan kami mempertimbangkan semua kekhawatiran Anda.

Catatan: ini mungkin masuk akal untuk dilakukan untuk nama prop React lainnya yang tidak cocok dengan nama atribut camelCased.

@renatoagds

memiliki rencana untuk kompatibilitas ke belakang? Mungkin mengikuti jalur yang sama dengan React Fiber, menambahkan peringatan tentang perubahan dan memberikan waktu untuk pembaruan basis kode yang besar.

Seperti yang saya catat:

Dan kami memiliki lebih dari 50 ribu komponen di Facebook agar kami tetap jujur ​​tentang strategi migrasi kami. Kami tidak dapat menulis ulang kode produk kecuali beberapa perbaikan yang ditargetkan atau codemod otomatis.

Jadi kami pasti akan mencoba membuat strategi migrasi semulus mungkin, seperti yang selalu kami lakukan. Jika tidak mulus kita tidak akan bisa melakukan perubahan sendiri.

re: className -> class, saya tenang dengan keputusan apa pun, saya pasti dapat melihat pengecualian untuk mengubah kelas untuk pengguna baru, dan manfaat sampingan dari baris kode yang lebih pendek. Meskipun demikian, mereka masih perlu belajar tentang nama camelCase lainnya.

Jadi satu-satunya ketidaknyamanan yang tersisa dengan kelas adalah Anda tidak dapat menulis ini:

const { class } = props;

Tapi saya pikir seiring berjalannya waktu, argumen ini tidak cukup kuat dengan sendirinya. Bereaksi tidak memaksa Anda untuk menggunakan > merusak, dan menulis

const class = props.class;

bukankah itu lebih banyak usaha.

Dua hal (mungkin kecil):

1. Bukankah JavaScript const class = props.class tidak valid? Saya tidak berpikir demikian, dan dalam pengujian cepat Chrome tidak menyukainya. Juga, artikel ini menunjukkan bahwa itu tidak valid.

2. Saya dapat melihat perubahan ini sebagai area frustrasi (sekali lagi, berpotensi kecil) bagi orang-orang yang menulis komponen seperti ini: nvm (lihat Pembaruan di bawah)

const { oneProp, twoProp, className, ...rest }  = this.props;

// do stuff with oneProp, twoProp, className

return (
  <div
    someProp={prop}
    anotherProp={anotherProp}
    className={someClassName}
    {...rest}/>
);

Setelah perubahan ini, ini perlu menjadi sesuatu seperti ...

const { oneProp, twoProp, ...rest }  = this.props;

// do stuff with oneProp, twoProp, this.props.className

return (
  <div
    someProp={prop}
    anotherProp={anotherProp}
    {...rest}
    class={someClassName}/>
);

Bukan tidak mungkin untuk mengatasi perubahan ini, tetapi sedikit lebih banyak yang perlu diingat ketika menulis dan membaca komponen dalam gaya ini.

Perbarui :

Sudahlah,

const { class: className } = this.props;

melakukan trik.

Satu-satunya kelemahan besar yang tersisa adalah biaya migrasi. Kami akan menilai ini dengan hati-hati. Tetapi jika kita tetap melakukan banyak perubahan, kita mungkin dapat membuat yang ini juga dan memperbaikinya untuk selamanya. Kami tidak menganggap enteng hal ini dan kami mempertimbangkan semua kekhawatiran Anda.

Untungnya ini mudah dikurangi jika seseorang menggunakan pendekatan CSS-in-JS, seperti Estetika. Terima kasih atas tulisan yang luar biasa!

Tip acak mengenai nama atribut, saya menemukan proyek yang luar biasa, svg2jsx sangat bagus untuk mengonversi SVG besar untuk digunakan di Bereaksi!

@jamesplease Maaf, pikiranku kosong — kamu benar. Diedit.

@jamesplease Anda benar. Itu juga sering muncul saat bekerja dengan JSON, untuk nilai default, sangat mengganggu!

const { default: defaultVal } = property

Saat Anda mengubah sistem acara, akan sangat menyenangkan untuk melihat sesuatu yang mirip dengan fungsi linkEvent Inferno sehingga kami dapat melakukan penanganan acara menggunakan alat peraga dalam komponen fungsional tanpa harus membuat fungsi anonim setiap render.

className -> class akan menjadi perubahan besar bagi ekosistem, banyak komponen yang tidak dirawat akan menjadi tidak kompatibel, dan tidak ada yang dapat Anda lakukan jika Anda tidak dapat menambalnya. Mungkin memiliki beberapa pembungkus seperti StrictMode yang menonaktifkan perubahan ini untuk komponen yang lebih dalam di pohon untuk menyediakan jalur migrasi bertahap?

Saya dapat melihat perubahan ini sebagai area frustrasi (sekali lagi, berpotensi kecil) bagi orang-orang yang menulis komponen seperti ini:

const { oneProp, twoProp, className, ...rest }  = this.props;

// do stuff with oneProp, twoProp, className

return (
 <div className={someClassName} {...rest}/>
);

Hanya saja, jangan merusaknya.

const { oneProp, twoProp, ...rest }  = this.props;

return (
  <div
    {...rest}
    class={'something ' + rest.class}
  />
);

@gaearon

apakah React menggunakan properti atau atribut secara internal adalah detail implementasi

Itu sepertinya masalah juga, jujur. Elemen DOM dapat dan memang berperilaku berbeda dalam beberapa kasus tergantung pada apakah Anda menyetel atribut atau properti. React tidak mungkin mengetahui semua perbedaannya, tetapi pengguna elemen dapat mengetahui tentang elemen yang mereka gunakan. Kontrol eksplisit atas properti, atribut, dan peristiwa akan memungkinkan penulis keluar dari situasi ini.

@justinfagnani Jika Anda memiliki hal-hal tertentu yang Anda ingin kami ubah, apakah Anda keberatan mengajukan masalah terpisah dengan API yang Anda sarankan? Ini terdengar sedikit di luar cakupan masalah ini.

@sompilasar

className -> class akan menjadi perubahan besar bagi ekosistem, banyak komponen yang tidak dirawat akan menjadi tidak kompatibel, dan tidak akan ada yang dapat Anda lakukan jika Anda tidak dapat menambalnya. Mungkin memiliki beberapa pembungkus seperti StrictMode yang menonaktifkan perubahan ini untuk komponen yang lebih dalam di pohon untuk menyediakan jalur migrasi bertahap?

Saya setuju — dan kami masih menimbang pro dan kontra. Tidak ada yang diselesaikan.

Namun dalam praktiknya, masalah komponen yang tidak dirawat bukanlah hal baru — masalah ini muncul setiap rilis mayor React karena ada sesuatu yang berubah di jurusan menurut definisi (jika tidak, kami tidak dapat melanjutkan, dan kami tidak memiliki kemewahan untuk menyimpan semua kode lama di dalamnya. bundel selamanya tidak seperti di misalnya lingkungan server). Masalah yang sama muncul ketika PropTypes dipindahkan ke paket terpisah, dan akan terjadi lagi dengan penggantian nama siklus hidup UNSAFE_ . Paket yang tidak dirawat akan di-fork atau ditambal. Kami menyadari ini adalah waktu yang terbuang, dan inilah mengapa kami menghindari melakukan lebih dari satu jurusan besar dalam setahun. Untuk orang-orang yang tidak mampu membantu, biasanya menunggu beberapa bulan sebelum pindah ke jurusan baru adalah strategi terbaik karena pengadopsi awal membuka jalan dan menghidupkan kembali paket yang ditinggalkan. Kemudian kita bergerak maju bersama-sama.

Sekali lagi — saya sangat memahami keraguan Anda, tetapi ini pada dasarnya tidak berbeda dari perubahan besar lainnya yang terjadi di masa lalu, atau yang mungkin terjadi di masa depan. Seperti biasa, kami akan melakukan banyak upaya dan penekanan pada skrip otomatis yang dapat Anda jalankan untuk mengonversi sebagian besar basis kode Anda, dan Anda juga dapat menjalankan paket lain (dan mengirim PR ke mereka — atau fork mereka dalam keadaan terakhirnya ).

Terlepas dari keputusan Anda, satu argumen lagi yang menentang class adalah kemampuan untuk ditelusuri. Berapa banyak positif palsu yang akan memberi Anda pencarian dengan class ketika Anda ingin menemukan komponen yang menggunakan kelas CSS dalam kode ES6 yang menggunakan komponen kelas JS? Ya, Anda dapat mencari class={ , tetapi bagaimana dengan destrukturisasi props di JSX yang dibuat sebagai objek di JS? (Saya menentang penggunaan alat peraga yang merusak tetapi mereka masih digunakan) Tentu saja, kita membutuhkan alat pencarian berbasis AST yang lebih sadar konteks dalam editor kode, tetapi untuk saat ini kita hanya memiliki teks dan regexp. Tentu saja sistem tipe dapat membantu melacak objek yang lewat, tetapi populasi besar belum mengadopsinya.

Sesuatu tentang menggunakan kata yang dicadangkan tidak cocok dengan saya, bahkan jika itu tidak menyebabkan masalah apa pun sekarang ; dapatkah kita mengatakan dengan pasti bahwa rest.class (misalnya) tidak akan signifikan bagi bahasa dalam x tahun?

@GeordieP Jika bekerja hari ini tidak bisa rusak besok. Itulah prinsip inti bagaimana JavaScript berkembang, dan alasan dari banyak keistimewaannya.

@gaearon Cukup adil, kalau begitu. Jika itu adalah kemenangan yang cukup besar, saya katakan lakukanlah.

@sompylasar Saya biasanya mencari className= atau className: , sepertinya keduanya akan bekerja dengan class juga.

Tolong singkirkan className , dan demi Tuhan, htmlFor . Saya bukan pengembang DOM, biasanya ada yang sangat sangat salah jika saya harus mengakses metode DOM asli. Tantangan terbesar yang saya miliki untuk mengarahkan orang ke React adalah abstraksi yang dibuat JSX atas DOM dan atribut HTML penggantinya yang aneh. Semuanya sedang diubah, tidak ada alasan untuk khawatir tentang kata-kata yang dicadangkan pada saat ini. IMO.

Tidak yakin ini menambahkan apa pun ke diskusi yang ada, tetapi sepertinya harus ada alasan yang lebih baik untuk mengubah className .

Apakah menyelamatkan pelajar Bereaksi pemula dari nama yang sedikit tidak intuitif layak untuk setiap orang yang harus memperbarui proyek & perilaku mereka?

Sebagai seseorang yang menggunakan de-strukturisasi secara bebas, harus mengingat pengecualian baru pada aturan ini mungkin merupakan gangguan mental yang lebih besar daripada kesempatan langka yang saya tulis class alih-alih className .

Juga, bukankah pemula masih akan bingung dengan banyaknya materi (seperti blog/repos/dll) yang menggunakan className saat ini?

Akhirnya, seperti yang dikatakan @sompylasar , ini merusak kemampuan pencarian dalam basis kode saya.

Mungkin ini adalah argumen tipe tab vs spasi, tetapi saya tidak sepenuhnya mengerti mengapa perubahan ini diperlukan. Sepertinya biaya besar untuk keuntungan kecil kecuali ini adalah bagian dari perubahan yang lebih besar dalam cara Anda ingin memodelkan API dari waktu ke waktu. Yang mengatakan, saya pasti akan menggunakan apa pun yang Anda putuskan .

Sedikit berlebihan tetapi agak menyedihkan bahwa tidak seorang pun (sejauh yang saya tahu) memiliki ide untuk membuat html/css/svg -> jsx transfomer untuk memudahkan migrasi ke Bereaksi dengan begitu banyak perubahan sepele untuk memetakan atribut HTML ke Bereaksi alat peraga.

@jxub - Saya membuat konverter HTML ke JSX sebagai bagian dari cara hackathon pada tahun 2014: https://magic.reactjs.net/htmltojsx.htm. Saya tidak yakin apakah itu menangani SVG dengan baik. Proyek hackathon adalah membuat skrip yang akan "ajaxify" situs HTML biasa dengan menggunakan React (https://github.com/reactjs/react-magic) dan bagian dari itu mengharuskan saya membangun cara untuk membuat komponen React dari sepotong HTML, jadi saya merilis bagian HTML ke JSX sebagai halaman mandiri yang terpisah.

Kami masih peduli untuk mendukung IE11 tetapi ada kemungkinan bahwa kami tidak akan mencoba memuluskan beberapa perbedaan browser yang ada — yang merupakan sikap yang diambil oleh banyak perpustakaan UI modern.

@gaearon - Apa saja contoh perpustakaan UI modern yang tidak memuluskan perbedaan browser? Bagi saya, itulah salah satu alasan utama menggunakan perpustakaan.

Teori konspirasi: seluruh className / berita kelas ini adalah satu hal kontroversial yang cerah yang akan segera diperhatikan dan diperdebatkan semua orang. Entah itu untuk menarik perhatian proyek pengerjaan ulang secara keseluruhan, atau mengalihkan perhatian dari sesuatu yang lebih besar yang terjadi di bayang-bayang, atau memberikan satu hal yang nantinya bisa ditarik kembali sementara sisanya akan diterima, seperti dalam anekdot berikut:

Seniman teater besar Tyshler, membuat sketsa pemandangan, di sudut menggambar seekor anjing hijau kecil. Dan ketika salah satu panitia penerimaan bertanya: "Saya suka semuanya, tetapi di mana anjing ini?", Artis dengan desahan penyesalan menempel padanya.

Alasan sebenarnya di balik perubahan ini tidak jelas, tetapi mereka telah meroketkan popularitas proyek peningkatan baru ini dan komunitas ramai di sekitar React.

Alangkah baiknya jika mendukung Passive Event Listeners berada dalam lingkup React Fire, yang merupakan fitur penting di ponsel.

6436

Terima kasih atas semua kerja keras Anda dalam hal ini, tetapi harap pertimbangkan kembali className -> class .

Kami semua pernah menjadi pemula React dan className tidak menghalangi kami untuk belajar dan mencintai React.

Saya ingat ketika saya menggunakan vue dengan jsx, mereka sudah memiliki class bukan className , saya tidak setuju jika className akan diubah menjadi class , karena React adalah pelopor dalam Virtual DOM , dan mewakili DOM itu sendiri.

Lampirkan acara di root React daripada di dokumen

@gaearon Apakah ini berarti bahwa dalam lingkungan pengujian saya tidak perlu menambahkan elemen ke dokumen untuk dapat mengirimkan acara browser nyata dan meminta penangan yang terkait dengannya dipanggil? Harus melakukan ini sangat kontra-intuitif dan saya yakin telah menjadi sumber banyak pengembang yang tidak terbiasa dengan internal React menjadi bingung, membuang banyak waktu menulis tes dan menimbulkan simulasi acara dan praktik pengujian yang buruk.

Yang membawa saya ke catatan lain, dapatkah kita melakukan sesuatu tentang react-dom/test-utils ? Saya secara khusus tertarik dengan kemungkinan penghapusan Simulate mengingat semua masalah yang terkait dengannya yang kita semua tahu, dan tentu saja melakukan perubahan yang diperlukan pada react-dom itu sendiri sehingga benar-benar tidak diperlukan lagi. Mungkinkah itu dalam ruang lingkup?

/cc @kentcdodds

Saya menyukai arah dan gambaran besar yang diambil React Fire. Sejauh ini, itu tampak seperti perubahan besar yang harus dilakukan.

Suka perubahan yang paling diumumkan, tapi saya skeptis tentang perubahan className .

React tidak memaksa Anda untuk menggunakan destructuring atau menggunakan nama variabel khusus ini, dan menulis sesuatu seperti (...code snippet...) tidak membutuhkan banyak usaha.

Meskipun tidak banyak usaha untuk menulis, dalam pengalaman saya saat ini, saya berharap akan _way_ lebih sulit untuk dijelaskan kepada pengembang lain (terutama pengembang dari bahasa lain). Di sisi lain selama bertahun-tahun kami menggunakan React di perusahaan kami, saya kira hanya satu atau dua pengembang yang bingung dengan className dan hanya menerima ini sebagai Reacts API untuk menyetel nama kelas dalam beberapa menit.

(Menurut pendapat pribadi saya ketika saya _love_ destructing, sintaks rename terkadang terasa aneh sendiri untuk pemula, karena berbeda dengan rename di import yang terlihat sangat mirip dan dapat dikombinasikan dengan hal-hal seperti nilai default. One _could_ tidak menggunakan destructing kemudian , tapi itu akan menjadi pengecualian _big_ untuk semua kode lain yang saat ini kami tulis di perusahaan kami. Pengalaman dari orang lain Mungkin berbeda tentu saja, tapi itulah pandangan saya tentang masalah ini .)

Bagus

Juga skeptis tentang perubahan className . Ini adalah salah satu perubahan paling kecil dalam skema, tetapi menarik sebagian besar diskusi komentar di sini.

Apakah benar-benar layak menghabiskan modal politik sebanyak itu untuk sebuah perubahan, ketika ada begitu banyak hal bagus lainnya yang diumumkan?

Dari tempat saya berdiri, jika Anda membuat keputusan di mana bagian dari pembenarannya adalah "dan menulis sesuatu seperti... ...bukankah _itu_ lebih banyak usaha.", keputusan itu harus memiliki _masif_ terbalik, dan className -> class perubahan hanya tidak dibandingkan dengan semua hal lain yang telah diumumkan.

ini akan menjadi kemajuan besar pada React Fire

Tentang class v/s className , saya pikir kita harus mengingatkan diri kita sendiri bahwa JSX Bereaksi.

Karena JSX adalah _DSL_ yang dirancang agar terlihat seperti HTML, yang terbaik adalah membuatnya sedekat mungkin dengan HTML. Memang itu disebut className di DOM API, tetapi sebagian besar menggunakan JSX mungkin karena mereka tidak ingin berurusan dengan DOM API secara langsung.

Jika lebih masuk akal untuk React's API untuk sangat cocok dengan DOM API, maka saya harap tidak apa-apa/mungkin untuk melakukan pemetaan dalam transpilasi:
<img src="avatar.png" class="profile" /> → React.createElement("img", { src: "avatar.png", className: "profile" }) .

Akan sangat berharga untuk menjadikan sintaks JSX sebagai superset HTML yang bersih.

Untuk menambah apa yang dikatakan @mhenr18 .

Keadaan saat ini:

• Reaksi tidak konsisten
• API adalah camelCase

Keadaan yang diusulkan:

• Reaksi tidak konsisten
• API adalah camelCase
• className -> class

Manfaat yang dirasakan:

Jika React open source hari ini, sepertinya pro dari mengizinkan kelas (lebih dekat secara konseptual dengan apa yang diharapkan kebanyakan orang, lebih sedikit mengetik untuk prop yang paling umum digunakan) lebih besar daripada kerugiannya (sedikit lebih banyak mengetik untuk mencegatnya — dalam hal ini Anda akan mungkin hanya ingin operator spread saja).

Kerugian sebenarnya:

• seluruh ekosistem yang bergantung pada className berhenti bekerja (usaha peningkatan besar-besaran)
• seluruh kumpulan besar buku, tutorial, contoh, kode, posting, artikel menjadi sedikit tidak valid
• satu-satunya JS valid yang tersisa adalah pengetikan tambahan : const {class: cls} = props . Setiap kasus penggunaan lain yang mungkin dalam JS biasa menjadi tidak valid
• React API tetap tidak konsisten, dan mematahkan asumsi lebih lanjut (mengapa htmlFor bukan for dll.)

Jika saya adalah seorang manajer produk, reaksi langsung saya terhadap perubahan tersebut adalah: wat?

@gaearon Anda mungkin sudah mempertimbangkan ini, harap beri tag PR dengan "React Fire" atau kata kunci serupa.

Masalah biasanya ditandai dengan benar, PR terkadang tidak memilikinya. Ini membantu kontributor potensial.
Ini berasal dari pengalaman saya ketika saya mencoba membaca riwayat git mencari komit terkait React Fiber dan React Reconciler selama seluruh pengembangan Fiber. Ini membantu kita yang mencoba mencari tahu apa yang terjadi dan melihat apakah kita dapat berkontribusi dalam beberapa cara.

Saya juga berpikir mengganti nama className menjadi class akan menyebabkan upaya migrasi yang besar dan masalah bagi pengembang baru.
Atribut className sangat terlihat dan banyak digunakan sehingga benar-benar akan merusak semua perpustakaan yang mengandalkan reaksi.
Dan ini tidak cukup, sebagian besar tutorial akan rusak. Salin & tempel perangkat baru dari sebuah artikel akan bertanya-tanya "mengapa itu tidak berfungsi, dikatakan className bukan prop yang valid".
Jadi senior harus membantu dan kami belum mendapatkan apa-apa, karena kami masih harus menjelaskan mengapa itu tidak berjalan seperti yang Anda harapkan.
Dan sebenarnya, menjelaskan bahwa Anda harus menggunakan className untuk mendefinisikan kelas pada komponen membutuhkan waktu kurang dari satu menit dan mudah dimengerti. Menjelaskan mengapa mereka berubah dari className menjadi class ke setiap pengembang membutuhkan waktu lebih lama dan menghasilkan lebih banyak frustrasi.

Semua upaya diperlukan untuk satu kata.
Itu tidak akan mengubah apa pun dalam cara bereaksi berperilaku.
Itu tidak akan mendorong perkembangan reaksi-dom.
Itu tidak akan meningkatkan produktivitas pengembang yang bekerja lebih dari seminggu dengan reaksi.
Itu hanya akan menghancurkan segalanya.

Tolong pikirkan tentang itu, apakah itu benar-benar layak?

Saya telah menggunakan babel-plugin-react-html-attrs selama bertahun-tahun dan itu telah membantu saya dengan baik, saya tidak berpikir mengganti nama className menjadi class adalah ide yang bagus. Lebih baik dicapai dengan plugin seperti yang saya sebutkan.

Bukankah ada plugin Babel untuk menangani seluruh situasi “ class v className “ / “ for v htmlFor “?

Saya harap mungkin untuk mendukung atribut html apa adanya sambil mempertahankan kompatibilitas mundur dengan keputusan penamaan yang sudah dibuat.

Fakta bahwa sudah ada plugin babel yang melakukan konversi, mungkin merupakan bukti bahwa mungkin untuk mendukungnya di transpiler inti BEJ itu sendiri. Tetapi menjadikannya sebagai spesifikasi resmi akan membuat segalanya jauh lebih mudah dan dapat diandalkan untuk semua orang.

Saya tidak mengetahui React internal, jadi tidak bisa mengatakan banyak tentang kelayakan sebenarnya. Hanya mengungkapkan bagaimana menurut saya "seharusnya" dalam hal keramahan pengguna.

Harap pertimbangkan kembali className vs class . Seperti yang telah dikatakan di atas, keuntungannya hampir tidak ada tetapi ada kerugian nyata.

Salah satunya adalah bagi kami yang menggunakan Haxe sebagai bahasa untuk menulis aplikasi reaksi, ini tidak hanya akan menjadi perubahan besar tetapi juga akan mencegah kami menulis _any_ aplikasi reaksi.

class adalah kata kunci yang dicadangkan di sebagian besar bahasa pemrograman, dan kami tidak dapat memanipulasi prop ini lagi, membuat aplikasi reaksi hampir tidak mungkin (semoga berhasil membuat yang asli tanpa memanipulasi kelas). Hal yang sama berlaku untuk htmlFor vs for , sayangnya (yang ini sangat jelek tapi saya bersyukur itu ada).

Omong-omong, kemampuan pencarian... Bayangkan Anda mencari "kelas React" di Google, Anda akan mendapatkan sinyal campuran: Komponen kelas React, atribut kelas React. Anda google untuk "React className", Anda akan mendapatkan dokumentasi yang sudah ketinggalan zaman (orang-orang yang disebutkan di atas sejumlah besar pekerjaan pemutakhiran yang dihasilkan oleh perubahan ini selain pemutakhiran kode).

Apakah tujuan dari proyek ini untuk menghasilkan lebih banyak pekerjaan bagi masyarakat dan lebih banyak gangguan dan sinyal campuran untuk Internet? Saya harap tidak.

Ya, ekosistem Web dan JavaScript berjuang untuk mempertahankan back-compat dengan kesalahan bodoh di masa lalu, tetapi upaya untuk back-compat inilah yang memungkinkannya tumbuh hingga skala seperti itu tanpa fragmentasi besar.

Saya mengerti bahwa tidak ada kemajuan tanpa perubahan, dan saya sendiri mengadopsi moto awal FB untuk memecahkan sesuatu agar bergerak cepat (juga memiliki rencana bagaimana merakitnya kembali sebelumnya).

Jika Anda begitu gigih sehingga perubahan ini benar-benar dibutuhkan, katakan saja alasan sebenarnya dari perubahan tersebut. Ini bukanlah hal yang "sulit untuk dipelajari", kedengarannya terlalu dangkal untuk tim React Core yang hebat. Anda pasti harus memikirkan sesuatu.

@sompylasar Saya biasanya mencari className= atau className:, sepertinya keduanya akan bekerja dengan kelas juga.

Juga, semoga berhasil melakukannya langsung di github =/

Saya sudah membaca semua komentar di sini. Saya setuju dengan perubahan, tetapi tidak yakin tentang class . Alasan utamanya adalah karena tidak akan bekerja dengan rencana untuk JSX 2.0. tentang notasi pintasan (seperti yang kita miliki sekarang di objek).
Segala sesuatu yang lain tampaknya merupakan perbaikan yang sangat bagus.
Menunggu keputusan akhir :) Terima kasih atas upaya Anda yang luar biasa!

Dalam salah satu komentar Anda, Anda menyebutkan "jika berhasil hari ini, itu akan berhasil besok". Ingatlah hal ini sebelum saya bertanya;).

Saya memelihara perpustakaan UI bernama RMWC https://jamesmfriedman.github.io/rmwc/ yang menargetkan semua versi Bereaksi kembali ke 15.4. Saya dapat mempertahankan permukaan api terpadu, tetapi mengubah className menjadi class, onChange menjadi onInput, dan merombak sistem event akan membuat ini hampir mustahil untuk dilanjutkan.

Apakah ada kemungkinan lapisan "compat" yang dapat menerjemahkan beberapa hal ini di bawah tenda? Jadi saya bisa menulis dalam versi apa pun reaksi api tetapi terus berjalan di runtime yang lebih rendah.

Jika tidak, saya berharap kode aneh saya akan menjadi lebih aneh. 👀.

jika className benar-benar harus diubah menjadi class , harap ubah juga htmlFor menjadi for .
karena class dan for awalnya tidak valid ketika kita merusak props .

Jika React memiliki API sendiri yang menormalkan banyak nama atribut untuk membuat API yang konsisten, maka pasti className sangat cocok untuk itu. Satu pembelajaran idiomatik tambahan di atas idiom camelCase, ditambah fakta bahwa itu memetakan ke nama properti DOM (seperti beberapa atribut JSX lainnya) pasti baik-baik saja dibandingkan dengan harus merusaknya sebagai kasus khusus setiap kali Anda menggunakan objek props dengan itu.

Saya merasa, hingga saat ini, Anda telah mendengar banyak pendapat vokal menentang status quo (“mengapa kita tidak dapat memiliki kelas?!”) sementara semua orang yang senang menggunakannya tetap diam; sesuai dengan pepatah lama bahwa orang lebih cenderung memberikan ulasan negatif daripada yang positif. Secara pribadi saya pikir kurva belajar kecil di atas banyak lainnya jauh lebih baik daripada casing khusus penyangga ini setiap kali muncul.

Saya pikir saya ingin melihat sedikit lebih banyak demokrasi di sekitarnya - saya pikir perubahan yang sangat spesifik ini dapat dilakukan oleh komite (pada dasarnya komite semu yang membuat Anda mempertimbangkan perubahan ini) - dan saya senang berada di pihak yang kalah. Hanya agar itu mempengaruhi paling sedikit orang dari hari ke hari.

Ps semuanya tampak hebat btw, terutama hal-hal acara

menunggu pembaruan baru

@gaearon Apakah layak untuk mempertimbangkan contoh Anda sendiri:

const { oneProp, twoProp, ...rest }  = this.props;

return (
  <div class={'something ' + rest.class} {...rest}/>
);

berisi bug dan tidak akan berfungsi seperti yang Anda harapkan? Ini mungkin tidak sesederhana "Jangan merusaknya."

apakah saya satu-satunya yang tidak begitu peduli tentang kelas menjadi className? Jika Anda bertanya kepada saya reaksi masalah apa yang bahkan tidak akan pernah terlintas dalam pikiran saya.

Namun, pembaruan adalah gratis dan saya suka gratis.

apakah saya satu-satunya yang tidak begitu peduli tentang kelas menjadi className?

Saya sama sekali tidak khawatir tentang kelas. Bug halus dengan IE11 akan menjadi lebih lucu (dan saya masih lebih dari baik-baik saja dengan perubahan ini)

Alangkah baiknya jika mendukung Passive Event Listeners berada dalam lingkup React Fire, yang merupakan fitur penting di ponsel. #6436

Saya setuju. Ini pasti dalam lingkup pekerjaan ini.

Hai @gaearon - pertama-tama terima kasih.

Sudahkah Anda mempertimbangkan untuk melakukan survei untuk mengumpulkan informasi tentang bagaimana orang menggunakan reaksi dan API apa yang digunakan dan apa yang membingungkan?

Sementara React sejauh ini merupakan tumpukan pengembangan frontend favorit saya, saya menemukan ada beberapa pijakan saat mempelajari dan pertama kali menggunakannya. Saya tidak ingin hanya menjelaskan apa yang menurut orang-orang yang saya ajar membingungkan secara pribadi.

Saya merasa ini berguna dalam proyek yang saya ikuti secara pribadi (Node, Bluebird dll).

Dalam hal apa yang secara pribadi ingin saya lihat di inti: Saya ingin dukungan injeksi ketergantungan non-global yang lebih sederhana, penanganan acara yang lebih baik dan lebih konsisten (yang sudah Anda diskusikan).

Sudahkah Anda mempertimbangkan untuk melakukan survei untuk mengumpulkan informasi tentang bagaimana orang menggunakan reaksi > dan API apa yang digunakan dan apa yang membingungkan?

Saya pikir reaksi-asli memiliki canny.io Saya tidak menyadari reaksi tidak

Saya memelihara perpustakaan UI bernama RMWC https://jamesmfriedman.github.io/rmwc/ yang menargetkan semua versi Bereaksi kembali ke 15.4. Saya dapat mempertahankan permukaan api terpadu, tetapi mengubah className menjadi class, onChange menjadi onInput, dan merombak sistem event akan membuat ini hampir mustahil untuk dilanjutkan.

Apakah ada kemungkinan lapisan "compat" yang dapat menerjemahkan beberapa hal ini di bawah tenda? Jadi saya bisa menulis dalam versi apa pun reaksi api tetapi terus berjalan di runtime yang lebih rendah.

Saya berempati dengan kekhawatiran Anda (saya juga menulis bagian perpustakaan saya yang adil). Namun, karena ada begitu banyak pengorbanan dengan mengubah apa pun, kami cenderung melakukan kesalahan dalam upaya membantu orang meningkatkan versi daripada membantu orang mendukung beberapa versi. Itu tidak berarti kami tidak melakukan itu sama sekali (kami memang merilis polyfill untuk penulis perpustakaan untuk perubahan siklus hidup di 16.3) tetapi kami tidak mengoptimalkan untuk kasus penggunaan ini.

Saran saya adalah memotong jurusan baru ketika kita memotong jurusan baru jika ada sesuatu yang tidak sesuai. Orang-orang dapat terus menggunakan versi utama perpustakaan Anda yang lama jika mereka mau. Saya tahu ini lebih banyak upaya untuk mempertahankan, terutama jika Anda terus mengembangkannya, tetapi patut dipertanyakan apakah satu basis kode peretasan lebih baik daripada dua basis kode yang menyimpang tetapi konsisten.

@jamesmfriedman seharusnya (dan tidak terlalu rumit) untuk memperbarui (secara otomatis) dengan codemod) ke API baru dan kemudian (sebagai bagian dari proses pembuatan) mengubah (sekali lagi dengan codemod) ke API lama. Kemudian kirimkan kedua bundel dan minta mereka secara dinamis berdasarkan versi React.

Itu adalah beberapa pekerjaan tetapi dapat dilakukan sekali (sebagai plugin webpack atau skrip instal npm misalnya?) Dan seharusnya tidak sulit. Saya berasumsi itu adalah jenis yang akan dirilis sekali dan digunakan di semua perpustakaan.

Seperti lapisan kompatibilitas waktu kompilasi khusus untuk perpustakaan.

Saya mendukung menjatuhkan htmlFor for for.

Apakah menurut Anda rilis jembatan yang mendukung className dan class akan menjadi ide yang bagus? Itu akan memungkinkan pengembang untuk menggunakan kode React pihak ketiga yang lebih lama sementara kode pihak pertama mereka saat ini dapat dihadapi di masa depan. Setelah pihak ketiga memperbarui, semudah menjatuhkan paket jembatan untuk memiliki React DOM yang sepenuhnya dioptimalkan.

React API tetap tidak konsisten, dan mematahkan asumsi lebih lanjut (mengapa htmlFor tidak untuk dll.)

Saya pikir Anda melewatkan kalimat terakhir ketika saya mengatakan for juga harus berubah. Kemudian saya pikir kita akan sepenuhnya konsisten dengan "nama atribut berselubung unta" kecuali satu atau dua atribut SVG yang langka. Yang bisa kita ubah juga.

Bukankah ada plugin Babel untuk menangani seluruh situasi "class v className" / "for v htmlFor"?

Saya melihat beberapa menyebutkan ini jadi saya ingin mengklarifikasi. Pengaya Babel bukanlah tempat yang tepat untuk melakukan konversi ini karena tidak berfungsi untuk kasus seperti

const props = {
   class: "foo"
}
<div {...props} />

Juga tidak masuk akal jika Anda melewatkan class tetapi mendapatkan className dalam props komponen. Atau, jika plugin hanya menargetkan elemen platform, akan aneh jika mengganti button dengan Button mengubah apa yang dikompilasi oleh prop class .

Menggunakan plugin Babel untuk ini hanya mengaburkan semantik kode yang Anda tulis dan menyebabkan lebih banyak kebingungan. Dalam pandangan saya ini adalah solusi yang lebih buruk daripada hanya mengizinkan className atau class .

Fakta menyenangkan: ini adalah cara kerja kompiler JSX versi yang sangat lama. Perilaku ini telah dihapus karena membingungkan.

Perubahan yang mengagumkan. . .

Luar biasa! Terima kasih kepada semua kontributor yang telah bekerja untuk menghadirkan pembaruan yang begitu menarik.
Saya tidak tahu className > class adalah skandal besar. Secara pribadi saya sudah terbiasa.

Pengurangan ukuran bundel & sistem acara yang ditingkatkan terdengar sangat menjanjikan. Sangat bersemangat!

Saya sangat menantikan untuk memisahkan polyfill dari sistem acara sebagai paket terpisah.
Tetapi apakah className > class terlalu radikal, Anda tahu, React memiliki dampak yang terlalu luas.
Akankah ini mengarah pada banyak sistem yang tak terduga?

Menjatuhkan sepertiga dari React DOM akan menyenangkan.

Akan sangat bagus menggunakan React dalam pengembangan aplikasi web.

Akan lebih baik jika namespace bereaksi terhadap props tertentu seperti key dan ref . misalnya

<Foo @key="foo" @ref={callback} prop="hi" />

ini telah dibahas di sini - https://github.com/facebook/jsx/issues/66

@elado Meskipun itu mungkin sesuatu yang ingin kami lakukan di masa mendatang, saya pikir itu di luar cakupan karena memengaruhi API non-DOM khusus.

Meskipun mengasyikkan, terutama pengurangan ukuran bundel yang selalu disambut baik. Kekhawatiran saya adalah bahwa orang-orang di Facebook meremehkan kelembaman, rasa sakit, dan fragmentasi yang dapat menyebabkan perubahan API pada ekosistem dan komunitas.

Memang benar bahwa mereka memiliki sejumlah besar komponen di FB yang perlu dikhawatirkan, tetapi keuntungan yang mereka dapatkan, dan saya berasumsi di sini, adalah ketergantungan minimal mereka pada perpustakaan reaksi open source eksternal karena kemungkinan besar mereka membangun sebagian besar komponen mereka secara internal. Untuk orang lain yang menggunakan banyak perpustakaan open source, itu benar-benar membutuhkan banyak usaha, menunggu dan frustrasi untuk mendapatkan Proptypes dari banyak perpustakaan (dan saya berbicara dari pengalaman nyata memutakhirkan basis kode reaksi yang besar). Bergerak cepat dan memecahkan banyak hal mungkin tidak berlaku untuk orang-orang yang ingin membangun bisnis yang stabil dengan sumber daya terbatas.

Saya sangat menikmati reaksinya, API-nya sederhana dan secara pribadi saya tidak butuh waktu lama untuk belajar dan menyesuaikan dengan sintaksnya. Jadi saya benar-benar mendesak pengelola untuk mengevaluasi pro/kontra dari setiap perubahan besar ekosistem dengan hati-hati dan berpikir secara pragmatis jika perubahan tersebut memaksa seluruh ekosistem untuk menulis ulang.

Selain itu, saya sangat menghargai upaya membangun, memelihara, dan meningkatkan React, dan semangat para insinyur di baliknya :)

{...pembaruan} mendatang ini adalah

className -> class : Saya tidak berpikir ini adalah situasi yang jarang terjadi ketika atribut class didefinisikan di luar deklarasi JSX/objek. Dalam situasi seperti itu kita harus menggunakan penamaan yang berbeda untuk hal yang sama, menyebabkan inkonsistensi, meningkatkan kompleksitas kode dan beban kognitif.
Perubahan yang disarankan tidak akan menghapus ketidakcocokan atribut/nama prop dari basis kode kami - itu akan ada di suatu tempat karena keterbatasan sintaks atau saat bekerja dengan DOM asli. Merupakan hal yang baik bahwa kami memiliki solusi "standar" (dan mapan pada saat ini) untuk masalah penamaan ini.
Saat ini className dapat digunakan secara konsisten di mana saja, selalu mengacu pada hal yang sama - bahkan ketika bekerja dengan DOM asli. Sebenarnya reaksi mungkin satu-satunya tempat, di mana kita akan dipaksa untuk menggunakan class untuk merujuk ke atribut kelas.
className tampaknya tidak perlu dan sedikit membingungkan sejak awal, tetapi ternyata cukup praktis kemudian dan relatif mudah untuk digunakan.

Saya juga akan menyingkirkan objek tambahan { __html } untuk dangerouslySetInnerHTML karena tampaknya sangat tidak perlu, tetapi mungkin tidak sebanding dengan masalah yang terkait dengan migrasi (dan mungkin tidak terkait dengan masalah ini sama sekali).

Sementara perubahan lain menghasilkan lebih sedikit emosi, itu jauh lebih menarik dan penting, jadi terima kasih tim fb atas usahanya.

Semakin banyak perubahan yang melanggar, semakin lama waktu yang dibutuhkan untuk memutakhirkan aplikasi pengguna yang sebenarnya. Secara pribadi saya sudah cukup jauh di belakang React terhebat terbaru (yang membuat saya sedih), karena versi React sebelumnya telah merusak hal-hal yang kemudian membutuhkan perpustakaan tempat saya bergantung untuk memutakhirkan, yang kemudian menyebabkan penundaan.

Idealnya saya ingin berada dalam skenario yang:

• Pustaka Bereaksi Hilir menulis ulang kode pada versi baru, memperkenalkan bug untuk kasus penggunaan saya
• React menambahkan fitur baru yang keren/pengurangan bundel
• Versi perpustakaan lama tetap dapat digunakan di React baru
• Yay, saya dapat menggunakan fitur baru segera setelah React diluncurkan dan hanya menunggu perpustakaan memperbaiki bug

Dalam praktiknya lebih seperti:

• Perpustakaan menulis ulang kode, memperkenalkan bug
• React merilis perubahan terobosan baru
• Perpustakaan lama tidak lagi berfungsi
• Perpustakaan baru akhirnya diperbarui
• Bug mungkin masih ada
• Saya terjebak pada Bereaksi yang sudah ketinggalan zaman daripada (mengutip Ken Wheeler) "kepanasan baru" untuk waktu yang lama.
• Saya merasa sedih :(

Dari 'perspektif kode pengiriman', setiap pemutakhiran kerusakan besar menjadi bagian besar dari hutang teknis yang mengganggu yang melibatkan pembaruan semua dependensi, pengujian ulang semuanya, lalu memburu bug baru untuk melihat apakah ada solusi. Kecuali jika ada kerentanan kritis atau benar-benar tidak praktis untuk melakukan sesuatu (dan standarnya tinggi), prioritasnya akan dikurangi.

Sayangnya, meskipun telah melepaskan paradigma 0.x dan meskipun mencoba menjadi perpustakaan web inti, React masih mengaduk-aduk nomor versi yang berarti banyak waktu yang dihabiskan untuk berhenti berjalan.

Pada dasarnya apa yang saya katakan adalah, tolong, coba rencanakan API yang memungkinkan perubahan besar di masa depan tidak rusak.

(Juga hal IE11 menyedihkan karena Anda mencela browser yang bukan EOL - rilis terakhir 52 hari yang lalu. Saya pikir tim React akan menemukan ini hanya mendorong pekerjaan ke tim Facebook dan semua tim perpustakaan eksternal dan internal untuk menguranginya alih-alih).

@urugator

Saya juga akan menyingkirkan objek tambahan { __html } untuk HazardlySetInnerHTML karena tampaknya sangat tidak perlu

Ini sengaja dirancang untuk eksplisit dan sulit digunakan secara tidak sengaja. Jika dihapus, maka semua data yang tidak bersih dapat secara tidak sengaja diteruskan ke HazardlySetInnerHTML.

@philipwhiuk

Pada dasarnya apa yang saya katakan adalah, tolong, coba rencanakan API yang memungkinkan perubahan besar di masa depan tidak rusak.

Melanggar perubahan diperlukan untuk meningkatkan teknologi, dan React melakukannya secara bertanggung jawab dengan sejumlah kecil perubahan yang melanggar. Tanpa merusak perubahan seperti menghapus componentWillReceieveProps, kami tidak akan memiliki hal-hal hebat seperti React Suspense, dan perangkat lunak di komunitas akan lebih sulit untuk dipelihara dengan API lama yang tetap ada selamanya. Jika Anda meningkatkan satu rilis utama pada satu waktu, Anda akan baik-baik saja.

Juga hal IE11 menyedihkan karena Anda mencela browser yang bukan EOL - rilis terakhir 52 hari yang lalu.

Tidak ada yang mencela IE 11. Versi React saat ini sebenarnya membutuhkan polyfill untuk beberapa fitur di IE 11, jadi perubahan yang disarankan kemungkinan akan memiliki efek yang sama pada pengembangan IE 11. https://reactjs.org/docs/javascript-environment-requirements.html

Saya juga akan menyingkirkan objek tambahan { __html } untuk HazardlySetInnerHTML karena tampaknya sangat tidak perlu

@urugator - Untuk apa nilainya, secara internal di Facebook penggunaan __html yang paling umum adalah untuk memasukkan HTML yang dirender server ke dalam pohon komponen React. Untuk kasus penggunaan tersebut, kami membuat objek __html sisi server, dan memiliki aturan lint untuk tidak melakukannya di sisi klien. Sisi server, kami memiliki metode yang membuat serialisasi XHP ke objek dengan properti __html . Itu memastikan kami tidak memperkenalkan lubang keamanan di mana pun, karena XHP sangat mirip dengan JSX (itu sebenarnya adalah inspirasi utama untuk JSX) dan juga memiliki perlindungan XSS.

Pada dasarnya, objek __html menandai string HTML yang kita tahu telah disanitasi di suatu tempat dan aman untuk langsung dimasukkan ke dalam DOM. String mentah lebih sulit untuk ditangani - Bagaimana Anda bisa tahu apakah itu sudah dibersihkan vs jika seseorang secara tidak sengaja mengembalikan beberapa input pengguna mentah (dan dengan demikian memperkenalkan lubang XSS)?

Jadi ya, ini sengaja sulit untuk digunakan, karena seharusnya tidak ada banyak kasus penggunaan di sebagian besar aplikasi, dan kasus penggunaan harus terkandung secara wajar. Umumnya Anda tidak boleh membuat objek __html secara langsung di komponen React Anda, tetapi Anda harus memiliki beberapa fungsi yang mengembalikannya (lihat bagaimana dokumen menggunakan fungsi createMarkup : https://reactjs. org/docs/dom-elements.html#dangerouslysetinnerhtml)

Kekhawatiran saya adalah bahwa orang-orang di Facebook meremehkan kelembaman, rasa sakit, dan fragmentasi yang dapat menyebabkan perubahan API pada ekosistem dan komunitas.

Terima kasih telah mengangkat ini. Saya benar-benar mengerti dari mana Anda berasal. Tetapi saya ingin menunjukkan bahwa sebagian besar orang di tim React telah menggunakan React sendiri di luar Facebook sebelum dipekerjakan — sering kali pada aplikasi besar. Jadi saya pikir ini membantu kami berempati dengan jenis masalah yang memengaruhi pengguna open source kami. Saya telah menggunakan Bereaksi selama dua tahun dan mengingat fragmentasi yang disebabkan oleh misalnya sakelar konteks induk/pemilik dengan sangat baik. Kuncinya adalah memiliki strategi migrasi yang baik — dan hal yang sama berlaku untuk semua perubahan di atas.

Memang benar bahwa mereka memiliki sejumlah besar komponen di FB yang perlu dikhawatirkan, tetapi keuntungan yang mereka dapatkan, dan saya berasumsi di sini, adalah ketergantungan minimal mereka pada perpustakaan reaksi open source eksternal karena kemungkinan besar mereka membangun sebagian besar komponen mereka secara internal.

Ini secara historis benar untuk sisi produk pengembangan. Namun, sejak Benang dibuat dan diintegrasikan dengan repositori web kami, kami telah melihat peningkatan jumlah komponen pihak ketiga yang digunakan di halaman alat internal — yang dengan sendirinya memiliki luas permukaan yang jauh lebih besar daripada produk konsumen Facebook. Jadi kita akan memerlukan strategi untuk migrasi bertahap dalam paket pihak ketiga juga.

Tidak seperti banyak perusahaan lain, kami menggunakan versi React yang sama di seluruh basis kode. Jadi kami juga memiliki tantangan unik (misalnya kami tidak bisa hanya "menunggu" dengan mengupgrade beberapa produk). Hal ini tentunya akan menambah tekanan bagi kita untuk memiliki strategi migrasi yang baik dan dijadikan sebagai stress test.

Untuk orang lain yang menggunakan banyak perpustakaan open source, itu benar-benar membutuhkan banyak usaha, menunggu dan frustrasi untuk mendapatkan Proptypes dari banyak perpustakaan (dan saya berbicara dari pengalaman nyata memutakhirkan basis kode reaksi yang besar). Bergerak cepat dan memecahkan banyak hal mungkin tidak berlaku untuk orang-orang yang ingin membangun bisnis yang stabil dengan sumber daya terbatas.

Jika Anda penasaran, kami masih memiliki kode seperti

React.PropTypes = require('prop-types')
React.createClass = require('create-react-class')

di basis kode kami karena kami juga tidak mampu bermigrasi ke "slate bersih" sepenuhnya. Tetapi orang-orang yang memulai dengan React hari ini, serta bagian yang lebih modern dari basis kode kami, tidak perlu menanggung beban itu. Begitulah cara kami memikirkannya — kami ingin memilih default yang lebih baik untuk pengguna React baru, tetapi memiliki cerita migrasi yang bagus untuk kami dan semua orang, bahkan jika beberapa bagiannya mungkin diretas.

Saya mungkin tidak mengomunikasikan ini dengan cukup jelas, jadi saya minta maaf. Setiap perubahan besar akan membutuhkan strategi migrasi yang canggih dan dijalankan dengan baik yang memperhitungkan bahwa perpustakaan pihak ketiga akan membutuhkan waktu lama untuk diperbarui, versi yang berbeda mungkin perlu hidup berdampingan, dll. Misalnya, dengan class rencana tidak hanya untuk mengubahnya dalam semalam. Jika kita ingin melakukannya, kita harus cerdas tentang cara meluncurkannya — mungkin dengan tenggang waktu di mana kita mengizinkan keduanya, atau seorang pembantu untuk membuatnya lebih mudah, dan kemudian secara bertahap menghapus nama lama . Saya belum memiliki strategi khusus, tetapi jelas bahwa perubahan itu tidak mungkin dilakukan tanpa strategi yang baik — baik untuk kami maupun Anda. Ini adalah sesuatu yang kami anggap sangat serius.

(Juga hal IE11 menyedihkan karena Anda mencela browser yang bukan EOL - rilis terakhir 52 hari yang lalu. Saya pikir tim React akan menemukan ini hanya mendorong pekerjaan ke tim Facebook dan semua tim perpustakaan eksternal dan internal untuk menguranginya alih-alih).

Saya tidak mengerti apa yang Anda maksud. Saya tidak mengatakan di mana pun IE11 menjadi "usang".

Posting saya hanya mengatakan bahwa kami mungkin memerlukan lebih banyak polyfill daripada sekarang untuk browser seperti IE11. React sudah membutuhkan beberapa polyfill di IE11. Saya tidak mengatakan kami ingin merusaknya — masih memiliki banyak pengguna — tetapi Anda harus menyertakan lebih banyak polyfill jika Anda ingin itu berfungsi. Itu tampaknya sepenuhnya adil bagi saya.

Selain itu, kami tidak dapat "mendorong pekerjaan" ke tim lain di Facebook. Jika kita merusak sesuatu, itu tugas kita untuk memperbaikinya. Inilah mengapa kami sangat peduli dengan strategi migrasi — kami biasanya harus menjalankannya sendiri.

Re: sisa komentar Anda — kami sama sekali tidak membuat perubahan yang melanggar demi itu. Sebenarnya kami berusaha sangat, sangat keras untuk menghindari melanggar perubahan. Ada banyak bagian dari React yang rumit dan sulit untuk dipelihara, tetapi kami menyimpannya untuk satu-satunya alasan bahwa kami mencoba untuk mendukung API lawas meskipun mereka telah ditandai secara eksplisit sebagai tidak stabil. Namun, pada titik tertentu beban masalah menumpuk, dan kita perlu membersihkan batu tulis untuk bergerak maju dan memperbaikinya. Masalah dalam posting OP saya persis seperti itu. Mereka tidak akan layak melakukan perubahan besar sendirian. Tetapi jika digabungkan, kami pikir itu sepadan dengan usaha.

Saya tidak mengerti mengapa orang begitu negatif terhadap ini. Hanya saja, jangan memutakhirkan sampai dependensi Anda melakukannya?

Apakah masalah kata kunci untuk class vs className dan for vs htmlFor bukan sesuatu yang dapat ditangani oleh kompiler jsx untuk menimpa kata-kata yang dicadangkan?

Saya benar-benar hanya akan khawatir jika perubahannya cukup besar sehingga hasil pencarian memberikan jawaban yang usang ... Seperti rasa sakit angular 2+ yang diperkenalkan saat mencari di googling untuk "angular -angularjs -angular1.x" dll

Selain itu saya menyambut semua perubahan!!!

@gaearon

Kamu berkata

"Kami mungkin perlu membatalkan kompatibilitas dengan beberapa browser lama"

Itu adalah bagian kompatibilitas drop yang saya punya masalah, bukan bagian polyfill berikut. Kembali ke zaman kegelapan adalah kekhawatiran saya.

Mengenai proses. Bukankah 'masalah' semacam ini untuk apa proses RFC dirancang?

Itu adalah bagian kompatibilitas drop yang saya punya masalah, bukan bagian polyfill berikut. Kembali ke zaman kegelapan adalah kekhawatiran saya.

Saya sedang berbicara tentang IE10 dan sebelumnya. Saya secara khusus mencatat bahwa kami ingin terus mendukung IE11 — saya pikir ini mewakili sekitar 3% dari lalu lintas kami, yang jauh lebih banyak daripada batas 1% yang kami anggap terlalu tua.

Mengenai proses. Bukankah 'masalah' semacam ini untuk apa proses RFC dirancang?

Kami akan memposting RFC ketika semuanya lebih disempurnakan. Banyak dari ini membutuhkan eksplorasi, eksperimen, dan pengujian aktual untuk menentukan apa yang bisa dan tidak bisa kita lakukan, dan strategi migrasi apa yang bisa kita gunakan. Kami tidak memiliki cukup detail sekarang bahkan untuk mulai memikirkan RFC (yang harus mencakup strategi migrasi yang komprehensif).

Oke terima kasih atas klarifikasinya!

@gaearon

Masuk akal bahwa kita akan menyingkirkan peristiwa sintetik sama sekali.

Bagaimana cara kerjanya dengan event.currentTarget menunjuk ke elemen di mana pendengar acara terpasang, yang dalam kasus asli selalu berarti document - atau root React setelah React beralih ke itu?

Bereaksi Bukan Hanya Mengatur Properti

(...)

Maksud saya di sini adalah apakah React menggunakan properti atau atribut secara internal adalah detail implementasi

Mengapa ini merupakan detail implementasi ketika dapat memengaruhi apa yang terjadi di DOM? Kecuali jika itu hanya merujuk ke properti yang entah bagaimana tercermin dalam atribut (dan kembali) seperti class / className .

Saya merasa kebingungan seputar perlakuan class / className terkait dengan fakta bahwa apakah React menggunakan properti atau atribut dianggap sebagai detail implementasi. Saya memiliki latar belakang Angular dan ketika saya mulai menggunakan React itu adalah gotcha terbesar bagi saya - di Angular pemisahan antara atribut, properti, dan event handler jelas langsung dari sintaks dan saya bingung apakah props pada elemen DOM disetel oleh React as properti atau atribut.

Bagaimana cara kerjanya dengan event.currentTarget menunjuk ke elemen di mana pendengar acara terpasang, yang dalam kasus asli selalu berarti dokumen - atau root React setelah React beralih ke itu?

Saya belum tahu. :-) Kita lihat saja apa yang bisa kita lakukan. Sangat mungkin bahwa beberapa dari hal ini tidak akan berhasil, atau akan menjadi berbeda. Rencana ini hanyalah garis besar kasar dari hal-hal yang kami rencanakan untuk dilihat, dan visi pemersatu untuk mereka.

Mengapa ini merupakan detail implementasi ketika dapat memengaruhi apa yang terjadi di DOM? Kecuali jika itu hanya merujuk ke properti yang entah bagaimana tercermin dalam atribut (dan kembali) seperti class/className.

Untuk sebagian besar dari mereka tidak ada perbedaan yang terlihat dari sudut pandang pengguna mana yang akan digunakan. Saya pikir sebagian besar dari mereka tercermin (walaupun mungkin saya salah).

Saya memiliki latar belakang Angular dan ketika saya mulai menggunakan React it, gotcha terbesar bagi saya - di Angular pemisahan antara atribut, properti, dan event handler jelas langsung dari sintaks dan saya bingung apakah props pada elemen DOM disetel oleh React sebagai properti atau atribut.

Saya menghargai perspektif Anda. Namun, dalam praktiknya, perbedaan ini seringkali tidak relevan untuk sebagian besar elemen DOM dan dapat diperdebatkan bahwa mempelajari seluk beluk mana yang akan digunakan, dan selalu harus memikirkannya, sebenarnya berharga untuk pengembangan produk sehari-hari. Saya pikir sejauh mana orang membingungkan mereka menunjukkan fakta bahwa itu sebenarnya tidak terlalu relevan bagi mereka.

( Ada kasus di mana itu menjadi jauh lebih relevan seperti dengan elemen khusus. Tetapi bahkan di sana, mendukung keduanya sama-sama membingungkan karena Anda harus memilih mana yang akan digunakan. Ini telah diperdebatkan di tempat lain jadi saya ingin menghindari melompat ke dalam debat ini lagi — kami memiliki proposal dari orang-orang seperti @robdodson dan kami akan memeriksanya.)

@Daniel15
Tanpa kebijakan yang disebutkan (yang menurut saya tidak disebutkan di tempat lain), pembungkus objek tambahan tidak membuatnya lebih aman dengan cara apa pun.
Saya percaya pengguna cukup diperingatkan tentang penggunaan berbahaya melalui dangerouslySetInnerHTML . Itulah gunanya ketika pengguna dipaksa untuk memeriksa dokumen, mempertimbangkan implikasinya dan membuat keputusan.
Kebutuhan untuk membungkus string (mungkin tidak bersih) menjadi objek/fungsi apa pun, tidak akan membuatnya mempertimbangkan kembali atau membersihkan nilai yang dibungkus.
Jika itu akan bekerja seperti itu, maka mungkin { __html } tidak cukup rumit dan [{ _html: { __html }] akan membuatnya lebih aman - berapa kali kita harus menyatakan bahwa ada sesuatu yang berbahaya untuk membuatnya aman ?

Dengan wawasan yang Anda berikan, saya memahami alasannya, tetapi saya pikir itu saat ini tidak berlaku untuk siapa pun di luar facebook, karena kami tidak memiliki petunjuk tentang aturan " { __html } mewakili html yang disanitasi".
Saya selalu berpikir itu hanya halangan lain di API. Terima kasih telah meluangkan waktu dan menjelaskannya, sekarang lebih masuk akal.

Ini bukan hanya tentang membuatnya lebih kompleks, ini tentang mencegah data yang tidak disanitasi digunakan secara tidak sengaja.

Saya hanya suka cara bereaksi yang begitu dikritisi oleh masyarakat. Kudos bagi kalian untuk mendengar semuanya dan memanfaatkannya sebaik mungkin.

Saya suka bagaimana semua orang berpikir perubahan yang datang ke sini atau datang ke React di versi terakhir adalah 'melanggar'. Orang-orang itu jelas tidak mengalami Angular 2 > 3 > 4 kali.

Saya suka perubahannya. Secara pribadi saya tidak keberatan className dan merusak class bisa menjadi masalah. Tapi saya ingin melihat apa yang akan kalian buat.

Saya ingin meminta agar diskusi ini tetap pada topik. Apakah Anda menganggap penodaan HTML berbahaya bermanfaat atau tidak, itu menarik tetapi tidak terkait dengan masalah tersebut.

saya suka Bereaksi

Ini adalah kesempatan sempurna untuk membantu pengembang yang baru bereaksi agar merasa lebih diterima. Saya sangat senang ini terjadi.

Membiarkan orang menggunakan kelas saja tidak memiliki efek negatif kecuali itu tidak berhasil dengan perusakan, dan biaya migrasi.

@gaearon Melempar 2c tetapi dua negatif itu tampak lebih besar atau lebih besar dari negatif saat ini (biaya belajar satu kali kecil class => className vs selalu menghindari perusakan + biaya migrasi tingkat ekosistem).

reaksi :hati:

menggemakan @natew di atas:

@gaearon Melempar 2c tetapi dua negatif itu tampak lebih besar atau lebih besar dari negatif saat ini (biaya belajar satu kali kecil class => className vs selalu menghindari perusakan + biaya migrasi tingkat ekosistem).

Lagi pula, apa motivasi di balik perubahan dari className menjadi class ?
Sejauh yang saya dapat mengumpulkan komentar Anda bermuara pada dua argumen, (tolong perbaiki saya jika saya salah):

lebih dekat secara konseptual dengan apa yang kebanyakan orang harapkan

Oke tapi menambahkan Name adalah rintangan terkecil. Belajar menggunakan className adalah bagian paling sederhana dari belajar React. Ini sedikit kekhasan yang tidak memiliki kerugian - memang itu benar-benar memecahkan masalah dengan empat karakter. Dan itu memiliki overhead kognitif yang jauh lebih sedikit daripada alternatif perusakan mana pun yang disediakan.
Bayangkan mengajari seseorang untuk mendesain komponen React pertama mereka dengan

function Button({ color, ...rest }) {
  const buttonClass = rest.class +  ' Button-' + color;
  return <button {...rest} class={buttonClass} />
}

Kepala noob saya akan meledak.
Saya pikir ketika berinteraksi dengan API, orang mengharapkan API untuk memberikan solusi. ClassName adalah solusi bawaan. Kelas adalah masalah bawaan.

kurang mengetik

Bruh, itu empat karakter 8^) . Selain itu, bahkan jika kita merusak class jauh lebih jarang daripada yang kita gunakan saat ini className itu jauh lebih banyak mengetik ketika kita melakukannya. Jadi saya akan mengetikkan 4 karakter lebih sedikit 12 kali tetapi menambahkan 50 karakter lagi setiap kali saya desctructure class ? Ini hanya konyol.

Apakah ada alasan kuat lain untuk perubahan ini yang saya lewatkan?
Apakah motivasinya semacam kekhawatiran tentang kesesuaian dengan atribut/properti DOM?
Itu sepertinya argumen yang terlalu akademis bagi saya. Kebanyakan orang tidak terlalu menyadari detail implementasi ini dan saya rasa tidak perlu demikian.

Apakah jika dirilis hari ini React akan mengizinkan class alih-alih mengubah ke className?
Saya pikir itu tidak relevan.
React tidak open source hari ini dan jika itu/akan open source setahun ke depan, serangkaian keputusan yang berbeda mungkin dibuat pada saat itu.
Terkadang lebih baik untuk tetap pada konsistensi daripada mencoba menghilangkan setiap kerutan.

Dan jika React telah menggunakan kelas sejak awal, kita akan terbiasa untuk merusak struktur kelas dan menugaskannya kembali ke className tetapi siapa pun yang datang dengan PR untuk mengubah kelas _to_ className akan dipuji sebagai penyelamat.

Terakhir, saya hanya ingin mengatakan bahwa saya tidak mengharapkan diri saya untuk menjadi begitu marah atas ini, jadi saya minta maaf jika ada yang dianggap kasar, menghina, atau menuduh. Saya berterima kasih atas semua pekerjaan yang Anda lakukan di React dan untuk semua pengetahuan yang Anda berikan di Twitter - Saya telah menggunakan tweet Anda untuk mempertahankan beberapa jawaban yang saya berikan pada wawancara.

Saya berdoa kepada dan.church agar Anda berubah pikiran.

Saya sangat senang bahwa reaksi dapat terus ditingkatkan. Sebagai pengembang yang menggunakan reaksi, saya tidak ingin melihatnya dikalahkan oleh vue. Tetapi proses className-> class pasti menyakitkan.

Saya tidak menentang penggantian nama className -> class demi copy-paste tetapi tidak ada motivasi yang jelas untuk itu sampai sekarang. className ada di DOM sementara ada nama prop yang dipesan yang muncul entah dari mana seperti htmlFor . Saya merasa itu harus diprioritaskan dalam hal penggantian nama dan itu mungkin kurang meresap dari perubahan yang dapat berfungsi sebagai ujian juga.

@sonhanguyen htmlFor adalah nama web api resmi juga: https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelElement/htmlFor

@allan2coder alih-alih membungkusnya dalam array, bungkus dalam <React.Fragment> atau <> .

@allan2coder Juga tolong jaga topik ini tetap pada topik, Anda dapat mengajukan pertanyaan dengan mengajukan masalah terpisah jika Anda mau.

Saya ingin menarik perhatian ke patch-package yang merupakan paket yang membuatnya lebih mudah untuk menambal dependensi Anda (mis. untuk membuatnya berhenti menggunakan React API yang tidak didukung). Memang, ini lebih berguna untuk kode aplikasi daripada kode perpustakaan, tetapi saya pikir ini akan membantu mengatasi beberapa masalah @philipwhiuk .

Aku tak sabar untuk.

• Bermigrasi dari onChange ke onInput dan jangan polifill untuk komponen yang tidak terkontrol.

Untuk kata-kata di atas, saya ingin tahu apakah acara onChange akan digunakan dekat dengan acara asli atau tidak digunakan di masa depan?

@MuYunyun

Berdasarkan kata-katanya, mereka tidak berencana untuk mempertahankan perilaku onChange saat ini. Itu tidak masuk akal. Bereaksi seperti lib modern lainnya tidak akan menjadi lapisan kompatibilitas browser, juga tidak seharusnya.

OnChange saat ini mengemulasi input + beberapa kasus lainnya. Sama sekali tidak masuk akal mengingat acara perubahan sudah ada di DOM dan tidak memiliki semantik yang sama: https://developer.mozilla.org/en-US/docs/Web/Events/change

@jxub

Sedikit berlebihan tetapi agak menyedihkan bahwa tidak seorang pun (sejauh yang saya tahu) memiliki ide untuk membuat html/css/svg -> jsx transfomer untuk memudahkan migrasi ke Bereaksi dengan begitu banyak perubahan sepele untuk memetakan atribut HTML ke Bereaksi alat peraga. Begitu banyak jam kerja yang terbuang untuk melakukan sebagian besar cari-dan-ganti :(

Saya tidak tahu tentang editor lain, tetapi IntelliJ IDEA (dan WebStorm, PhpStorm dll.) melakukan transformasi ini, ketika Anda menempelkan kode HTML ke JS.

Sedikit berlebihan tetapi agak menyedihkan bahwa tidak seorang pun (sejauh yang saya tahu) memiliki ide untuk membuat html/css/svg -> jsx transfomer untuk memudahkan migrasi ke Bereaksi dengan begitu banyak perubahan sepele untuk memetakan atribut HTML ke Bereaksi alat peraga. Begitu banyak jam kerja yang terbuang untuk melakukan sebagian besar cari-dan-ganti :(

Itu sebenarnya ada tetapi cukup lama dan tidak sepenuhnya benar: https://magic.reactjs.net/htmltojsx.htm

Kita harus menghidupkan kembali upaya itu. Jika Anda ingin membantu, silakan lakukan: https://github.com/reactjs/reactjs.org/issues/484. Sejauh ini tidak ada yang menawarkan bantuan dan menindaklanjuti.

Itu sebenarnya ada tetapi cukup lama dan tidak sepenuhnya benar: https://magic.reactjs.net/htmltojsx.htm

Saya telah menggunakan ini berkali-kali sebelumnya - ini sangat umum digunakan ketika mengalihdayakan komponen tertentu kepada orang yang mengetahui HTML/CSS tetapi tidak JavaScript.

Jadi hanya memberikan umpan balik bahwa ini adalah alat yang berguna yang digunakan orang dalam praktik. Ada juga konverter online lainnya.

Masalah dengan pendekatan ini adalah hanya satu arah (hanya migrasi _to_ bereaksi). Masalah itu tidak khusus untuk React.

Semoga itu akan membuat segalanya lebih mudah ...

Masalah dengan pendekatan ini adalah hanya satu arah (hanya bermigrasi untuk bereaksi). Masalah itu tidak khusus untuk React.

Mengapa? Seharusnya lebih mudah sebaliknya — jalankan ReactDOMServer.renderToString .

Sabar nunggu rilisnya

@gaearon

Mengapa? Seharusnya lebih mudah sebaliknya — jalankan saja ReactDOMServer.renderToString.

Oke, jadi untuk konteks masalah yang dibahas adalah: Saya ingin orang yang menulis html/css dan tidak tahu JavaScript cukup baik untuk bekerja pada kode JS untuk dapat bekerja pada markup/gaya/tata letak komponen.

Salah satu cara untuk melakukannya sekarang adalah dengan meminta mereka mengembangkannya dalam html/css dan menggunakan htmltojsx. Itu bekerja cukup baik untuk saya.

Masalahnya adalah saya sekarang harus mempertahankan setiap perubahan markup/gaya/tata letak sendiri di Bereaksi.

Jika saya memanggil ReactDOMServer.renderToString memang saya akan mengeluarkan HTML statis tetapi HTML itu akan kehilangan semua kode komponen yang sebenarnya sehingga tidak layak untuk memberikannya kepada orang-orang UI dan menggunakan output mereka karena saya harus menulis ulang semua logika saya.

Hal-hal seperti react-sketchapp adalah kemungkinan yang bagus untuk mengatasi masalah ini, tetapi saya berharap pendekatan yang lebih umum memungkinkan saya melakukan ini saat menggunakan html/css biasa. Misalnya - melalui beberapa bentuk metadata dan menyimpan ID reaksi pada elemen.

Saya benar-benar mengerti ini tidak dalam ruang lingkup untuk inti ReactDOM tetapi itu pasti dalam domainnya dan merupakan masalah yang menarik.

Ini bukan prioritas tinggi - saya kebanyakan hanya ingin menjelaskan mengapa htmltojsx berguna bagi sebagian dari kita bahkan di luar konteks migrasi :)

Saya ingin orang yang menulis html/css dan tidak tahu JavaScript cukup baik untuk bekerja pada kode JS untuk dapat bekerja pada markup/gaya/tata letak komponen.

Seberapa besar masalah ini, dan seberapa sulitkah untuk mengajari mereka sedikit BEJ? Perubahan perlu ditinjau oleh insinyur yang paham Bereaksi.

Maaf jika ini terlalu di luar topik, tapi saya yakin HTML/CSS saja tidak cukup saat ini.

( @gaearon jangan ragu untuk menyembunyikan ini jika berisik karena ini adalah balasan tentang komentar OT yang sudah sedikit di atas)

Seberapa besar masalah ini, dan seberapa sulitkah untuk mengajari mereka sedikit BEJ? Perubahan perlu ditinjau oleh insinyur yang paham Bereaksi.

Nah, itu akan membutuhkan yang berikut:

• Hanya bekerja dengan kontraktor yang akrab dengan tumpukan React Anda saat ini. Jauh lebih sulit untuk menemukan orang yang akan mempelajari komponen gaya
• Instal Node (npm), tumpukan Anda (React, webpack, dll.), dan semua hal lain yang diperlukan untuk menjalankan proyeknya di setiap komputer pengguna UI dan tetap perbarui.
• Ajari mereka beberapa pemrograman dasar dan JavaScript, pelajari cara bekerja dengan devtools, kesalahan konsol, dll.
• Ajari mereka Bereaksi, apa sintaksnya, hal-hal seperti className , apa arti key dll.
• Hanya bekerja dengan kontraktor dan pekerja lepas yang bersedia bekerja seperti itu daripada memproduksi HTML/CSS. Ini biasanya juga membuat barang lebih mahal.

Sekarang, seperti yang disebutkan di atas hal-hal seperti react-skeptchapp adalah cara yang berguna untuk membuat ini lebih mudah didekati dan mudah bagi orang-orang UI - tetapi itu masih mengharuskan mereka untuk belajar banyak.

Saya benar-benar mengerti mengapa Anda menanyakan ini dan saya tidak yakin ini adalah masalah umum (saya curiga demikian). Terlepas dari itu, saya tidak berpikir itu dalam ruang lingkup untuk masa depan inti ReactDOM.

Ini agak keluar dari topik :-) Mari kita lanjutkan diskusi ini di Twitter atau di tempat lain.

"Perilaku Anda melihat alat yang digunakan adalah perilaku yang didorong oleh alat"
~ Gary Bernhardt

Cara React digunakan, karena sebagian besar tidak menjadi bagian dari React's API, menghasilkan banyak jebakan yang menghasilkan diskusi seperti ini di mana semua orang bingung dan frustrasi. Apakah menggunakan kata kunci yang dicadangkan seperti class buruk karena javascript, html, atau reaksi itu sendiri?

Kembali ke perubahan yang dibuat pada 16.3 (Jika saya ingat dengan benar) perpustakaan sekarang akan berperilaku berbeda dengan menerima atribut apa pun yang diteruskan ke elemen html asli yang dirender oleh vdom, saya ingat dengan jelas bahwa sebagian besar basis kode saya sekarang diganggu oleh bug karena dari perilaku yang kami terapkan dalam pola yang jelas buruk ini

<div {...this.props} />

Jadi saya harus mengatakan saya cukup kecewa bahwa Dan menyarankan agar kami terus menyebarkan kode mengerikan ini ke semua basis kode.

Pertama-tama, tidak ada jaminan dalam konten props , tetapi pada saat pertama elemen html asli hampir selalu tidak melakukan apa yang diharapkan dari mereka jika Anda memberikan props yang salah ke dalamnya, namun pada saat yang sama dianggap aman untuk menyebarkan props induk ke komponen anak, tetapi kenyataannya ini sangat malas

<Child {...props} />

const Child = (props) => <div {...props} />

Terkadang Anda bahkan tidak tahu apa yang Anda render dan masalah ini menjadi lebih sulit untuk ditangani. Juga sangat sulit untuk memeriksa jenis komponen ini menggunakan sistem tipe karena itu berarti bahwa sebagian besar komponen diperlukan untuk mengimplementasikan sejumlah antarmuka acak yang harus mereka bagikan satu sama lain, ini adalah lubang kelinci yang dalam untuk dimasuki.

Jika penulisan ulang untuk bereaksi dibuat untuk memperbaikinya, saya berharap para desainer di belakangnya menyadari kerusakan yang disebabkan oleh pola-pola buruk ini terhadap basis kode alih-alih menggandakan keputusan yang buruk.

Kita harus ingat bahwa jsx dibangun di atas javascript, dan menggunakan "keistimewaan" javascript sebagai alasan untuk secara sengaja bertentangan dengan bahasa dalam penggunaan kata kunci adalah langkah pertama yang buruk untuk memperbaiki API, saya akan menyarankan bahwa alih-alih memulai perang terhadap bahasa Anda akan menjauh darinya sepenuhnya

@gaearon Lama! :) (ps. maaf untuk tl; dr depan)

Bagaimanapun, saya hanya ingin memberikan beberapa wawasan tentang apa yang telah saya pelajari dari petualangan saya sendiri. Saya telah membuat turunan React "minimal" saya sendiri yang sekarang saya gunakan untuk aplikasi kritis kinerja/fitur. Awalnya hanya eksperimen sampingan yang menyenangkan, tetapi saya melihat peningkatan kinerja melebihi +300% dalam kasus dunia nyata untuk rendering/pembaruan/penghapusan awal termasuk banyak manfaat lainnya. Itu tanpa menggunakan event handler yang dikumpulkan juga.

IIRC sebagian besar dari ini datang hanya dari perpustakaan saya sendiri melewati semua logika React-props dan hanya memasukkan atribut langsung ke setAttribute, gaya langsung ke style.setProperty, pendengar langsung ke addEventListener, dan seterusnya. Jadi antarmuka elemen DOM dasar terlihat seperti ini `{attributes: {}, style: {}, listeners: {}, className: "", ...}, ini lebih bertele-tele tetapi antarmuka sekarang kecil dan sepele untuk diimplementasikan dan sangat cepat. Ini mungkin terlalu ekstrem bagi Anda, tetapi ini sangat membantu saya.

Sesuatu yang telah saya lakukan juga adalah menjatuhkan CSS sepenuhnya, semua gaya sebaris. Ini jauh lebih cepat daripada yang Anda harapkan dan hadir dengan banyak manfaat praktis yang bagus, ini juga mengurangi biaya penguraian CSS awal browser (yang sangat mahal) dan pencocokan pemilih yang menutup sebagian besar overhead. Saya dapat dengan mudah mencapai 60 FPS yang stabil dan jauh di atas laptop saya yang kurang bertenaga bahkan untuk hierarki yang kompleks (tanpa pemangkasan pohon).

Saya membayangkan sebagian besar itu tidak terlalu berguna bagi Anda, tetapi mungkin ada sesuatu yang menarik di sana. Bagaimanapun, keluhan utama saya dengan HTML+React adalah bahwa komponen pengguna React tidak mengekspos antarmuka apa pun untuk tata letak/posisi (dan mungkin sampai batas tertentu juga acara) tanpa menggunakan CSS. Sederhananya, jika saya membuat ButtonComponent dan kemudian menggunakannya, secara default tidak dapat diposisikan atau diintegrasikan ke dalam tata letak tanpa; mengimplementasikan logika tujuan-khusus di dalamnya, membungkusnya dalam elemen dummy yang dapat diposisikan atau dengan mengekspos style-prop yang digabungkan ke dalam gaya yang digunakan untuk elemen root ButtonComponent. Tak satu pun dari mereka yang sempurna, dan menggabungkan gaya apa adanya berbahaya karena mudah untuk menempatkan gaya di sana yang seharusnya tidak Anda lakukan. Pada dasarnya, masalahnya adalah bahwa pada batasan komponen, subset dari properti yang tersedia harus bersifat publik (pemosisian/tata letak) dan beberapa internal (penataan visual).

Hal lain yang saya lakukan adalah pemisahan antara komponen dan konten/anak-anak. Misalnya komponen DOM tidak mengambil daftar turunan, melainkan menerima instance konten. Instance konten mengimplementasikan logika rekonsiliasi dan rendering anak-anak, yang berarti Anda dapat memiliki implementasi yang berbeda untuk tujuan yang berbeda. Kasus penggunaan yang paling jelas adalah; sebagian besar hierarki statis vs anak-anak yang dihasilkan secara dinamis. Jadi hierarki statis yang membentuk mayoritas dapat diimplementasikan menggunakan logika sederhana yang lebih cepat, sedangkan anak-anak yang dihasilkan secara dinamis mungkin memiliki strategi yang dapat dikonfigurasi. Ini juga membuka kemungkinan memiliki "komponen konten" yang dapat digunakan untuk mengelola secara cerdas, misalnya, tata letak flexbox tanpa tipuan yang tidak perlu.

Terkait dengan itu dan sesuatu yang menurut saya React salah adalah anak-anak, saya belum sampai pada kesimpulan atau solusi khusus. Tapi saya sangat percaya ada masalah mendasar dalam React di mana Anda tidak dapat menggelembungkan props dari root ke titik sembarang dalam hierarki tanpa merender ulang setiap elemen di antara dua titik itu dan pemangkasan yang efektif sering kali juga bermasalah. Kinerja sebagian besar "cukup baik" dan kompleksitas tambahan dalam mengelola ini di React mungkin tidak membuatnya layak untuk dipecahkan. Tetapi dalam eksperimen saya sejauh ini, saya dapat mengurangi biaya pembaruan root penuh menjadi pecahan biasa dengan jumlah kode yang sangat kecil, tetapi intuisi saya mengatakan itu tidak terlalu cocok dengan filosofi React atau model anak-anak sederhananya.

Sesuatu yang sebagian besar pasti bukan untuk Anda, tetapi fitur besar dari perpustakaan saya adalah pada dasarnya hanya menyediakan "elemen DOM dasar" minimal untuk tujuan umum. Idenya adalah bahwa Anda dapat dengan mudah memperluas/mengganti dan menerapkan perilaku spesifik tingkat rendah Anda sendiri jika Anda mengembangkan proyek besar dengan persyaratan/keadaan tertentu dengan sangat murah dan tanpa menggunakan "peretasan", misalnya jika Anda sangat menyentuh berorientasi, ingin melakukan penanganan gaya khusus, dll. Ini juga berarti bahwa versi yang berbeda kompatibel dan dapat dijalankan berdampingan selama ABI sama (perubahan harus sangat jarang dan sangat mudah diperbaiki ). Ini juga berarti bahwa Anda bisa cukup berpendirian dalam antarmuka elemen DOM tanpa harus mencakup semua dan mencoba memecahkan masalah semua orang.

Bagaimanapun, mungkin sebagian besar hanya bertele-tele dan saya mungkin tidak menyampaikan sebagian besar konsep dengan baik, tetapi mungkin ada informasi menarik untuk Anda dari seseorang yang pergi ke arah yang berlawanan. Sebagian besar mungkin tidak relevan bagi Anda hanya karena Anda menargetkan "kesederhanaan", tetapi siapa tahu :)

Juga sebelum saya lupa, Anda mungkin tertarik dengan fungsi objectKeyValueReconcile saya, yang secara khusus dioptimalkan menjadi sangat cepat untuk membandingkan props prev/next untuk skenario mirip React. Ini bertanggung jawab atas peningkatan kinerja dunia nyata yang cukup signifikan bagi saya.

https://github.com/syranide/surgical/blob/master/packages/surgical/private/objectKeyValueReconcile.js

imho saya akan menjatuhkan ide "kelas". BEJ pada akhirnya akan mati.

Apa pemikiran untuk menambahkan dukungan untuk DOM/peristiwa jendela berbasis non-elemen ke React DOM? Dengan kemungkinan penghapusan acara sintetis, saya curiga masih ada beberapa bentuk pengumpulan/pembaruan/pengumpulan acara. Peristiwa penekanan tombol, pengubahan ukuran, dan gulir jendela adalah skenario umum yang muncul dalam pikiran, tetapi mungkin dapat mendukung sebagian besar/semua daftar di https://developer.mozilla.org/en-US/docs/Web/Events akan bermanfaat di balik abstraksi yang sama.

Ini kebetulan juga dibahas di edisi terbuka tertua #285 .

@gaearon

Efek praktis dari className -> class adalah:

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

akan menjadi

({ ...rest }) => <div class={rest.class} />

Perubahan ini akan menyebabkan sedikit rasa sakit sementara manfaatnya sepenuhnya akademis . Kami telah melihat komunitas lain melakukan hal serupa - misalnya, pertimbangkan bahwa python3 pertama kali dirilis satu dekade lalu dan kami masih memperdebatkannya. Sebagian besar masyarakat belum melakukan transisi dan tidak akan pernah. Harap pertimbangkan kembali.

@kans

Atau ini:

props => <div class={props.class} />

Itu kompleksitas yang mirip dengan fungsi aslinya.

Saya suka className karena class adalah kata kunci di js, tapi jangan berpikir itu masalah besar. Saya lebih suka menata dengan sesuatu seperti glamor, jadi, ini bukan sesuatu yang mempengaruhi saya. Saya mungkin telah menggunakan className beberapa lusin kali dalam beberapa tahun terakhir ?? Hampir tidak pernah.

Meskipun satu pemikiran yang muncul di benak saya mendukung class adalah bahwa kebanyakan orang yang benar-benar menggunakan className menggunakan css, dan mereka mengharapkan model html/css dari class . Tujuan utama dari prop ini sebenarnya hanya menghubungkan dengan kode css, benar, jadi mengapa tidak menyebutnya kelas seperti yang diharapkan pengguna html/css?

IMO di luar kode sistem desain, pengembangan React yang benar-benar idiomatis biasanya tidak akan banyak menggunakan className atau class. Ketika saya perlu menggunakan kelas untuk css, itu sebagian besar diisolasi ke beberapa komponen UI kecil. Hampir semua yang digunakan pada lapisan aplikasi adalah level yang lebih tinggi (seperti, katakanlah, <Columns verticalAlign="center"> atau <BodyText /> ).

Jadi saya kira saya bertanya-tanya apakah mengganti nama dari className menjadi class memudahkan jenis orang yang tetap menggunakan prop (lebih mudah untuk masuk ke pengembangan React, untuk beralih konteks, untuk tidak marah , dll), mengapa tidak mengganti namanya saja?

Kurangi ukuran bundelnya.

Karena ini adalah pembaruan besar yang melanggar, mungkin kami juga dapat memperbaiki penamaan siklus hidup React!

yaitu shouldComponentUpdate => shouldUpdate , dll. Penamaan ini sangat konyol.

@AlexGalays

Karena ini adalah pembaruan besar yang melanggar, mungkin kami juga dapat memperbaiki penamaan siklus hidup React!

yaitu shouldComponentUpdate => shouldUpdate, dll. Penamaan ini tidak masuk akal.

Nama kait siklus hidup yang lebih panjang tidak terlalu ambigu saat dicari. Nama yang lebih pendek terlalu umum dan bergantung pada konteks di mana mereka berada, jadi mungkin secara kebetulan cocok dengan sesuatu yang lain dengan basis kode yang besar (pencocokan positif palsu).

Metode siklus hidup adalah bagian dari inti React, dan masalah ini semata-mata tentang react-dom.

@ljharb
Ups, memang!

@sompilasar
Maaf, itu bukan alasan yang baik (permainan kata-kata, reasonReact memperbaiki nama metode :)). Kami juga tidak mengawali semua modul kami dengan nama paketnya dan kami menganggapnya baik-baik saja. Bagaimanapun, akan berhenti membicarakan hal ini karena inti-reaksi berada di luar cakupan dalam masalah ini.

Akan senang melihat perubahan ini.
Saya berharap mereka akan diimplementasikan dengan mempertimbangkan elemen kustom.

Saya ingin tahu apakah perlu memindahkan beberapa diskusi ke utas terpisah di forum (https://discuss.reactjs.org)? Karena masalah GitHub tidak dijalin seperti posting forum, itu membuatnya sulit untuk membahas banyak hal berbeda dalam masalah yang sama.

Perubahan className -> class menurut saya menarik

Tonton, proyek React 2019

const {
  class: className, // YouKnowIamRight PepeHands
  someFancyProp,
  ...restProps
} = props

Saya melihat ini datang pasti.

Saya sangat senang dapat menyalin tempel HTML dan tidak harus mengubah className tetapi pada saat yang sama saya melihat masalah yang dapat ditimbulkan oleh kata kunci yang dipesan class .

Pada titik ini, saya lebih memilih untuk tetap menggunakan className kecuali jika Anda memiliki kekhawatiran teknis yang kuat tentang hal itu (bukan preferensi pribadi)

Tapi itu hanya pendapat pragmatis saya.

Sementara saya memahami gesekan tambahan karena tidak dapat merusak pengenal class , saya merasa terlalu banyak orang di utas ini melebih-lebihkan berapa kali mereka perlu menerima nama kelas sebagai penyangga.

Meneruskan className ke komponen React (bukan hanya elemen DOM) berarti Anda membuat blok penyusun yang cukup kecil tanpa memberikan abstraksi baru atau komponen tersebut memaparkan beberapa detail implementasinya. Dalam kasus pertama (misalnya komponen <Button /> ), Anda mungkin ingin mengikuti contoh @gaearon dan meneruskan "sisa" props ke elemen DOM juga. Dalam kasus kedua, mungkin gesekan tambahan akan memaksa Anda untuk menghindari melakukan hal itu dan menemukan solusi yang lebih baik.

Dari pengalaman saya yang sederhana, saya harus menyalin HTML tempel ke JSX (dan mengganti class dengan className ) lebih sering daripada yang saya ingat membuat komponen yang menerima className .

Menyebarkan semua alat peraga ke HTML adalah pola anti. Jika seseorang di masa depan menyertakan prop tambahan yang kebetulan cocok dengan atribut HTML, itu akan secara tak terduga mengubah perilaku. Jika IE menambahkan atribut baru, Anda disemprot.

@philipwhiuk jika Anda hanya menyebarkan alat peraga yang tidak Anda gunakan, tidak akan ada masalah perilaku.

@j-f1

jika Anda hanya menyebarkan alat peraga yang tidak Anda gunakan, tidak akan ada masalah perilaku.

Tidak juga. Jika Anda menambahkan opsi baru ke API komponen Anda, maka opsi ini berhenti diteruskan ke simpul DOM yang mendasarinya. Seseorang mungkin bergantung pada atribut yang tepat yang ditetapkan pada elemen dan kemudian Anda menghancurkan orang itu. Menyebarkan semua alat peraga yang tidak digunakan ke apa pun di bawahnya berarti penambahan apa pun ke API komponen Anda adalah perubahan besar.

Btw, saya menggunakan contoh acak di mana Anda mendekonstruksi nilai class tetapi tidak memotong detail itu.

Banyak dari Anda (ya, memang) mendekonstruksi hampir setiap nilai dari props dan state alih-alih menggunakan notasi titik untuk non-alasan selain menghindari mengetik beberapa teks tambahan.

Oleh karena itu, saya menekankan situasi, tetapi jangan menyamping dan fokus dalam menyebarkan alat peraga atau topik sampingan mana pun yang dapat Anda bicarakan.

Jika Anda sedikit lebih pragmatis, Anda akan berbicara tentang implikasi teknis alih-alih preferensi pribadi Anda, tetapi saya tidak melihat ada orang yang mengatakan apa pun tentang implikasi teknis dari className .

Hal lain yang perlu Anda perhatikan adalah Anda membuat kontributor Inti fokus pada sesuatu yang merupakan masalah preferensi pribadi (buktikan saya salah, hanya karena saya ingin Anda memikirkannya secara pragmatis)

Waktu, tenaga, dan uang mereka (dari perusahaan) terbatas, jadi lebih baik jika masyarakat memahami bahwa ada hal-hal yang lebih baik untuk memusatkan perhatian kita dan jika ada orang dari tim Inti akan menghabiskan waktu satu jam untuk sesuatu yang kita sukai yang mereka gunakan. hal besar berikutnya untuk React, tidak ada kode refactoring untuk perubahan seperti itu.

Tapi sekali lagi, pendapat pragmatis saya.

Berbicara tentang polyfill, saya tidak berpikir reaksi harus mencoba mendeteksi apakah pengguna menentukan polyfill "baik".
(misalnya hasBadMapPolyfill dalam kode)
React seharusnya tidak bertanggung jawab atas semua kesalahan acak yang dapat dilakukan seseorang dalam proyek pemrograman.

@AlexGalays React bergantung pada penggunaan implementasi Peta dengan semantik yang benar. Jika pengguna menggunakan polyfill yang tidak sesuai, aplikasi mereka mungkin rusak dengan cara yang tidak terduga dan membingungkan, jadi akan sangat membantu untuk memperingatkan sebelumnya dalam kasus tersebut.

Ini hanya dilakukan dalam pembangunan pengembangan juga, jadi tidak ada biaya tambahan untuk ini dalam produksi.

Saya suka React Fire ini dan Anda akan terus mengerjakan ini karena sepertinya langkah yang lebih menarik untuk memodernisasi ReactDOM.

Apakah mungkin reaksi api untuk tidak rebind event handler?

class Compo exntends Compoent {
 onClick() {
   ...
 }
  render() {
   <button onClick={this.onClick} >click me </button>
  }
}

Saya tidak berpikir ada orang yang benar-benar ingin event handler di-rebound. Dan dalam kasus yang jarang terjadi, Anda dapat mengikatnya secara manual

@cullophid

Apakah mungkin reaksi api untuk tidak rebind event handler?

Anda dapat mengikat metode ke kelas sekali menggunakan ikatan otomatis fungsi panah atau mengikat fungsi di konstruktor Anda. Jika ada parameter unik yang ingin Anda hubungkan ke acara, Anda dapat melihat ke memoizing event handler atau melampirkan atribut DOM ke node itu sendiri dan mengaksesnya melalui event.currentTarget .

class Compo extends Compoent {
 onClick = () => {
   ...
 }
 render() {
   <button onClick={this.onClick}>click me</button>
 }
}

Manfaat lain dari menyederhanakan sistem acara (dapatkah kita kembali ke acara DOM mentah tanpa penyatuan seperti yang dilakukan SEMUA kerangka kerja? :)) adalah lebih mudah untuk mengetik secara statis juga.

Sepertinya rencana yang bagus! Akan sangat menyenangkan untuk memiliki dukungan IE 11 (bahkan jika itu berarti mengirimkan polyfill kita sendiri yang benar-benar baik-baik saja). Sebagai seseorang yang bekerja dengan klien pemerintah, kapan mereka akan berhenti menggunakan IE 11 sama sekali tidak diketahui :(

@MatthewHerbst kapal yang sama, klien kami menggunakan IE 11 dan kami memiliki lalu lintas yang cukup

Hanya ingin berpadu untuk mengatakan ini semua sangat menarik. Satu hal yang saya baca yang membuat saya khawatir adalah:

mungkin saja kami tidak akan mencoba untuk memperhalus beberapa perbedaan browser yang ada

Saat ini saya senang mengetahui bahwa sistem acara React akan "Hanya Bekerja" di browser apa pun yang didukung React. Saya khawatir perubahan ini akan berarti bahwa itu akan menjadi tanggung jawab aplikasi untuk memperhitungkan masalah lintas browser. Ini kemungkinan akan memperkenalkan banyak bug yang sulit dilacak. ...setidaknya untuk aplikasi saya. :)

Bagaimanapun, terima kasih seperti biasa untuk perpustakaan yang hebat.

@kentcdodds telah menyebutkan integrasi JSX 2.0 sebagai ide yang mungkin saya baca melalui Strategi dan tidak melihat apa pun yang tampaknya terkait dengan itu. Saya bertanya-tanya apakah itu hanya di udara atau sesuatu yang akan ditunda untuk masa depan?

Biarkan IE mati! Jangan mendukung browser yang benar-benar ketinggalan jaman. Tidak ada alasan, bahkan untuk perusahaan yang membatasi, untuk tidak beralih ke browser terbaru. Anda akan melihat bahwa IE11 dalam statistik Anda sampai Anda dan web berhenti mendukungnya.

@hbroer Perangkat lunak lama?

@hbroer tidak ada yang tetap menggunakan browser lama karena situs mereka masih berfungsi, mereka melakukannya karena mereka tidak punya pilihan, atau tidak tahu cara memperbarui. Melanggar situs untuk pengguna ini sangat berbahaya dan membuat mereka tidak memiliki browser yang diperbarui, tetapi tanpa apa-apa.

• "tidak tahu cara memperbarui" - bukan masalah kami, tetapi kami dapat memasukkan pesan "instal browser baru" dengan daftar browser dan mungkin dengan teks bantuan dan nomor telepon Microsoft Hotline ^^
• "tidak punya pilihan" - Benar, tetapi organisasi harus memperbarui lingkungan mereka. Jika alat mereka tidak berfungsi, mereka akan melakukannya.

saya benci kode untuk masa lalu dan tidak dapat menggunakan manfaat teknologi baru, karena 90% pembuat kode masih mendukung browser jelek dari 15% konsumen terbawah yang hidup di abad lalu. ^^ Gak mau ini "oh ada apa dengan internet explorer 6 nerd ini, kita harus mendukung 15% itu" lagi untuk 10 tahun ke depan.

btw M$ jahitan untuk membawa Edge untuk Windows 7 dan 8 dengan beralih ke webkit.

@hbroer semuanya adalah masalah kami jika itu berdampak pada pengguna. Memiliki empati untuk manusia lain.

(Secara terpisah, M$ adalah referensi akhir 90-an yang cukup remaja dan sangat tua yang mungkin ingin Anda hapus; Saya senang untuk menghapus ini jika Anda melakukannya)

Begitu, di sini ada banyak M$ fanboiz. :DI benar-benar peduli pada manusia, tetapi tidak pada organisasi yang menghalangi kemajuan teknologi, atau pembuat kode yang bermaksud harus mendukung omong kosong lama itu selama bertahun-tahun. Saya tidak punya masalah dengan paket tambahan yang membuat perpustakaan "kompatibel dengan omong kosong lama". Tetapi perpustakaan pada tahun 2019 harus dikodekan dengan teknologi >=2019, dan bukan teknologi <=2013. Sudah cukup buruk untuk mendukung itu (oh mari kita lakukan ini sedikit dengan cara lain) safari dan omong kosong tepi (lama).

tetesan mikro

@hbroer sebenarnya browser android kuno, dan safari kuno, lebih merupakan masalah daripada browser microsoft mana pun. ini bukan tentang menjadi "fanboi" tetapi menjadi profesional, dan menggunakan istilah "M$" bukanlah.

Dan tidak, itu tidak "buruk" dengan cara apa pun untuk mendukung teknologi lama, itu adalah hal moral dan etis yang harus dilakukan. Yang buruk adalah situs web yang "berfungsi paling baik di X", entah itu Netscape Navigator, IE 6, atau Chrome terbaru.

Begitu, di sini ada banyak M$ fanboiz.

@hbroer Saya melihat di sini seseorang dengan serangan selimut ad hominem.

Tetapi perpustakaan pada tahun 2019 harus dikodekan dengan teknologi >=2019, dan bukan teknologi <=2013.

Tidak, seharusnya tidak.

Jika Anda mengambil satu detik dan melihat ke daftar browser default, Anda akan terkejut. Sebaliknya, Anda menggunakan serangan ad hominem dan penghinaan tingkat kafetaria sekolah.

Setelah Anda mendapatkan cukup banyak pengguna, IE11 menjadi bagian yang cukup besar dari orang-orang yang mengakses situs web Anda. Pada pekerjaan sebelumnya, kami memiliki hampir satu juta orang per bulan yang mengakses situs web kami dari IE11.

Jika Anda ingin mendukung omong kosong lama, tambahkan isian poli. Tidak ada alasan untuk tidak membuat kode untuk masa depan dan masa kini. Mendukung teknologi lama membuat aplikasi web lebih gemuk dan lebih lambat dari yang dibutuhkan.

Ps saya melihat orang yang tidak bisa membaca sarkasme dan tidak peduli dengan senyuman ^^

@hbroer Anda menunjukkan bahwa IE11 adalah hadiahnya, jadi kami diharapkan untuk mengkodekannya.

Dan, sekali lagi. Lihat nilai default di https://browserl.ist.

Ps saya melihat orang yang tidak bisa membaca sarkasme dan tidak peduli dengan senyuman ^^

Ya, tidak. Ini adalah taktik umum yang digunakan oleh troll dan pengganggu taman bermain. "Apa?! Aku tidak menghinamu! Itu hanya lelucon!".

0,20% orang di planet ini, bahkan disaring oleh "mereka yang menggunakan internet", adalah 6,4 juta manusia. Persentase sama sekali tidak relevan. Kode untuk manusia; masa lalu dan masa depan, dan ukuran bundel Anda, tidak masalah.

Jika Anda ingin membuat kode untuk ukuran bundel manusia, seperti kompatibilitas browser, tentu saja penting. Pengguna tidak hanya mengharapkan segala sesuatunya berfungsi, tetapi juga harus cepat dimuat.

Sekarang pada tahun 2019 saya akan menggunakan untuk proyek baru css grid (yang hanya memiliki dukungan eksperimental pada IE11), dan akan berubah menjadi ES6 dan saya tidak ingin mengirimkan polyfill untuk Browser yang sudah ketinggalan zaman itu. Pengguna IE11 hanya mendapatkan pesan: Perbarui browser Anda atau gunakan alternatif.

Ada orang di luar sana yang tidak ingin menggunakan skrip java. Anda peduli tentang mereka? Anda tidak melihat orang-orang itu dalam statistik. Dan saya tidak dalam statistik juga, seperti banyak orang lain yang memblokir alat itu.

Saya memperhatikan setiap browser yang tidak ketinggalan zaman. Saya mendukung edge, yang memiliki lebih sedikit pengguna daripada omong kosong IE11 itu, karena Windows 7 (yang mendukung berakhir Januari 2020), dan orang modern menggunakan browser modern. ^^

Tidak ada yang menghentikan Anda menggunakan polyfill dan sesuatu seperti paket kompatibilitas. Tapi intinya harus up to date dan tidak tertinggal jauh hanya karena satu bagian dari browser teknologi M$ lama.

Apa yang saya lewatkan di banyak kerangka kerja javascript adalah LTS. Itu yang bisa kita bicarakan. Jika Anda membangun halaman modern dengan fitur-fitur dari masa kini, maka bagus untuk menggunakan kerangka kerja teknologi terkini. Dan jika Anda sedang membangun aplikasi web untuk hal-hal b2b yang membutuhkan stabilitas dan kompatibilitas maksimum, maka Anda dapat menggunakan versi LTS. Atau gunakan knockout. Maka Anda dapat mendukung beberapa 100t orang yang masih menggunakan windows XP yang tidak diperbarui dengan IE6 ^^

Kompatibilitas jelas tercantum di bawah "pertukaran" di posting asli sehingga memiliki dukungan sempurna untuk browser lama sudah menjadi fokus sekunder.

Mereka akan membutuhkan lebih banyak polyfill dan integrasi jika Anda perlu mendukungnya tetapi itu akan menjadi pilihan Anda untuk melakukannya. Anda juga dapat membuat beberapa bundel untuk target browser yang berbeda dan mengirimkan JS sekecil mungkin untuk setiap pengunjung sehingga tidak akan memengaruhi seluruh audiens Anda.

Progres di React Fire sendiri sepertinya tidak terpengaruh sehingga tidak ada yang bisa didapat dari perdebatan ini. Mari kita lanjutkan dan kembali ke topik utama.

Apakah ini kesempatan yang baik untuk menyelesaikan #6410? Tampaknya berdampak serupa dengan perubahan yang diusulkan pada onChange / onInput .

Pembaruan dari 5 Juni 2019

Sudah lama. Berikut adalah pembaruan kecil di tempat kami berada.

Kami mulai mengerjakan Fire pada bulan Desember. Ada beberapa pekerjaan dalam proses di https://github.com/facebook/react/pull/14382 dan utas lainnya. Namun, saat kami mulai menghapus bagian dari sistem peristiwa yang kami anggap tidak perlu atau ketinggalan zaman, kami menemukan banyak kasus tepi yang sangat membantu dan mencegah bug — bahkan di browser modern. Kami masih ingin mengurangi kelebihan lama, tetapi tidak jelas apakah lebih dekat dengan peristiwa DOM mentah adalah arah terbaik dalam praktiknya. Mengurangi kode perpustakaan hanya untuk menambahkannya kembali beberapa kali dalam kode aplikasi bukanlah tradeoff terbaik. Dan bahkan tidak selalu mungkin untuk memperbaikinya di tingkat aplikasi.

Secara terpisah, saat bekerja di FB5 , kami menyadari bahwa bahkan saat menggunakan React, hari ini ada kesulitan yang signifikan dalam mengimplementasikan antarmuka pengguna yang berfungsi dan terasa hebat pada mouse dan perangkat sentuh. Bahkan hal-hal dasar seperti tombol terasa sangat berbeda dengan mouse dan sentuhan saat Anda menggunakan acara seperti onClick , dan semakin sulit untuk mencapai perilaku yang konsisten dengan mengarahkan kursor, fokus, dll.

Jadi ketika kami mulai mengerjakan Fire, kami berpikir bahwa mungkin sistem acara khusus tidak diperlukan. Tetapi setelah membuat prototipe menghapusnya, kami menyadari bahwa sistem acara kami sebenarnya adalah tuas terbesar kami untuk memperbaiki rangkaian masalah ini .

Sebagai hasil dari penyelidikan ini, kami telah menghentikan sementara pekerjaan pada item lain yang merupakan bagian dari React Fire, dan memutuskan untuk fokus hanya pada sistem event terlebih dahulu. Proyek itu dikenal sebagai React Flare (https://github.com/facebook/react/issues/15257). Ini cukup menantang dengan sendirinya dan memengaruhi item lain dalam daftar ini, jadi kami berfokus pada hal itu terlebih dahulu secara terpisah.

Tujuan React Flare adalah untuk memudahkan pembuatan UI yang terasa hebat di desktop dan seluler, dengan mouse dan sentuhan, dan dapat diakses. Ini mencakup API deklaratif untuk mengelola interaksi seperti Press, Hover, dan Focus. Tidak seperti sistem event React saat ini, desain Flare tidak mengembang bundel untuk event yang tidak Anda gunakan — dan seharusnya memungkinkan untuk mengurangi jumlah kode di library UI yang menangani event mouse dan sentuh.

React Flare masih merupakan eksperimen, tetapi kami cukup yakin dengan arah keseluruhannya, dan berencana untuk membuatnya tersedia secara resmi di open source. (Untuk saat ini hanya berfungsi jika Anda membangun secara manual dari master, dan tidak ada jaminan semver karena kami secara aktif mengerjakannya.) Seperti Fire, "Flare" hanyalah nama kode — pada saat kami mengirimkannya, itu akan memiliki penamaan yang tepat, dokumentasi, dll. Mungkin react/events atau sesuatu seperti ini. Kami juga ingin menawarkan acara yang setara di React Native pada akhirnya.

Setelah kita menyelesaikan implementasi awal React Flare, kita akan kembali ke daftar React Fire dan mengevaluasi kembali semua poin lainnya menggunakan apa yang telah kita pelajari darinya. Masih ada kemungkinan bahwa jika Flare mengambil alih rangkaian peristiwa yang "lebih kaya", kita dapat menyederhanakan penanganan peristiwa "dasar" di React DOM dan menghapus sekumpulan polifill. Terima kasih kepada semua orang untuk diskusi sejauh ini, dan saya harap ini bermanfaat.

Kerja bagus! Jadi sistem event masih diperlukan untuk menyeimbangkan event mouse dan touch, tetapi akan ringan dan independen dari React.

Akankah "React Flare" datang sebagai bagian dari paket default React atau memerlukan instalasi tambahan mengingat jumlah API yang akan dikirimkan?

Kami ingin menghindari kode yang tidak digunakan dibundel. Jadi niatnya saat ini adalah untuk ikut serta per API. Mungkin titik masuk terpisah dalam satu paket.

Akankah sistem acara mouse dan sentuh ini memanfaatkan PointerEvent ? Saya tidak melihat penyebutan standar web ini di pembaruan sebelumnya, jadi saya hanya ingin memberitahukannya kepada Anda.

Peristiwa penunjuk adalah peristiwa DOM yang dipicu untuk perangkat penunjuk. Mereka dirancang untuk membuat model peristiwa DOM tunggal untuk menangani perangkat input penunjuk seperti mouse, pena/stylus, atau sentuhan (seperti satu atau lebih jari). Pointer adalah perangkat agnostik perangkat keras yang dapat menargetkan kumpulan koordinat layar tertentu. Memiliki model peristiwa tunggal untuk pointer dapat menyederhanakan pembuatan situs Web dan aplikasi dan memberikan pengalaman pengguna yang baik terlepas dari perangkat keras pengguna.

Dan ini adalah link langsung ke kompatibilitas browser saat ini .

@jonathantneal Ya, sistem baru banyak menggunakan Pointer Events – dengan fallback ke Mouse/Touch event ketika tidak ada dukungan untuk Pointer Events.

Saya khawatir https://github.com/facebook/react/issues/11347 tidak dibahas dalam masalah ini. Bereaksi gagal https://custom-elements-everywhere.com.

Harap pertimbangkan shadow root saat mendesain ulang sistem acara - hanya melampirkan ke root React tidak akan menyelesaikan sebagian besar masalah hari ini, hanya melampirkan ke elemen (https://github.com/facebook/react/issues/9242, https:// github.com/facebook/react/issues/15759, https://github.com/facebook/react/issues/13713, https://github.com/facebook/react/issues/11827

Dalam pembaruan ini: https://github.com/facebook/react/issues/13525#issuecomment -499196939 @gaearon menyebutkan:

Namun, saat kami mulai menghapus bagian dari sistem peristiwa yang kami anggap tidak perlu atau ketinggalan zaman, kami menemukan banyak kasus tepi yang sangat membantu dan mencegah bug — bahkan di browser modern.

Saya ingin tahu apakah daftar kasus tepi ini didokumentasikan di mana saja?

@gaearon sekarang setelah Flare keluar (SCNR), apakah ada rencana yang diperbarui (mengenai pembaruan 5 Juni 2019 ) bagaimana cara melanjutkan?

Dan seperti @trusktr , saya juga ingin #11347 ditangani di sini.

Dapat membagi polyfill menjadi bundel lain terutama yang tidak relevan dengan browser evergreen utama.

Hai semua, sudah lama dan kami telah mencoba beberapa hal ini dan mematikan.

Biarkan saya memberikan pembaruan pada masing-masing:

• Berhenti mencerminkan nilai input dalam atribut value (https://github.com/facebook/react/issues/11896). Ini awalnya ditambahkan di React 15.2.0 melalui https://github.com/facebook/react/pull/6406. Itu sangat sering diminta karena model konseptual DOM orang adalah bahwa value yang mereka lihat di inspektur DOM harus cocok dengan atribut JSX value . Tapi bukan itu cara kerja DOM. Saat Anda mengetik ke dalam bidang, browser tidak memperbarui atribut value . React juga seharusnya tidak melakukannya. Ternyata perubahan ini, meskipun mungkin berguna untuk beberapa kode yang mengandalkan pemilih CSS, menyebabkan serangkaian bug — beberapa di antaranya masih belum diperbaiki hingga hari ini. Beberapa dampak dari perubahan ini meliputi: https://github.com/facebook/react/issues/7179 , https://github.com/facebook/react/issues/8395 , https://github.com/facebook /react/issues/7328 , https://github.com/facebook/react/issues/7233 , https://github.com/facebook/react/issues/11881 , https://github.com/facebook/react /issues/7253 , https://github.com/facebook/react/pull/9584 , https://github.com/facebook/react/pull/9806 , https://github.com/facebook/react/pull /9714 ​​, https://github.com/facebook/react/pull/11534 , https://github.com/facebook/react/pull/11746 , https://github.com/facebook/react/pull/12925 . Pada titik ini jelas tidak layak untuk terus melawan browser, dan kita harus mengembalikannya. Bagian positif dari perjalanan ini adalah berkat kerja tak kenal lelah dari kontributor DOM kami ( @nhunzaker , @aweary , @jquense , dan @philipp-spiess) kami sekarang memiliki perlengkapan uji DOM terperinci yang akan membantu kami menghindari regresi.

Kami masih ingin melakukan ini, tetapi kami telah memutuskan untuk "menyimpan" React 17 untuk memiliki sedikit kemungkinan perubahan pemutusan sehingga dapat fokus pada item berikutnya dalam daftar ini. Jadi perubahan ini akan menunggu hingga React 18.

• Lampirkan acara di root React daripada di dokumen (https://github.com/facebook/react/issues/2043). Melampirkan event handler ke dokumen menjadi masalah saat menyematkan aplikasi React ke sistem yang lebih besar. Editor Atom adalah salah satu kasus pertama yang mengalami hal ini. Situs web besar mana pun pada akhirnya juga mengembangkan kasus tepi yang sangat kompleks terkait dengan stopPropagation berinteraksi dengan kode non-React atau di seluruh root React (https://github.com/facebook/react/issues/8693, https://github .com/facebook/react/pull/8117, https://github.com/facebook/react/issues/12518). Kami juga ingin melampirkan acara dengan penuh semangat ke setiap root sehingga kami dapat melakukan lebih sedikit pemeriksaan runtime selama pembaruan.

Kami melakukan ini di React 17. Ini ternyata merupakan pekerjaan yang sangat besar, tapi untungnya sudah selesai.

• Bermigrasi dari onChange ke onInput dan jangan melakukan polyfill untuk komponen yang tidak terkontrol (https://github.com/facebook/react/issues/9657). Lihat masalah terkait untuk rencana terperinci. Telah membingungkan bahwa React menggunakan nama event yang berbeda untuk apa yang dikenal sebagai event input di DOM. Meskipun kami biasanya menghindari membuat perubahan besar seperti ini tanpa manfaat yang signifikan, dalam hal ini kami juga ingin mengubah perilaku untuk menghilangkan beberapa kerumitan yang hanya diperlukan untuk kasus tepi seperti mengubah input yang dikontrol. Jadi masuk akal untuk melakukan dua perubahan ini bersama-sama, dan menggunakannya sebagai peluang untuk membuat onInput dan onChange bekerja persis seperti yang dilakukan peristiwa DOM untuk komponen yang tidak terkontrol.

Kami kemungkinan akan kembali ke ini, tetapi tidak jelas berapa banyak churn yang layak dilakukan di sini. Jadi ini masih TBD.

• Sederhanakan sistem acara secara drastis (https://github.com/facebook/react/issues/4751). Sistem acara saat ini hampir tidak berubah sejak implementasi awal pada tahun 2013. Ini digunakan kembali di seluruh React DOM dan React Native, jadi tidak perlu abstrak. Banyak dari polyfill yang disediakannya tidak diperlukan untuk browser modern, dan beberapa di antaranya menciptakan lebih banyak masalah daripada yang mereka pecahkan. Ini juga menyumbang sebagian besar ukuran bundel React DOM. Kami tidak memiliki rencana yang sangat spesifik di sini, tetapi kami mungkin akan memotong sistem acara sepenuhnya, dan kemudian melihat seberapa minimal kami dapat membuatnya jika kami tetap mendekati apa yang diberikan DOM kepada kami. Masuk akal bahwa kita akan menyingkirkan peristiwa sintetik sama sekali. Kita harus berhenti menggelegak peristiwa seperti peristiwa media yang tidak menggelembung di DOM dan tidak memiliki alasan yang baik untuk menggelembungkan. Kami ingin mempertahankan beberapa kemampuan khusus React seperti menggelegak melalui portal, tetapi kami akan mencoba melakukan ini melalui cara yang lebih sederhana (mis. mengirim ulang acara). Acara pasif kemungkinan akan menjadi bagian dari ini.

Kami telah mencobanya di awal tahun 2019, dan sistem peristiwa yang benar-benar minimal tidak berjalan dengan baik dalam pengujian internal kami. Ada sedikit normalisasi lintas-browser yang dilakukan React yang masih berguna untuk orang-orang dengan browser lama, atau di area khusus seperti editor input teks kaya menggunakan contentEditable . Karena itu, sebagai bagian dari pekerjaan kami dalam melampirkan acara ke akar, kami telah menghapus banyak abstraksi dari sistem acara sehingga lebih mudah untuk dipahami dan ditingkatkan di masa mendatang. Sebagai bagian dari React 17, kami menghapus "event pooling" yang telah menyebabkan banyak kebingungan, dan kami juga tidak lagi mem-bubble event onScroll . Kami kemungkinan akan mengikuti dengan menghentikan gelembung acara media di React 18, membawa perilaku React lebih dekat ke browser. Kami memang menyimpan beberapa byte dengan sistem acara baru, tetapi mereka diambil oleh fitur baru yang sedang kami kerjakan, jadi itu tidak akan menyebabkan penurunan ukuran bundel secara keseluruhan.

• className → class (https://github.com/facebook/react/issues/4331, lihat juga https://github.com/facebook/react/issues/13525#issuecomment- 417818906 di bawah). Ini telah diusulkan berkali-kali. Kami sudah mengizinkan melewatkan class ke node DOM di React 16. Kebingungan yang dibuat ini tidak sebanding dengan batasan sintaks yang coba dilindunginya. Kami tidak akan melakukan perubahan ini dengan sendirinya, tetapi dikombinasikan dengan semua hal lain di atas itu masuk akal. Perhatikan bahwa kami tidak dapat membiarkan keduanya begitu saja tanpa peringatan karena hal ini membuat ekosistem komponen sangat sulit untuk ditangani. Setiap komponen perlu belajar menangani keduanya dengan benar, dan ada risiko keduanya saling bertentangan. Karena banyak komponen yang memproses className (misalnya dengan menambahkannya), itu terlalu rawan kesalahan.

Ini adalah bagian yang paling kontroversial dari proposal. Sejak itu, kami merilis Hooks, yang mendorong komponen fungsi penulisan. Dalam komponen fungsi, kami biasanya menyarankan menggunakan destructuring untuk props, tetapi Anda tidak dapat menulis { class, ... } karena itu akan menjadi kesalahan sintaks. Jadi secara keseluruhan tidak jelas apakah ini cukup ergonomis untuk benar-benar ditindaklanjuti. Saya pikir masuk akal kita akan meninjau kembali ini di masa depan, atau setidaknya membuat class tidak memperingatkan dan membiarkan orang melakukan apa yang mereka inginkan. Tapi untuk saat ini, kami akan mengesampingkan ide ini.

Hai, ini artikel yang bagus!
Hanya ingin tahu apakah ada rencana untuk mengurangi ukuran prod React-DOM? Untuk aplikasi seluler, ini masih merupakan overhead karena browser akan mem-parsing 100+ KB React-DOM JS dan kemudian modul lainnya. Kemudian JS khusus aplikasi.
Untuk halaman yang kaya konten, ini menyebabkan Pemblokiran yang lebih besar dan TTI yang lebih besar.

Adakah ide kapan kita bisa melihat perubahan seperti itu?

@morevolk-latei Dalam pengukuran Anda, berapa banyak waktu yang dihabiskan untuk menguraikan 100 KB ReactDOM?