Material-ui: [RFC] solusi gaya v5 💅

Hanya untuk beberapa koreksi:

Komunitas React, pada umumnya, telah memilih untuk tidak menggunakan JSS dalam skala besar.

Saya menyarankan agar komunitas React tidak memilih _untuk_ JSS. Mungkinkah itu tidak "dipasarkan" sebaik solusi lainnya?

Kami tidak bertaruh pada kuda yang tepat.

Kami bertaruh pada satu-satunya kuda - itu adalah pacuan kuda satu. Tidak ada solusi lain yang tersedia pada saat itu yang memenuhi syarat.

Emosi terdengar hebat! Saya suka mendapatkan dukungan TS, misalnya, pelengkapan otomatis dan semua manfaat mengetik - dengan CSS-in-JS - saat membuat komponen UI atau gaya, apakah itu masih mungkin?

Bagian terakhir membuatku! Saya ingin membantu dengan melakukan ini di belakang bendera beta atau mengembangkan beberapa fitur:

Semua komposisi yang menggunakan emosi (baik komposisi waktu render atau waktu definisi) menghasilkan satu kelas pada elemen tersebut.
Komponen bergaya TIDAK bekerja dengan cara ini terkait komposisi waktu render (komposisi waktu definisi digabungkan menjadi satu kelas).

Saya juga mencatat bahwa objek tema akan tetap sama, - menurut pendapat saya - cara terbaik mutlak untuk memberi tema pada aplikasi! Saya tidak punya apa-apa lagi untuk dikatakan: heran:

Terima kasih atas kerja bagus di M-UI. Saya suka arah proyek ini.

Pindah ke cara penataan yang lebih standar adalah cara yang harus dilakukan. Saya tahu tim dan komunitas akan mengatasi masalah ini, dan v5 - menurut suaranya - akan menjadi lebih hebat! :roket:

Sebagai seseorang yang telah menggunakan komponen gaya dan emosi, saya dapat memastikan bahwa transisi di antara keduanya itu mudah dan tidak menyakitkan.

+ emosi lebih ramah tulisan

Berbicara sebagai pemelihara Emosi - kedengarannya bagus 🚀

Kami juga harus dapat segera merilis mayor baru yang tidak akan menjadi revolusi apa pun, hanya beberapa pembersihan, peningkatan keseluruhan, kait di bawah kap, dan peningkatan jenis TS (inferensi dan kinerja yang lebih baik).

Oh, dan parser ditulis ulang! yang menghilangkan beberapa bug edge di Emotion dan Styled-Components (seperti saat ini, keduanya menggunakan parser yang sama). Ini lebih kecil dan lebih cepat.

Bagaimana dengan perubahan yang melanggar, opsi mana yang memperkenalkan lebih banyak perubahan yang melanggar (jika ada)?

Tidak yakin apakah itu membuat perbedaan tetapi apakah tolok ukur dilakukan dengan emosi dan / atau plugin babel komponen gaya? Mereka membantu mengoptimalkan lebih lanjut.

Menurut pemahaman saya, MUI sebelumnya sudah mengindikasikan akan bergaya jadi ini kejutan. Menurut saya emosi adalah perpustakaan yang hebat, tetapi dengan lebih banyak orang yang menggunakan gaya saat ini, penting bagi Anda untuk menemukan cara memberi mereka pilihan yang baik jika mereka tidak ingin berpindah ke emosi.

@ ee0pdt Emosi sangat, sangat mirip dengan gaya. Saya pikir itu adalah bagian dari keseluruhan pilihan Emosi daripada komponen gaya. Ada manfaat yang jelas, dan hutang migrasi sedikit atau tidak sama sekali.

Dan ada keseluruhan bagian tentang mendukung keduanya dengan memberikan pilihan kepada pengembang. Itu bisa menjadi cara untuk pergi, tetapi sekali lagi, standarisasi mungkin akan lebih membantu kita di masa depan. Konkurensi penuh dan tanpa komponen pembungkus adalah pemecah kesepakatan bagi saya. Saya mengerti bahwa orang lain mungkin menginginkan sesuatu yang bergaya, dan itu harus dipertimbangkan. Saya lebih suka mendorong ke arah standardisasi

Mengapa styletron-react dikesampingkan? Ini meninggalkan seluruh metrik yang tidak dipertimbangkan, yaitu konsumsi memori. Mesin styletron default (dan fela) adalah atom. Meskipun sedikit lebih lambat, ini menghemat banyak memori. Setelah melihat banyak halaman react tidak melakukan apa-apa dan menjadi> 1GB setelah beberapa saat itu agak mengkhawatirkan. Browser macet setelah itu.

Dengan kerangka kerja atom, kinerja meningkat dari waktu ke waktu secara global, di seluruh komponen karena setiap "kelas" atom di-cache. Kemungkinan juga tidak tercermin dalam tes.

Senang dengan baik asalkan mendukung SSR

Saya baru saja menarik suara saya dari masalah komponen bergaya asli: sweat_smile: - pertama kali belajar mengetahui emosi melalui buku cerita, tetapi It will mean that all components styles need to be created using the styled API, which means for developers they will always have wrapper components if they need to re-style. membuat saya beralih.

Terima kasih semuanya atas umpan balik cepatnya. Berikut adalah jawaban dari beberapa komentar / pertanyaan.

Bagaimana dengan perubahan yang melanggar, opsi mana yang memperkenalkan lebih banyak perubahan yang melanggar (jika ada)?

@ sag1v menggunakan styled-components vs emotion tidak memperkenalkan lebih banyak atau kurang perubahan yang mengganggu yang perlu kita tangani. Keseluruhan perubahan yang melanggar akan berada di sekitar bagaimana timpaan di dalam tema akan terlihat:

// previosly
root: {
  contained: {
    '&$disabled': { // <-- this part will need to be transformed
      color: 'red',
    },
  },
  containedPrimary: {
    color: 'blue',
  },
}

// after
root: {
  contained: {
     '&.Mui-disabled': {
      color: 'red',
    },
  },
}

Namun karena sintaks gaya antara emotion & styled-components identik, tidak akan ada bedanya.

Tidak yakin apakah itu membuat perbedaan tetapi apakah tolok ukur dilakukan dengan emosi dan / atau plugin babel komponen gaya? Mereka membantu mengoptimalkan lebih lanjut.

@ hc-codersatlas tidak, tetapi kinerja itu tetap berada di antara beberapa teratas, jadi saya tidak percaya itu akan membuat perbedaan. Panggilan yang bagus, tangguh!

Mengapa styletron-react dikesampingkan? Ini meninggalkan seluruh metrik yang tidak dipertimbangkan, yaitu konsumsi memori. Mesin styletron default (dan fela) adalah atom. Meskipun sedikit lebih lambat, ini menghemat banyak memori. Setelah melihat banyak halaman react tidak melakukan apa-apa dan menjadi> 1GB setelah beberapa saat itu agak mengkhawatirkan. Browser macet setelah itu.

Dengan kerangka kerja atom, kinerja meningkat dari waktu ke waktu secara global, di seluruh komponen karena setiap "kelas" atom di-cache. Kemungkinan juga tidak tercermin dalam tes.

Komentar saya tentang mengapa styletron-react dikesampingkan mungkin agak menyesatkan maaf tentang itu, akan segera memperbarui deskripsi PR. Performanya bagus, tetapi perhatian terbesar saya dengan styletron adalah komunitasnya: https://www.npmtrends.com/styletron-react-vs-@emotion/core -vs-styled-components Baik emosi maupun komponen gaya lebih dari 2000000 unduhan dalam 6 bulan terakhir, styletron sekitar 15000.

Juga atomic css dapat menyebabkan masalah dengan penggantian, karena setiap nama kelas hanya berisi satu aturan styler.

Saya punya pertanyaan jika kami memutuskan menggunakan emosi kami ingin menambahkan kode di bawah ini di atas semua file?
/ ** @jsx jsx * /
Ini adalah pragma JSX, secara default pragma JSX adalah React.createElement

Anda perlu menambahkannya jika Anda menggunakan properti css dalam emosi. Untuk API styled serta API className biasa, Anda tidak membutuhkannya.

Dimungkinkan untuk melewati penambahan pragma JSX, tetapi memerlukan penyiapan Babel tambahan dan dilengkapi dengan dukungan yang lebih buruk dari perkakas - misalnya, TS tidak dapat memeriksa jenis-memeriksa properti CSS Anda seakurat seperti saat menggunakan pragma JSX. Informasi lebih lanjut dapat ditemukan di sini: https://github.com/emotion-js/emotion/pull/1941/files#diff -9abe25e5d2b00958d4b9849f5f20c139R5

@jamur_kejang Saya hanya berharap penggunaan memori tercakup lebih dari sekadar menjamin styletron pada khususnya. Mengenai unduhan atau komunitas - Uber "hanya" menggunakan styletron :) jadi jangan khawatir. Memilih emosi di tempat pertama.

Akan lebih keren jika ada plugin babel atau sejenisnya yang dapat mengubah gaya statis menjadi kelas css nyata. Sudah ada perpustakaan serupa yang disebut compiled . Kebanyakan gaya secara realistis bersifat statis.

Agar berguna, Fela memerlukan seperangkat plugin seperti fela-plugin-rtl , fela-plugin-prefixer yang akan membuat kinerja menjadi lebih buruk (https://github.com/microsoft/fluentui/pull/12289) 🐢 Dan kemudian Anda mungkin akan berakhir dengan Emosi (https://github.com/microsoft/fluentui/pull/13547) karena terkadang bisa dua kali lebih cepat dari Fela

Satu-satunya kekhawatiran saya adalah menggunakan css thingy dari Emotion. Itu adalah tanda bahaya besar berdasarkan pengalaman saya. Saya harus menghapus hal seperti itu dari basis kode besar dan tidak menyenangkan. Mengapa? Karena ini adalah abstraksi yang membawa lebih banyak masalah daripada yang bisa diselesaikan dalam jangka panjang.

Sebagian besar waktu, kami mencoba menggunakan fungsi styled , tetapi kami cukup senang dengan fungsi makeStyles untuk menghasilkan beberapa kelas dalam beberapa kasus.

Mudah-mudahan, tidak ada perubahan yang mengganggu untuk kedua API tersebut, dan saya tidak dipaksa untuk menggunakan makro css .

Satu-satunya perhatian saya adalah menggunakan css thingy dari Emotion.

@yordis Anda pasti tidak akan dipaksa untuk menggunakan properti css . Saya menduga akan ada beberapa tingkat perubahan untuk penggunaan makeStyles dan withStyles . Mudah-mudahan jumlah perubahan yang diperlukan sebagian besar dapat dibatasi pada codemod pada impor. Saya rasa pendekatan yang digunakan dalam makeStyles atau withStyles akan praktis untuk mendukung penggunaan emosi, jadi saya mengharapkan dukungan berkelanjutan dari API tersebut melalui paket terpisah (sehingga " @ material-ui / core "tidak lagi memiliki ketergantungan JSS) yang mungkin hanya akan menerima pemeliharaan minimal setelah v5 dirilis (detail seputar apa yang terjadi pada makeStyles dan withStyles belum dipastikan Namun, jadi ini hanyalah spekulasi saya tentang implikasi dari bergerak maju dengan emosi).

👍 pilihan untuk menggunakan Emosi. Menghindari styled API dari styled-components adalah salah satu alasan tim saya memilih Emotion (yang juga mendukung serupa styled API selain css prop). Kami saat ini menggunakan kustomisasi gaya Emotion for Material UI dan berfungsi dengan cukup baik. Dukungan yang dibangun hanya akan menjadi lapisan gula pada kue.

Mengenai fakta ini:

Banyak pengembang menggunakan komponen bergaya untuk mengganti gaya Material-UI. Pengguna akhir menemukan diri mereka dengan dua pustaka CSS-in-JS dalam bundel mereka

Mendukung mode bersamaan
gaya-komponen: Parsial

Jika komponen bergaya memiliki dukungan penuh untuk mode bersamaan, apakah itu pilihan yang lebih masuk akal, mengingat sebagian besar pengembang mengganti MUI dengan komponen bergaya (tidak termasuk JSS)? Poin tentang emosi yang lebih kecil dalam ukuran bundel diperdebatkan jika 2 solusi css-in-js perlu disertakan. Dan saya menganggap sebagian besar aplikasi praktis MUI melibatkan penggantian gayanya.

Saat saya dan tim saya menggunakan Emosi sebagai cara utama komponen gaya, saya menemukan beberapa inefisiensi yang ada di perpustakaan emosi. Dan saya ingin tahu apa pendapat kalian tentang inefisiensi yang dijelaskan di bawah ini.

Pertimbangkan di bawah Emotion StyledComponent;

const StyledComponent = styled.div`
  ${({color}) => color && `color: ${color}`};
  display: flex;
  justify-content: center;
  align-items: center;
  background: teal;
  font-size: 20px;
  padding-top: 8px;
  padding-bottom: 8px;
  margin-top: 12px;
  margin-bottom: 12px;
  border: 1px solid grey;
`

Ketika color prop mengubah kelas css baru dibuat dengan semua props css ( display: flex, justify-content, ..., border: 1px soild grey ) disalin. Yang akan menghasilkan kelas css dengan props css yang sama persis untuk setiap prop warna, lihat di bawah;

Inefisiensi lain yang kami temukan adalah ketika komponen baru diturunkan dari atas StyledComponent itu akan membuat kelas baru dengan semua props css disalin dari basis StyledComponent . Pertimbangkan di bawah ini;

const DerivedComponent = styled(StyledComponent)`
  font-family: monospace;
`

Ini menciptakan kelas css lain yang hanya menambahkan font-family: monospace ke kelas css di atas yang dihasilkan dari StyledComponent . Artinya, Ini membuat css yang memiliki semua props yang disalin dari StyledComponent seperti yang dapat dilihat di bawah;

Sekarang jika di atas StyledComponent dan DerivedComponent digunakan bersama, kita (awalnya) memiliki dua kelas css yang memiliki properti css duplikat, (hanya berbeda dalam font-family). Seperti yang bisa dilihat di bawah ini;

Seperti yang dapat Anda bayangkan, sejumlah kelas css yang memiliki properti css duplikat satu sama lain dapat berkembang cukup cepat.

Saya menemukan bahwa dengan Emosi, karena gaya komponen disusun bersama, kita berakhir dengan kelas css dengan banyak properti css duplikat.

Saya tidak yakin duplikat alat peraga css di setiap kelas css ini memiliki dampak yang nyata pada aplikasi, tetapi saya ingin tahu apakah ini diperhitungkan dalam memilih untuk menggunakan emosi.

Saya tidak mempertanyakan kinerja Emosi dalam membuat dan menerapkan CSSStyle pada saat dijalankan. Emosi adalah salah satu yang tercepat dalam menerapkan gaya CSS sebagaimana dibuktikan dalam tes kinerja.
Saya hanya khawatir CSSstyle yang dihasilkan membengkak. Dan karena Emosi dapat berupa SSR (ed) yang berarti gaya sebaris dalam HTML, kita mungkin saja mendapatkan file HTML yang membengkak (dengan tag gaya css) yang tidak perlu. Yang pada gilirannya menghasilkan lebih banyak tag untuk diurai dengan alat peraga css yang tidak perlu oleh browser.

Jika komponen bergaya memiliki dukungan penuh untuk mode bersamaan, apakah itu pilihan yang lebih masuk akal, mengingat sebagian besar pengembang mengganti MUI dengan komponen bergaya (tidak termasuk JSS)? Poin tentang emosi yang lebih kecil dalam ukuran bundel diperdebatkan jika 2 solusi css-in-js perlu disertakan. Dan saya menganggap sebagian besar aplikasi praktis MUI melibatkan penggantian gayanya.

@petermikitsh alasan mengapa kami menyimpulkan tentang emosi sebenarnya adalah empat poin dalam kesimpulan

• Biaya migrasi kecil antara komponen gaya dan emosi
  Pengembang yang sudah menggunakan komponen bergaya seharusnya dapat menggunakan emosi dengan hampir tanpa usaha.
• Ada beberapa cara berbeda untuk menambahkan penggantian selain komponen pembungkus
  Dukungan cx + css dari emosi dapat bermanfaat bagi developer untuk menggunakannya sebagai alternatif untuk menambahkan style override jika tidak ingin membuat komponen pembungkus.
• Mode bersamaan pasti didukung 👍
• Bagaimana spesifisitas ditangani

Pertama-tama, jika pengembang benar-benar ingin menghindari dua solusi css-in-js dalam bundel, biaya migrasi sangat kecil untuk berpindah ke emosi + mendukung API yang berbeda selain styled .

@ ko-toss terima kasih telah menulis ini semua adalah poin yang bagus. Fakta bahwa emosi menghasilkan satu className dengan semua gaya, menjadikannya mesin yang lebih baik untuk menyelesaikan penggantian. Masalah yang mungkin kita hadapi dengan menghasilkan beberapa classNames adalah bahwa kelas terakhir yang ditulis akan menang, yang mungkin menjadi masalah di masa mendatang.

Di proyek lain, saya menggunakan atomic css, di mana dari konsumsi memori jauh lebih baik karena semua aturan css ditulis hanya sekali, tetapi melakukan penggantian yang dapat diprediksi di sana cukup sulit, karena setiap className adalah satu aturan atom, dan daripada lagi mana yang menang, tergantung pada urutan penulisannya, jika Anda tidak memutuskan untuk memproses semua gaya sebelumnya dan menggabungkannya dengan benar, yang pada akhirnya dapat memengaruhi kinerja.

Di sisi lain, saya percaya bahwa dengan menggunakan solusi css-in-js, orang tidak hanya akan membuat kombinasi gaya yang tak terbatas secara acak, mereka masih cukup terstruktur berdasarkan nilai properti.

Namun, sekali lagi ini adalah poin bagus, yang akan kami pikirkan, terima kasih banyak telah membagikannya 👍

• lain?

bagaimana dengan kompatibilitas ide [stylex] (seperti [style9])

• lain?

style9 atau mesin CSS lain yang kompatibel dengan ide stylex

Ini tampaknya memerlukan pengaturan waktu pembuatan yang akan membuat banyak orang enggan menggunakannya, terutama pemula.

(ini agak FYI, emosi adalah pilihan yang baik)

https://github.com/cristianbote/goober (1kB, perf sedikit lebih buruk dari emosi)

Saya belum memiliki pengalaman dengan itu tetapi saya ingin mencobanya suatu hari nanti.

@cztomsik Mirip dengan https://github.com/kuldeepkeshwar/filbert-js tetapi tidak memiliki dukungan sintaks JavaScript (hanya string template CSS)

Berikut adalah beberapa tes yang dilakukan dengan mercusuar google pada waktu interaksi:

https://jantimon.github.io/css-framework-performance/

FYI, saya telah melakukan beberapa patokan terperinci dari komponen-gaya v5, emosi v10, dan emosi v11, dengan / tanpa plugin babel, dengan API vanilla, API alat peraga css, dan API bergaya. Semoga ini bisa membantu diskusi!

https://github.com/simnalamburt/css-in-js-benchmark

Apakah Anda mempertimbangkan gelombang baru pustaka css-in-js yang sangat bergantung pada dukungan atomic css dan skrip?

• https://github.com/modulz/stitches
• https://github.com/kripod/otion

Apakah Anda mempertimbangkan gelombang baru pustaka css-in-js yang sangat bergantung pada dukungan atomic css dan skrip?

• https://github.com/modulz/stitches

• https://github.com/kripod/otion

Ini tidak sesuai dengan patokan, tapi saat ini otion 2 ~ 4 kali lebih lambat dari emosi. Menurut saya otion memang memiliki potensi yang cukup besar dan meyakini masih ada ruang untuk optimalisasi, namun otion belum benar-benar siap untuk diproduksi.

Aku belum menguji jahitannya. 😃

Bagaimana dengan pustaka zero-runtime yang sebenarnya? Saya belum pernah melihat siapa pun yang menyebutkan linaria .

Saya menemukan linaria di beberapa titik dan saya sangat menyukainya. Satu-satunya kekhawatiran saya adalah bahwa gaya alat peraga dinamika hanya bergantung pada variabel css, dan tidak ada dukungan untuk IE 11 berdasarkan https://github.com/callstack/linaria/issues/445 Juga dibandingkan dengan styled-components dan emotion komunitas saat ini jauh lebih kecil.

@Tokopedia
Linaria luar biasa.
Jika Anda mengaturnya dengan benar, saya yakin ini adalah yang terbaik dari css-in-js (dalam hal pengalaman dev), dan css murni (tidak dapat mengalahkan kinerja css murni). Ia bahkan mengoptimalkan (dedupes) dan menggunakan kembali aturan css.
Tetapi linaria membutuhkan langkah build dan bundling yang akan sulit bagi pemula.

Saya ingin melihat port untuk pustaka css-in-js lainnya dengan permukaan API yang serupa misalnya filbert-js / goober

@kuldeepkeshwar Kami akan memberi tahu Anda setelah kami memeriksa adaptor untuk API bergaya :)

Bagaimana https://compiledcssinjs.com/ cocok dengan semua ini? Tampaknya ini merupakan pendekatan yang sangat menarik; Compiled juga menjalankan RFC untuk proyek tersebut, yang terbukti bagus untuk open source dan kolaborasi. _kedip kedip_

Saya pikir masa depan sangat, sangat cerah untuk menata web, dan saya berharap Material-UI akan menjadi bagian integral dari solusi masuk untuk menata aplikasi apa pun.

Penjelasan tentang bagaimana Compiled bekerja membuat saya:

Jenis transformasi ini memungkinkan kami mengirimkan komponen Anda ke konsumen mana pun tanpa memerlukan mereka untuk mengonfigurasi / menyiapkan perkakas mereka. Cukup impor dan pergi. Ini kuat, dan yang lebih penting, sama seperti CSS saat ini di pustaka JS bekerja - dengan satu tangkapan.

_CSS tidak dapat dibuat saat runtime._

Kendala tunggal ini membuka banyak pintu bagi kami. Bangun pengoptimalan waktu. Jaminan waktu proses. Kemacetan kinerja hilang.

Di sisi lain, saya ingin menunjukkan bahwa popularitas tidak berarti banyak untuk proyek yang bagus. Saya mencintai MUI dan pekerjaan yang telah dilakukan sejauh ini; Saya juga berpikir itu luar biasa karena telah menjadi produk premium.
Tetapi memilih _name_ 'populer' demi popularitas bukanlah argumen yang masuk akal.
Saya telah melihat popularitas direferensikan beberapa kali, dan saya sangat tidak suka bahkan mempertimbangkan jika jumlah x orang menggunakan teknologi x - MUI (dalam buku saya) berfokus pada kinerja, DX, dan hal-hal lain, hanya saja bukan popularitas.

MUI tidak selalu memiliki 60k bintang, MUI mendapatkannya karena memilih teknologi terbaik (atau mendekati), bukan karena memilih teknologi populer.

Jika memilih berdasarkan suara populer berkaitan dengan proyek yang lebih dapat didekati secara luas, itu urusan bisnis, bukan peningkatan kinerja yang mungkin. Sebuah proyek hidup dengan atau tanpa pengguna. Itu mati dengan pilihan yang buruk. Saya pikir ada begitu banyak pepatah di sekitar ini dan membaca "ini tidak cukup populer, oleh karena itu ini adalah pilihan yang buruk" membunyikan banyak lonceng.

Orang menggunakan produk yang benar karena itu bagus, bukan karena menggunakan teknologi populer; MUI pernah menjadi ceruk tetapi menjadi terkenal meskipun memiliki CSS-in-JS, yang tidak memenangkan suara populer btw. Itu hanya memiliki beberapa properti yang luar biasa dan membuat pilihan yang tepat yang tidak didasarkan pada komunitas saat ini tetapi DX dan kinerja yang sebenarnya.

Catatan samping itu dicatat, saya sendiri berada di pihak pemilihan umum; jadi jika ada, saya juga menyabotase diri saya sendiri. Saya tidak memiliki keuntungan pribadi apa pun dari memilih produk yang jauh lebih populer, saya berpendapat bahwa popularitas tidak boleh dianggap _ sama sekali_ ketika berbicara tentang revolusi dan perubahan. Harap pertimbangkan kembali beberapa opsi ini berdasarkan pada apa sebenarnya opsi tersebut, bukan apa yang orang anggap berdasarkan popularitas opsi saat ini.

Sebagai penutup, saya berterima kasih atas setiap pemikiran dan waktu masuk ke MUI. Saya telah membuat beberapa solusi luar biasa (sayangnya pribadi) mengikuti semua standar, dll. Dalam beberapa tahun terakhir, yang akan memakan waktu berbulan-bulan atau bertahun-tahun untuk membuatnya sendirian! Saya tidak bisa mendeskripsikan apresiasi saya hampir cukup untuk bersinar di atas kertas 🙇‍♂️ 🙏 🙇‍♂️

Saya ingin tahu apakah Compiled bahkan adalah sebuah opsi dan bagaimana cara kerjanya dengan adaptor dan semacamnya. Saya pikir pendekatan yang dikompilasi:

Kompilasi mengkompilasi CSS Anda di JS pada waktu pembuatan dengan menganalisis kode Anda secara statis dan kemudian mengubahnya menjadi Komponen Terkompilasi. Semua yang kita butuhkan untuk menggunakan komponen disertakan di sisinya dalam bundel JavaScript.

adalah cara untuk dipikirkan, dengan mempertimbangkan seluruh batasan 'css pada waktu proses' kompilasi.

Saya mengatakan ini sebagai pemelihara Emosi - Kompilasi bagus. Atau lebih tepatnya - mungkin di masa mendatang, ini adalah hal yang sangat menarik tetapi masih cukup awal dalam eksperimen. Saya sangat meragukan bahwa MUI dapat melakukannya pada saat ini.

Perbaiki saya jika saya salah tetapi dikompilasi menyiratkan memiliki konfigurasi yang berarti wajib memiliki file konfigurasi untuk MUI bahkan tanpa menggunakan gaya kustom apa pun.

Saya tidak suka dipaksa membuat konfigurasi hanya untuk menggunakan MUI. Di samping catatan: bukankah itu sulit untuk digunakan dalam bootstrappers beropini seperti Create React App?

@Andarist Saya setuju sepenuhnya. Saya akan menyarankan untuk memulai kolaborasi atau setidaknya mempertimbangkan untuk berpartisipasi dalam pengembangan perpustakaan. Saya ingin tahu tentang ke mana hal itu bisa mengarah di masa depan! : eyes: Saya pikir sesuatu seperti yang dikompilasi - seperti yang Anda katakan - di masa depan akan menjadi hebat. Sungguh luar biasa jika lebih banyak pemikir hebat berkumpul untuk membuat sesuatu yang luar biasa.

@shilangyu Saya tidak yakin apa yang Anda maksud, karena saya mungkin melewatkan sesuatu. Jadi saya hanya akan mengatakan bahwa halaman depan compiled mengatakan ini tentangnya:

Bermigrasi ke realitas konfigurasi nol

API yang kami sukai ada di sini untuk perjalanan - prop CSS dan komponen nama kelas juga! Konsumen kami bahkan tidak perlu mengubah cara mereka mengonsumsi komponen kami, melanjutkan cerita zero config, mereka tidak perlu mengonfigurasi bundler mereka, juga tidak perlu menyiapkan hal-hal spesifik apa pun untuk rendering sisi server. Ini berhasil.

Hanya awal

Dengan zero config out-of-the-box hari ini, kami tidak melupakan seperti apa hari esok nantinya. Dengan kemungkinan untuk ekstraksi CSS opsional, mengubah CSS menjadi bentuk Atom, dan bahkan dapat menggunakan data CSS untuk analisis di seluruh basis kode kami, kami memikirkan hari esok yang menarik.

@Tokopedia
Saya membaca sekilas https://compiledcssinjs.com/ . Bukankah itu masih runtime css-in-js?
Ini membuat kelas css pada waktu pembuatan tetapi menerapkan gaya itu (membuat tag gaya dengan kelas css yang dihasilkan waktu pembuatan) dengan <CC>...</CC> tag pada waktu proses.
Jika secepat hanya menggunakan css murni maka itu benar-benar masa depan (karena menggunakan variabel css). Terima kasih telah berbagi
Saya bertanya-tanya seberapa cepat itu dibandingkan dengan Emosi.

Bagaimana dengan pustaka zero-runtime yang sebenarnya? Saya belum pernah melihat siapa pun yang menyebutkan linaria.

Apa yang tidak kami sertakan dalam persyaratan adalah bahwa solusi apa pun harus zero-config dari perspektif konsumen Material-UI. Jika saya memahami solusi zero-runtime maka mereka menghasilkan beberapa CSS pada waktu kompilasi. Bukankah saya harus mengatur bundler saya untuk memasukkannya dengan benar?

Jadi, meskipun zero-runtime mungkin merupakan solusi tercepat, hal ini juga membutuhkan perhatian ekstra. Memiliki solusi zero-config yang dapat dikonfigurasi untuk dijalankan dengan zero-runtime akan ideal menurut saya.

Jadi, meskipun zero-runtime mungkin merupakan solusi tercepat, hal ini juga membutuhkan perhatian ekstra. Memiliki solusi zero-config yang dapat dikonfigurasi untuk dijalankan dengan zero-runtime akan ideal menurut saya.

Tidak dapat benar-benar mengatakan tentang keadaan Terkompilasi saat ini tetapi saya membicarakannya beberapa kali dengan pengelola dan ini kira-kira adalah rencananya - idenya adalah untuk mempertahankan dukungan untuk API Komponen Emosi & Bergaya, jadi mengoptimalkan kode yang ditulis itu seharusnya hanya masalah mengubah impor dan termasuk plugin transform atau webpack loader. Itu, pasti, tidak akan menangani semua kode yang mungkin bisa ditulis (JS liar), tapi itu harus bisa menangani kode yang ditulis dengan bijaksana. Jika tidak dapat mengkompilasi sesuatu, file. Ini hanya akan membuang - memaksa seseorang untuk tidak menggunakannya atau menulis ulang bagian tertentu dari kode untuk membantu analisis statis.

Jadi untuk menyimpulkan - jika Anda menggunakan 0config Emotion (atau Komponen Bergaya) maka harus mungkin untuk mengadaptasi Compiled sebagai optimasi opsional di masa depan (jika proyek akan berhasil memberikan apa yang dijanjikan)

@ ko-toss Saya rasa ini dikompilasi ke dalam komponen bergaya pada waktu pembuatan. Saat runtime, gaya dari komponen kemudian dipindahkan ke tempat yang semestinya.

Seperti yang mereka katakan di halaman web:

Semua yang kita butuhkan untuk menggunakan komponen disertakan di sisinya dalam bundel JavaScript.

Kami mengambil kode awal Anda dengan segala kemuliaan:

import { styled } from '@compiled/css-in-js';

export const ColoredText = styled.span`
  color: #ff5630;
`;

Dan kemudian mengubahnya menjadi Komponen Terkompilasi:

...
...

Yang kemudian pada saat runtime akan memindahkan gaya ke kepala dokumen.

Jenis transformasi ini memungkinkan kami mengirimkan komponen Anda ke konsumen mana pun, tanpa memerlukan mereka untuk mengonfigurasi / menyiapkan perkakas mereka. Cukup impor dan pergi. Ini kuat, dan yang lebih penting sama persis dengan pekerjaan CSS saat ini di pustaka JS - dengan satu tangkapan.

CSS tidak dapat dibuat pada waktu proses.

Memiliki solusi zero-config yang dapat dikonfigurasi untuk dijalankan dengan zero-runtime akan ideal menurut saya.

Saya pikir Anda tepat sasaran. Akan terasa utopis jika tiba-tiba melakukan mimpi itu dengan penuh kasih .

Ada beberapa ide untuk dieksplorasi dan mungkin beberapa kolaborasi yang bisa didapat. Beberapa kode dan konsep agak asing bagi saya, jadi saya tidak dalam posisi untuk membahas banyak detail. Berikut beberapa hal yang saya sukai:

• Analisis statis - ini yang besar. Bayangkan saja mendapatkan data tentang cara Anda menggunakan solusi gaya, mendapatkan rekomendasi berdasarkan aturan X, konvensi atau spesifikasi, dan ditampilkan di mana Anda dapat mengoptimalkan
• Konfigurasi nol - meskipun saya akan memprioritaskan lebih banyak kebebasan demi kemalasan (memasang plugin untuk x bundler)
• CSS-in-JSS menjadi CSS murni, pada dasarnya mengekstrak gaya pada waktu kompilasi untuk menyertakannya secara statis, tidak perlu runtime.

Berkenaan dengan dukungan IE11, bagaimana Anda melihat statistik? Saya yakin itu adalah hal yang sangat layak untuk dilakukan. Edge sekarang didasarkan pada chromium, dan sebagian besar bisnis harus beralih ketika MS akhirnya menghentikan dukungan untuk IE ketika setiap OS IE11 diinstal mencapai akhir siklus dukungan mereka. Ini memang siklus yang panjang, tetapi menurut saya pengelola juga memiliki peran dalam mendorong perubahan, dan mempertahankan dukungan untuk sesuatu yang pada dasarnya sudah usang tampaknya memungkinkan orang untuk menunggu sampai 'shift' benar-benar terjadi.

Alangkah baiknya jika memiliki opsi untuk tidak mendukung IE11. Ini bukan standar industri lagi, dan akan ditinggalkan. Ini adalah masalah waktu, dan _default_ dukungan dari hal-hal luar biasa seperti MUI mungkin menahan pergeseran.

Alangkah baiknya jika memiliki opsi untuk tidak mendukung IE11.

Lihat https://github.com/mui-org/material-ui/issues/14420 untuk itu.

Kami tidak berencana untuk sepenuhnya menghentikan dukungan untuk IE. Versi default kemungkinan tidak akan menargetkan IE 11 di v5 tetapi kami tidak dapat memilih solusi yang tidak akan berfungsi sama sekali di IE 11. Atau lebih tepatnya itu harus menjadi solusi yang dapat kami tukar pada waktu pembuatan dan menghasilkan yang sama keluaran.

Ini membuatku senang.

apakah ada mod kode untuk mengubah jss yang ada menjadi gaya / emosi Saya ingin tahu?

Halo semuanya. Saya mengambil kesempatan untuk masuk ke dalam diskusi ini.

Dalam versi saat ini, Material UI banyak menggunakan withStyles HOC tanpa gaya dinamis (gaya menjadi fungsi yang bergantung pada alat peraga), yang secara internal menggunakan makeStyles . Kinerja makeStyles (tanpa alat peraga dinamis) sangat luar biasa dan Material UI bahkan bisa lebih cepat jika menggunakannya secara langsung, daripada withStyles , yang membuat pembungkus yang tidak perlu.

Saya telah membuat sebuah benchmark yang bercabang dari benchmark ini , dan saya menerapkannya ke Vercel, sehingga semua kode dikompilasi dengan flag produksi aktif. Tolok ukur merender kartu menggunakan CSS yang berbeda di pustaka JSS. Berikut tautannya:

Untuk 100 kartu :

• makeStyles : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=mui-make-styles&cards=100
• emotion : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=emotion-styled&cards=100
• styled-components : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=styled-components&cards=100

Untuk 500 kartu :

• makeStyles : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=mui-make-styles&cards=500
• emotion : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=emotion-styled&cards=500
• styled-components : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=styled-components&cards=500

Untuk 2500 kartu :

• makeStyles : https://csb-5z6e2-fqtfkzcrk.vercel.app/?cases=mui-make-styles&cards=2500
• emotion : https://csb-5z6e2-fqtfkzcrk.vercel.app/?cases=emotion-styled&cards=2500
• styled-components : https://csb-5z6e2-fqtfkzcrk.vercel.app/?cases=styled-components&cards=2500

Secara keseluruhan, emotion dan styled-components sangat mirip dalam kinerja. Namun, makeStyles tampaknya 2-4x lebih cepat secara keseluruhan saat pemasangan dan merender 6-8x lebih cepat untuk pembaruan.

Perbedaannya cukup signifikan, terutama saat kita melakukan rendering pada perangkat berdaya rendah, seperti ponsel kita .. dan ada banyak ponsel jelek di luar sana.

Semua ini untuk mengatakan bahwa saya khawatir tentang migrasi materi dan menggunakan emotion secara default, yang akan menurunkan kinerja rendering UI Material dan situs yang menggunakannya dengan faktor 3-5x. (ini sebenarnya tidak benar, ini tergantung pada komponennya; semakin kompleks, semakin sedikit perbedaannya).

Beberapa pertanyaan dan bahan pemikiran:

• Apakah DX benar-benar sebanding dengan pengorbanan UX? Bahkan DX masih bisa diperdebatkan karena banyak yang lebih suka makeStyles
• Masalah dengan makeStyles berkaitan dengan gaya dinamis yang tampaknya bisa diperbaiki dengan mengimplementasikan id cache deterministik. Saat ini, setiap instance komponen mendapatkan ID-nya sendiri untuk props dinamis, meskipun props dan gaya keluaran sama, menyebabkan overhead waktu proses, banyak tag gaya di head, dan penurunan kinerja SSR. Tampaknya dapat diperbaiki dengan menggunakan strategi hashing untuk gaya dinamis, seperti banyak CSS lain di JS libs yang melakukannya. Terkait: https://github.com/mui-org/material-ui/pull/16858
• Apakah ada ruang untuk perbaikan pada emotion dan styled-components untuk lebih dekat, atau bahkan lebih baik dari makeStyles ?
• Akankah Material UI mendukung adaptor mesin JSS resmi sehingga pengembang dapat memilihnya untuk performa lebih?

Saya bisa hidup dengan sedikit kerugian kinerja.

Bukan kehilangan kinerja 300%, tidak dengan biaya berapa pun. 😅

@satazor terima kasih telah menjelajahi ini. Kami melakukan pengujian kinerja yang berat sebelum memulai upaya ini, lihat PR https://github.com/mui-org/material-ui/pull/22173 untuk lebih jelasnya (kami melakukannya pada komponen ListItem) dan perbedaan kinerja ada di paling 10% untuk rendering x1000 instance, dalam mode produksi .

https://deploy-preview-22173--material-ui.netlify.app/performance/list-raw/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-mui/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-styled/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-styled-wrapper/

• Disalin dari https://github.com/mui-org/material-ui/pull/22173#issuecomment -673486269

Berdasarkan ini, kami memutuskan untuk mengabaikan perbedaan ini, karena manfaat yang akan kami dapatkan (alat peraga dinamis di luar kotak, API bergaya yang sudah digunakan oleh sebagian besar pengembang, dll - seluruh ringkasan dapat ditemukan di Deskripsi PR :))

Tidak yakin apa yang terjadi pada tolok ukur Anda, tetapi 3-5x tampaknya terlalu berlebihan bagi saya, itu membuat saya bertanya-tanya mengapa ada orang yang menggunakan emotion / styled-compoenents jika ini masalahnya .. Kita bisa mencoba untuk melihat di mana perbedaan antara kedua tolok ukur tersebut, jika kami melewatkan sesuatu. Selain itu, melakukan benchmark pada komponen MUI yang sebenarnya akan jauh lebih baik menurut saya, jadi kami akan mendapatkan angka yang lebih realistis, jadi beri tahu saya jika Anda ingin menjelajahi lebih banyak tentang sisi ini. Humas yang saya tautkan adalah titik awal yang baik.

Terima kasih atas balasannya @mnajdova. Anda benar bahwa pengujian pada komponen Mui akan lebih realistis. Yang mungkin terjadi adalah kode Mui untuk komponen List adalah faktor kelambatan utama, dan perbedaan di antara keduanya (~ 30 md) adalah perbedaan waktu rendering aktual yang terkait dengan gaya. Saya akan mengambil kode PR itu dan menambahkannya ke benchmark, untuk melihat hasilnya.

Akankah ini menjadi masalah pada akhirnya? Mungkin tidak, tapi itu tergantung aplikasinya. Perbedaan kinerja antara komponen Mui saat ini dan yang bergaya akan meningkat karena kode rendering itu sendiri lebih sederhana. Sebagai contoh, saya mengharapkan untuk melihat perbedaan yang meningkat pada komponen Ikon atau Tipografi, tetapi perbedaan yang berkurang untuk Kartu. Jadi, ini sangat tergantung pada aplikasi dan jumlah komponen dari setiap jenis yang digunakan aplikasi.

yang akan menurunkan kinerja rendering UI Material dan situs yang menggunakannya dengan faktor 3-5x.

Anda telah membuat patokan yang memiliki faktor ini. Tidak berarti setiap komponen akan menunjukkan penurunan ini. Harap mencoba untuk menghindari melompat ke kesimpulan karena informasi yang menyesatkan ini menyebar dengan sangat mudah dari masalah yang terlihat.

Menggunakan ekstensi devtools, saya melihat 140ms untuk mount dengan emosi vs 120ms untuk mount dengan makeStyles.

Anda telah membuat patokan yang memiliki faktor ini. Tidak berarti setiap komponen akan menunjukkan penurunan ini. Harap mencoba untuk menghindari melompat ke kesimpulan karena informasi yang menyesatkan ini menyebar dengan sangat mudah dari masalah yang terlihat.

Anda benar, lihat komentar saya sebelumnya.

Anda telah membuat patokan yang memiliki faktor ini. Tidak berarti setiap komponen akan menunjukkan penurunan ini. Harap mencoba untuk menghindari melompat ke kesimpulan karena informasi yang menyesatkan ini menyebar dengan sangat mudah dari masalah yang terlihat.

Menggunakan ekstensi devtools, saya melihat 140ms untuk mount dengan emosi vs 120ms untuk mount dengan makeStyles.

Saya telah memperbarui tolok ukur untuk menggunakan actualDuration daripada baseDuration , jadi sekarang kita harus melihat nilai yang lebih sejalan dengan apa yang ditampilkan di profiler devtools. baseDuration mengukur waktu tanpa memoisasi, sedangkan actualDuration adalah kebalikannya. Harap perhatikan bahwa perubahan ini hanya memengaruhi kinerja perenderan, dan sekarang saya melihat makeStyles 6-8x lebih cepat untuk perenderan, yang berarti cache / memoization lebih baik? Namun, saya tidak mendapatkan nilai yang Anda lihat. Bisakah Anda mencoba dengan tautan yang diperbarui?

@ satazor Saya tidak berpikir bahwa kasus pengujian Anda setara. Kita harus baik-baik saja.

Beberapa perubahan yang dapat Anda coba pahami dan itu akan mengurangi perbedaan kinerja:

• Memasang komponen react memiliki biaya, terutama saat merender banyak. makeStyles menggunakan div secara langsung sementara emosi / sc membuat komponen baru. Dalam tolok ukur tabel kami, saya telah mengalami bahwa setiap komponen tambahan menambahkan waktu rendering dasar, jadi jika 3 level komponen => x3 (Atau mengapa <MenuItem> hampir x10 lebih lambat dari <li> ).
• Demo Anda dengan makeStyles membuat satu lembar gaya, jangan emosi / sc. Coba gunakan satu lembar gaya dengan pemilih CSS untuk menargetkan item di setiap penampung kartu. Atau lakukan sebaliknya, uraikan stylesheet makeStyles utama menjadi beberapa, satu per item.

Memang, @oliviertassinari. Tampaknya kinerja ke depan dengan komponen emosi / gaya lebih di 1,5x-2x faktor maks bahkan untuk komponen sederhana, seperti Typography , yang telah saya terapkan di sini: https://codesandbox.io/ s / css-in-js-perbandingan-bercabang-lr3sr? file = / src / components / EmotionTypography.js.

Periksa build & benchmark produksi di: https://csb-lr3sr-7lp24bj5l.vercel.app/

makeStyles 1,5-2x lebih cepat saat pemasangan dan 3-4x lebih cepat saat perenderan. Ini mungkin sesuatu yang perlu diperhatikan, tapi saya kira deviasinya akan jauh lebih kecil untuk komponen yang lebih kompleks.

Jadi, sebagai kesimpulan, saya tidak lagi khawatir tentang kinerja dan saya tidak sabar untuk melihat bagaimana upaya ini akan terlihat.

@mnajdova Berikut pembuatan produksi untuk tes Daftar: https://csb-lr3sr-3zi42510w.vercel.app/?components=1000 , disalin dari PR yang Anda sebutkan. Tautan Codesandbox: https://codesandbox.io/s/css-in-js-comparison-forked-6s4nl

makeStyles tampaknya 1,7x lebih cepat saat dipasang, dan 2,2x lebih cepat saat dirender. Saya tidak mendapatkan perbedaan 10% yang Anda lihat. Apakah saya melakukan sesuatu yang salah?

@satazor Menarik, terima kasih telah menyatukannya. Saya telah menggunakan tolok ukur ini dengan # 22435 untuk membandingkan kinerjanya

import Slider from '@material-ui/core/Slider';

vs (emosi).

import SliderStyled from '@material-ui/lab/SliderStyled';

vs (komponen bergaya).

import SliderStyled from '@material-ui/lab/SliderStyled';

Pada titik ini, sulit untuk mengatakan mengapa ini lebih lambat. Hambatan mungkin bukan pada gaya. Dan ingatlah bahwa saya telah menjalankannya dalam mode pengembang ⚠️!

Saya telah menambahkan dua halaman baru untuk melihat performa versi emosi WIP dari Slider:

• https://deploy-preview-22435--material-ui.netlify.app/performance/slider-emotion/
• https://deploy-preview-22435--material-ui.netlify.app/performance/slider-jss/

Setelah dibuat untuk produksi, statistiknya tampaknya mirip dengan https://github.com/mui-org/material-ui/issues/22342#issuecomment -697540546, ini tentang x1.6 lebih lambat (tetapi CSS sepenuhnya dinamis). Perhatikan bahwa Anda dapat memainkannya dengan versi emosi WIP dengan:

• emosi : https://codesandbox.io/s/headless-shadow-fn41t?file=/package.json

• komponen-gaya : https://codesandbox.io/s/preact-material-ui-test-forked-lum1y?file=/src/index.tsx @mnajdova Untuk sc, saya harus menggunakan parsel, saya tidak bisa menggunakan Template CRA.

Juga, perhatikan bahwa kita tahu bahwa kita bisa membuat JSS versi x1.1 lebih cepat dengan menggunakan makeStyles daripada withStyles: # 15023.

@oliviertassinari dalam mode prod semuanya menjadi sedikit lebih cepat, tetapi saya kira perbedaannya tetap ada. Anda dapat mengklik terapkan> vercel pada kotak pasir kode untuk menerapkan dengan cepat dengan flag build produksi.

Melihat bagaimana makeStyles diimplementasikan, saya melihat bagaimana ini lebih cepat ketika Anda hanya menggunakan gaya statis :

1. Di setiap pemasangan, attach dipanggil.
2. Jika ini adalah contoh pertama dari jenis komponen itu, stylesCreator.create dipanggil, yang pada gilirannya memanggil fn ditentukan dalam makeStyles(fn) .
3. Pada setiap contoh lainnya, stylesCreator.create dilewati karena jumlah referensi> 0.

Untuk perender:

1. Pada setiap perenderan, attach dipanggil.
2. Setelah itu, stylesCreator.create dilewati karena ref count> 0, jadi tidak ada pekerjaan sama sekali.

Harap dicatat bahwa jika gaya dinamis ikut bermain, sheet akan diperbarui di sini , di setiap pemasangan dan perenderan ulang.

Sebaliknya, styled-components dan emotion tampaknya menjalankan fungsi styling kami pada setiap instance komponen, yang menghasilkan lebih banyak siklus CPU dan tekanan balik memori. Saya pikir mereka entah bagaimana bisa melakukan multi memoize cache berdasarkan kombinasi props, tetapi ini akan mengasumsikan bahwa fungsi styling murni, yang mungkin tidak terjadi, pertimbangkan:

     const someContext = useContext(FooContext);

    return <div css={ { paddingTop: someContext.padding(1) } }>;

Jika asumsi saya benar, akan sangat sulit untuk mencapai tingkat kinerja makeStyles untuk pembuatan gaya statis, karena cara kerjanya dan bagaimana API dirancang memungkinkan pengoptimalan yang styled atau css API tidak bisa.

Saya melihat beberapa kemungkinan arah yang bisa kita jelajahi:

• Dalam deskripsi masalah awal, kami hanya mengukur kinerja dengan dukungan dinamis Material-UI. Kita bisa menambahkan entri untuk kasus statis (apa yang digunakan v4). Kita juga bisa memiliki case untuk react-jss static & dynamic. Ini akan membantu kami memahami cakupan opsi mesin gaya yang tersedia.
• Kita bisa menyelidiki dimana kemacetannya. Kita bisa membayangkan memiliki adaptor untuk jss, seperti yang kita miliki untuk komponen bergaya, dan melihat apakah kinerjanya lebih baik. Ini seharusnya jauh lebih buruk dengan versi dinamis JSS, tetapi kita dapat membandingkannya dengan versi statis. Mungkin itu datang dari abstraksi tanpa gaya.
• Kami dapat menganggap perlambatan harga yang pantas dikeluarkan untuk membuka gaya dinamis dan tanpa gaya. Jika Anda ingin membuat daftar yang panjang, Anda akan menggunakan virtualisasi atau mengandalkan pemilih CSS bersarang.
  emosi dan komponen gaya telah terbukti memberikan fleksibilitas dan cukup cepat oleh industri, begitu pula React.

Jika entah bagaimana emotion mengekspos useCss hook seperti yang diminta di https://github.com/emotion-js/emotion/issues/1321 dan https://github.com/emotion- js / emosi / issues / 1853 , kita dapat mempertahankan makeStyles API dan akibatnya, manfaat dari "CSS statis". Namun, kami akan tetap menggunakan CSS statis di mana-mana, untuk meningkatkan kinerja, yang tidak terlalu "bersih" tetapi itulah yang sudah kami lakukan di v4.

Sebenarnya, dengan API ClassNames , saya pikir kita bisa membuat port withStyles sekarang yang akan mempertahankan keuntungan dari kinerja CSS statis dan kinerja yang baik dari CSS dinamis yang dimiliki emosi. Jika const css = useCss() ada, maka akan mudah untuk membuat port API useStyles juga.

Keuntungan utama menyimpan API withStyles + makeStyles yang menggunakan emosi di bawah tenda adalah:

• Migrasi yang harus dilakukan material sebenarnya tidak ada, kita hanya perlu membuat port dari 2 fungsi tersebut.
• Pengguna yang sudah menggunakan withStyles dan makeStyles luar UI Material, tidak perlu bermigrasi sama sekali. Mereka akan mendapatkan keuntungan dari peningkatan kinerja untuk CSS dinamis, secara gratis.
• Tidak ada logika tambahan yang diperlukan untuk mempertahankan API CSS classes +. Dengan styled kita perlu membuat className s global dengan tangan, atau dengan util.
• Dalam strategi ini, useCss adalah fungsi adaptor kami untuk CSS dalam solusi JS, bukan styled .
• Untuk mendukung CSS lain dalam solusi JS, mereka perlu menyediakan hook useCss atau yang serupa. Idealnya, kita bisa melakukan webpack / babel aliasing untuk mengubahnya, seperti styled .

Kami telah menjelajahi masalah kinerja lebih lanjut di https://twitter.com/olivtassinari/status/1309247827839680512. Saya pikir kita bisa maju apa adanya. Untuk tim yang sangat peduli dengan kinerja, mereka dapat ikut serta ke dalam komponen tanpa gaya, mereka memberikan kinerja yang lebih baik. Untuk yang lain, seperti kebanyakan industri, emosi dan komponen gaya sudah cukup baik.

• asli: 7.71ms
• v5 tanpa gaya: 20.89ms
• v4: 29.93ms
• v5: 37.37ms
• antd: 53.48ms
• chakra: 64.67ms

https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js…

Maaf saya mengganggu Anda di sini begitu terlambat dalam diskusi tetapi saya sedikit terkejut Anda tidak melihat dari dekat style-jsx

Daftar mereka benar-benar memenuhi kebutuhan Anda:

• Bekerja server dan klien
• Dukungan penuh CSS, tidak ada kompromi dalam kekuatan
• Ukuran runtime hanya 3kb (di-gzip, dari 12kb)
• Isolasi lengkap: Pemilih, animasi, bingkai utama
• Awalan vendor CSS bawaan
• Transpilasi sangat cepat, minimal dan efisien (lihat di bawah)
• Injeksi CSS waktu proses berperforma tinggi saat tidak merender server
• Bukti masa depan: Setara dengan "Shadow CSS" yang dapat dirender server
• Dukungan peta sumber
• Gaya dan tema dinamis mendukung
• Pemrosesan awal CSS melalui Plugin

Saya akan memperhatikan fakta bahwa ini hampir merupakan API standar CSS bayangan . Jadi dengan menghapus atribut jsx Anda dapat beralih ke komponen web di masa mendatang yang sudah berfungsi di browser normal BTW.

Ya, saya tahu itu mungkin bukan yang paling populer.
Tapi saya hanya ingin menunjukkan bahwa Flash sangat populer beberapa tahun yang lalu.
Tapi akhirnya kering karena tidak sesuai dengan standar web, dan kami memiliki SVG sekarang.
Sekadar catatan, standar SVG telah hadir lama ketika Flash menguasai industri.
Saya hanya melihat peristiwa sejarah sebagai pelajaran yang baik dan akan mencoba untuk menemukan pola bahwa popularitas adalah indikator terakhir yang dapat dipertahankan dan bukti masa depan.

@mifrej Saya pribadi punya pengalaman buruk dengannya: https://github.com/vercel/styled-jsx/issues/142.

Kami telah menjelajahi masalah kinerja lebih lanjut di https://twitter.com/olivtassinari/status/1309247827839680512. Saya pikir kita bisa maju apa adanya. Untuk tim yang sangat peduli dengan kinerja, mereka dapat ikut serta ke dalam komponen tanpa gaya, mereka memberikan kinerja yang lebih baik. Untuk yang lain, seperti kebanyakan industri, emosi dan komponen gaya sudah cukup baik.

• asli: 7.71ms
• v5 tanpa gaya: 20.89ms
• v4: 29.93ms
• v5: 37.37ms
• antd: 53.48ms
• chakra: 64.67ms

https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js…

Apakah Anda mencoba plugin babel untuk komponen emosi / gaya? Apakah itu membuat perbedaan waktu?

Apa arti perubahan dari JSS untuk classes prop yang tersedia pada komponen MUI yang ada? Bagaimana migrasi v5 mencari pengguna yang ada yang memanfaatkan prop ini secara ekstensif?

Kami membayangkan orang-orang untuk menggunakan sintaks berikut sebagai gantinya: https://next.material-ui.com/components/slider-styled/#unstyled -slider kelas pada dasarnya diganti oleh pemilih kelas yang tersedia untuk setiap slot dalam komponen. Anda juga dapat melihat contoh penyesuaian: https://next.material-ui.com/components/slider-styled/#customized -sliders

Sebagai keuntungan, Anda bisa menggunakan properti dan menerapkan gaya dinamis berdasarkan itu.

Kami membayangkan orang-orang untuk menggunakan sintaks berikut sebagai gantinya: https://next.material-ui.com/components/slider-styled/#unstyled -slider kelas pada dasarnya diganti oleh pemilih kelas yang tersedia untuk setiap slot dalam komponen. Anda juga dapat melihat contoh penyesuaian: https://next.material-ui.com/components/slider-styled/#customized -sliders

Sebagai keuntungan, Anda bisa menggunakan properti dan menerapkan gaya dinamis berdasarkan itu.

Saya suka API ini! Perubahan yang sangat disambut baik, dan tampaknya bermain sangat baik dengan mesin gaya.

Sebelum v5 , jika saya mengingatnya dengan benar, kompiler JSS akan mengacaukan nama kelas tersebut dan Anda tidak dapat menargetkannya dengan andal? Tapi sekarang sepertinya mereka akan diekspos untuk tujuan penargetan? 🙌 Selain itu, ada masalah dengan CSS yang diutamakan. Dan kekhawatiran itu diselesaikan dengan pendekatan baru ini? Terima kasih telah mengerjakan refactor ini!

@ConAntonakos tepatnya kelas-kelas ini dapat ditargetkan untuk versi komponen tanpa gaya dan gaya. Urutan pemanggilan gaya memastikan bahwa gaya baru akan menang, tentu saja jika kekhususannya sama :)

Sebelum v5, jika saya ingat dengan benar, kompiler JSS akan merusak nama-nama kelas tersebut dan Anda tidak dapat menargetkannya dengan andal?

Anda sudah bisa menargetkan mereka di v4.

kelas pada dasarnya diganti oleh pemilih kelas yang tersedia untuk setiap slot di komponen.

Apakah mereka "pada dasarnya" diganti atau benar-benar diganti? Saya pikir kami memutuskan untuk menyimpan beberapa API lama untuk mengurangi jumlah perubahan yang dapat menyebabkan gangguan.

Saya pikir kami memutuskan untuk menyimpan beberapa API lama untuk mengurangi jumlah perubahan yang dapat menyebabkan gangguan.

Kami memutuskan untuk menyimpan API yang sama untuk theme.components.overrides - overrides yang ditentukan dalam tema bekerja dengan cara yang sama.

Untuk contoh override, kita memiliki pendekatan styled sekarang dengan pemilih kelas, itulah mengapa classes prop tidak lagi didukung. Pengembang dapat melakukan hal yang sama dengan cara yang lebih fleksibel sekarang.

Pengembang dapat melakukan hal yang sama dengan cara yang lebih fleksibel sekarang.

Kedengarannya ini masalah kecil karena ada alternatif tetapi biaya migrasi untuk itu sangat besar. Bagaimana rencana migrasi terlihat?

Pengembang masih dapat menggunakan penggantian tema, jika mereka hanya memindahkan contoh yang ditimpa ke ThemeProvider bertingkat mereka tidak perlu mengubah gaya yang ditentukan sama sekali, karena struktur di antara keduanya sama (tidak sempurna , tetapi jika mereka menginginkan peningkatan tambahan, itu adalah cara yang harus dilakukan)

Di sisi lain, kita masih dapat mendukung prop kelas dengan mudah, tetapi dalam hal ini kita tidak dapat menjamin jika kombinasi kelas + gaya digunakan pada komponen yang sama yang mana yang harus dimenangkan. Haruskah kita mendukung dukungan kelas setidaknya pada versi komponen yang ditata?

Saya mungkin telah melewatkan ini sepanjang utas ini - pertanyaan lain yang terkait dengan pertanyaan classes . Jaminan "kebenaran" seperti apa yang mungkin ada?

Misalnya saya sudah mengedit contoh slider:

const StyledSlider = styled(SliderUnstyled)`
  & .MuiSlider-raill {
    display: block;
    position: absolute;
    width: 100%;
    height: 2px;
    border-radius: 1px;
    background-color: currentColor;
    opacity: 0.38;
  }
)

Anda akan melihat saya tidak sengaja salah mengeja MuiSlider-rail . Sebelumnya dengan classes akan ada sesuatu seperti classes.rail , dan jika saya salah mengeja properti, saya akan mendapat peringatan runtime bahwa classes.raill tidak ada di stylesheet. Saya yakin Tema memiliki perilaku yang sama?

Keuntungan dari classes API yang bisa saya pikirkan:

1. Tepi terhadap pemilih CSS global yang bocor di antara anak-anak: misalnya Dalam .css-e7ylz8 .MuiTreeItem-group . Anda tidak memiliki jaminan bahwa komponen tersebut tidak menerapkan gaya pada komponen anak (bukan efek yang Anda harapkan, kejutan!). Mungkin OK-ish untuk komponen kami karena kami akan berhati-hati.
2. Jadikan penanganan portal tidak perlu dipikirkan lagi: https://material-ui.com/guides/interoperability/#portals. Untuk menata tooltip, kita perlu memberi gaya pada komponen popper, bukan root seperti yang kita lakukan dengan Slider.
3. Sintaks $styleRule memperingatkan jika aturan gaya tidak ditentukan.
4. Izinkan menyesuaikan nama kelas yang digunakan. Solusi saat ini adalah menggunakan prop componentsProps . Kami menggabungkan nama kelas.

Ada dunia alternatif di mana kami akan:

Sebuah. Izinkan untuk memecahkan 1. dan 3. dengan pemilih komponen bergaya .
b. Buka API classes untuk kompatibilitas mundur.
c. Untuk mendapatkan file. dan B. bekerja, kita perlu meratakan bagaimana gaya komponen ditulis secara internal. x komponen bergaya alih-alih 1 akar gaya. Tapi ⚠️ dengan implikasi kinerja.

Apakah kita benar-benar perlu melakukan itu?

Saya telah melihat sejarah jQuery UI classes prop. Saya bisa menemukan dua masalah: https://bugs.jqueryui.com/ticket/7053 , https://bugs.jqueryui.com/ticket/8928 dan komit awal: https://github.com/jquery/jquery- ui / commit / c192d4086d9bbaf09d5f870857af30c60a427e22.

Kami membayangkan orang-orang untuk menggunakan sintaks berikut sebagai gantinya: https://next.material-ui.com/components/slider-styled/#unstyled -slider kelas pada dasarnya diganti oleh pemilih kelas yang tersedia untuk setiap slot dalam komponen. Anda juga dapat melihat contoh penyesuaian: https://next.material-ui.com/components/slider-styled/#customized -sliders

Sebagai keuntungan, Anda bisa menggunakan properti dan menerapkan gaya dinamis berdasarkan itu.

Wow, ini yang terbaik.
Komponen Unstyled atau Headless akan menjadi yang terbaik untuk kustomisasi (menurut saya salah satu kritik tentang mui).
Ini bukan hal kecil untuk memperbaiki imo, tetapi nilai tambah untuk MUI.

PS: Saya ingat dulu pernah sulit menyesuaikan beberapa komponen
PS2: Apakah Anda sudah melihat di https://github.com/modulz/stitches ?

Anda akan melihat saya tidak sengaja salah mengeja MuiSlider-rail. Sebelumnya dengan class akan ada sesuatu seperti class.rail, dan jika saya salah mengeja properti, saya akan mendapatkan peringatan runtime bahwa class.raill tidak ada di stylesheet. Saya yakin Tema memiliki perilaku yang sama?

@ianschmitz selain opsi @oliviertassinari yang disarankan untuk menggunakan pemilih komponen bergaya, kami memiliki opsi lain, yaitu mengekspos konstanta untuk kelas yang kami ekspos. Mungkin sesuatu seperti:

import { sliderClasses } from '@material-ui/core/Slider';

const StyledSlider = styled(SliderUnstyled)`
  & .${sliderClasses.rail} {
    display: block;
    position: absolute;
    width: 100%;
    height: 2px;
    border-radius: 1px;
    background-color: currentColor;
    opacity: 0.38;
  }
)

Ini tidak sama dengan peringatan runtime classes.rail , tetapi akan membantu melawan kesalahan eja kelas.

@mnajdova Kami juga dapat mempertimbangkan plugin eslint.

Mengenai dukungan pada classes prop - agar kami dapat melakukan ini dengan andal, kami harus membuat komponen untuk setiap bagian (slot) dari komponen inti. Misalnya, untuk Slider , kita perlu membuat komponen untuk rel, lintasan, tanda, label tanda, ibu jari, dan label nilai. Ini akan memungkinkan kita untuk menentukan gaya secara langsung pada komponen tersebut, daripada menggunakan kelas untuk meningkatkan spesifisitas. Perubahan ini dapat ditemukan di PR ini - https://github.com/mui-org/material-ui/pull/22893

Dengan perubahan ini, kami telah membuat codeandbox, yang dapat membandingkan performa komponen Slider yang baru ini dibandingkan dengan v4, native style, unstyled, serta dua library kompetitif lainnya - https://codesandbox.io/s/ slider-perbandingan-dengan-banyak-komponen-2tytc? file = / package.json

Jika kita membandingkan kinerja ini dengan kinerja yang hanya memiliki satu komponen dan menggunakan kelas selektor untuk bagian-bagiannya - https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js kita akan melihat bahwa menambahkan komponen per slot memiliki degradasi kinerja 20% 😢

Versi produksi:

• Satu komponen - https://csb-jziv6-99lfgp8e6.vercel.app/
• Komponen per slot - https://csb-2tytc-pz2xlac86.vercel.app/

Sejujurnya saya tidak tahu pada saat ini apakah lebih baik menambahkan kompatibilitas mundur ini atau tidak.

Apakah ini kasus penggunaan nyata untuk dukungan classes atau hanya untuk memudahkan peningkatan?
Apakah kita setuju dengan penurunan kinerja 20% hanya untuk memudahkan jalur migrasi?
Adakah alternatif yang tidak dapat kita lihat, yang akan membantu kita melakukan keduanya tanpa membayar biaya kinerja?

@ianschmitz @ eps1lon @oliviertassinari dan lain-lain :) apakah ada pendapat tentang ini?

Selama kita dapat menentukan dan menggunakan tema & gaya dengan TypeScript, saya tidak keberatan menghabiskan waktu bermigrasi dibandingkan dengan kehilangan kinerja 20%.

Saya biasanya penasaran, dan maafkan saya jika saya tidak memahami desain yang mendasarinya, tetapi classes adalah API untuk JSS? Jika desain API beralih dari JSS ke komponen bergaya, apakah masuk akal untuk tetap mendukung classes ?

Apakah ini kasus penggunaan nyata untuk dukungan classes atau hanya untuk memudahkan peningkatan?
Apakah kita setuju dengan penurunan kinerja 20% hanya untuk memudahkan jalur migrasi?
Adakah alternatif yang tidak dapat kita lihat, yang akan membantu kita melakukan keduanya tanpa membayar biaya kinerja?

Mohon maaf jika saya melewatkan sesuatu dengan API yang diusulkan, tetapi IMO kasus penggunaan yang paling sering saya lihat dalam organisasi kami adalah abstraksi dari sistem gaya yang mendasari yang digunakan oleh MUI. Ya, saya kira classes adalah semacam "API untuk JSS" seperti yang disebutkan @ConAntonakos , tetapi bagi konsumen itu tidak masalah. Sebagai konsumen saya dapat menggunakan teknologi CSS preferensi (adakah batasan hari ini dengan classes ?). Kami memiliki sejumlah produk yang menggunakan berbagai macam:

• File CSS Vanilla
• SCSS
• JSS

tergantung pada kebutuhan dan preferensi tim tersebut.

Mengekspor nama kelas membantu jika Anda menggunakan beberapa rasa CSS-in-JS, tetapi apa pendapat untuk yang tidak?

KEMBALI. Performa 20%, saya setuju bahwa kemungkinan ini bukan trade-off yang dapat diterima. Pada akhirnya, kalian harus melakukan yang terbaik untuk sebagian besar komunitas. Hanya menawarkan pikiranku 😄

Satu keinginan yang tidak pernah saya dapatkan adalah bahwa material-ui akan kompatibel dengan react-native. Banyak proyek lintas platform hari ini dan memiliki solusi gaya terpadu menawarkan banyak keuntungan untuk komponen lintas platform. Kami akhirnya menggulung sendiri menggunakan material-ui di sisi web dan react-native-paper di sisi native dan melakukan standarisasi pada material-ui API. Saya tertarik untuk memahami apakah solusi gaya baru ini akan menggunakan (beberapa / semua) komponen UI Material pada kemungkinan react-native? Referensi jendela apa pun dalam komponen jelas akan menjadi pemblokir, tetapi gaya itu sendiri mendukung asli juga bukan?

@mschipperheyn react-native sejauh ini tidak ada gol. Ini adalah + 5% dari potensi penggunaan (1 bulan pertumbuhan) dan + 50% lebih banyak usaha (perkiraan). Biaya peluang sangat tinggi tanpa arahan yang jelas tentang cara memonetisasinya (di luar model Ionic). Selain itu, ingatlah bahwa flutter tampaknya telah menangkap sebagian besar penonton yang bereaksi terhadap target asli.

Sekarang v5 dalam rilis alfa, apakah ada resolusi untuk masalah ini? Secara khusus, apakah solusi styling masih berbasis JSS? Kami telah melihat masalah kinerja yang substansial terkait dengan JSS, jadi kami sangat menantikan solusi baru.

@zzzev Ini bukan masalah semata. Ini adalah utas RFC (Permintaan untuk Komentar).

Saya ingin tahu tentang masalah kinerja substansial mana yang Anda bicarakan dan bagaimana beralih dari JSS akan meningkatkannya. Karena cara saya melihatnya adalah bahwa jika Anda memiliki masalah kinerja, mungkin bukan gaya tetapi bagaimana penerapannya, yaitu, hasil yang sama dapat dicapai dengan menulis gaya dengan cara lain, menggunakan lebih sedikit daya pemrosesan.

Setidaknya saya gagal untuk menghubungkan dengan bagaimana beralih dari JSS ke Emosi (yang ditunjukkan di utas ini ke _ kemungkinan besar_ memiliki beberapa penurunan kinerja) akan meningkatkan apa pun.

Pemahaman saya adalah bahwa emosi akan menyebabkan sedikit pukulan pada kinerja gaya statis, dan kinerja gaya dinamis yang jauh lebih baik - tapi mungkin itu kurang tepat? Ada banyak angka berbeda di utas ini dan sulit untuk digabungkan menjadi satu gambaran kinerja (dan jelas itu sangat tergantung pada situasi individu).

Ketika Anda mengatakan kita harus menulis gaya dengan cara yang berbeda, maksud Anda menghindari gaya dinamis? Atau adakah praktik terbaik lain yang harus kita pertimbangkan?

@zzzev Benar di bagian pertama, tidak cukup di bagian kedua (kecuali jika Anda menghitung beralih dari tidak didukung ke didukung sebagai perolehan kinerja tak terbatas 🙂).

Emosi mengaktifkan dukungan untuk gaya dinamis, dengan mengorbankan kinerja statis yang lebih lambat.

Saya bingung; bukankah ada gaya dinamis di makeStyles / v4 saat ini? misalnya pola ini

Saya bingung; bukankah ada gaya dinamis di makeStyles / v4 saat ini? misalnya pola ini

Ada tapi ada masalah kinerja yang diketahui. Tim saya tinggal jauh dari ATM

Saya benci gaya komponen
jss sudah bagus tetapi ada beberapa masalah dalam debugging, kinerja dan masih ada beberapa bug yang masih belum terselesaikan seperti bersarang seperti &:after

itu paket saya yang dibangun untuk react-native dan react-native-web
https://www.npmjs.com/package/@material-native-ui/theme -provider

Saya ingin sesuatu seperti ini (ini dibangun di atas RN dan RNW)

Jadi, apakah ada kesimpulan tentang solusi gaya yang direkomendasikan untuk digunakan dengan Material UI v5? Tampaknya ada niat untuk pindah dari JSS di mana @material-ui/styles saat ini dibangun. Atau @material-ui/styles akan difaktorkan ulang untuk dibangun di atas solusi gaya lain seperti styled-components sebagai gantinya?

Jadi, apakah ada kesimpulan tentang solusi gaya yang direkomendasikan untuk digunakan dengan Material UI v5? Tampaknya ada niat untuk menjauh dari JSS tempat @ material-ui / styles saat ini dibangun di atasnya. Atau @ material-ui / styles akan direfraktorisasi untuk dibangun di atas solusi penataan gaya lain seperti komponen gaya?

@ matthewkwong2 kami tidak akan mengadopsi paket @material-ui/styles ke mesin bergaya baru, itu akan tetap mendukung jss. Di v5, ini akan diisolasi ke basis kode lainnya dan kami berencana untuk menghapusnya di v6, yang dimaksudkan untuk membantu transisi ke mesin gaya baru.

Untuk v5, kami akan memiliki praktik ketukan baru terkait solusi penataan, seperti utilitas sx dan styled , kami masih mengerjakan dokumentasi seputar ini.

Selain itu, penggantian tema dan variannya masih akan didukung di v5.

Untuk v5, kami akan memiliki praktik ketukan baru terkait solusi penataan, seperti sx prop dan utilitas gaya, kami masih mengerjakan dokumentasi seputar ini.
Selain itu, penggantian tema dan variannya masih akan didukung di v5.

Jadi jika saya mengerti dengan benar, untuk penataan komponen individu, disarankan untuk menggunakan sx atau styled daripada makeStyles .

Tapi bagaimana dengan temanya (yaitu createMuiTheme )? Saya yakin bagian itu juga dibangun di atas JSS, bukan? Apa cara yang direkomendasikan untuk membuat tema (yaitu dengan tujuan utama mendefinisikan gaya global) sekarang?

Kami masih mempertahankan struktur yang sama untuk membuat tema, kami hanya berharap bahwa nilai-nilai untuk komponen ditimpa & varian mengikuti sintaks untuk komponen-gaya / emosi. Tidak ada perubahan dalam cara pembuatan tema, API persis sama, konteks tema yang sama juga digunakan untuk mesin gaya baru. Apakah ini masuk akal @ matthewkwong2 ?

@mschipperheyn react-native sejauh ini tidak ada gol. Ini adalah + 5% dari potensi penggunaan (1 bulan pertumbuhan) dan + 50% lebih banyak usaha (perkiraan). Biaya peluang sangat tinggi. Selain itu, ingatlah bahwa flutter tampaknya telah menangkap sebagian besar penonton yang bereaksi terhadap target asli.

Saya tidak ingin membawa kita pada garis singgung yang terlalu besar, tetapi saya ingin mendorong kembali beberapa alasan ini.

• Di masa lalu saat membuat aplikasi RN, salah satu hal tersulit yang harus dihadapi adalah Desain Material. Faktanya itu adalah masalah yang cukup besar sehingga berpotensi memutuskan apakah akan repot-repot membangun aplikasi seluler. Saya dengar ini sedikit lebih baik dengan satu perpustakaan baru yang menjanjikan. Tapi saya ragu itu akan menjanjikan jika MUI ada di dalamnya. Mungkin hanya saya, tapi saya bisa melihat MUI lintas platform benar-benar meningkatkan penggunaan RN. Saya tahu bahwa itu hanya sebagian kecil dari penggunaan react-dom, tetapi web sangat besar dan react-dom mendominasi kerangka web modern . Bahkan jika penggunaan bereaksi-pribumi relatif kecil, yang masih bisa cukup banyak orang sebagai mutlak yang akan menggunakannya. Jajak pendapat pengguna MUI saat ini mungkin akan menjadi metrik yang lebih baik daripada statistik npm.
• Saya tahu saya berada di luar lingkaran, tetapi saya tidak begitu percaya Flutter mengambil alih React Native. Perbandingan lalu lintas itu bukanlah cara yang bagus untuk membandingkan. Ini dipengaruhi oleh begitu banyak faktor perancu (Flutter lebih baru sehingga lebih banyak orang sudah tahu RN dan tidak perlu merujuk ke dokumentasi; Dokumentasi Flutter bisa jadi lebih berguna untuk mereferensikan ulang meningkatkan lalu lintasnya; Beberapa lalu lintas membaca dokumen RN juga bisa berjalan ke Expo). Perbandingan Google Trends yang agak cacat ini hampir merupakan ukuran yang lebih baik, dan ini cukup merata. Saya tahu secara pribadi Flutter memiliki beberapa pemecah kesepakatan yang sulit dan RN masih jauh lebih menjanjikan untuk saat berikutnya klien mengatakan bahwa mereka menginginkan aplikasi seluler.
• JSS adalah salah satu masalah terbesar (sebenarnya mungkin yang terbesar) dalam membuat MUI bekerja dengan React Native. Saya tahu masih akan ada beberapa faktor yang menyulitkan, tetapi IMHO peralihan ke emosi kemungkinan besar telah menghilangkan 2/3 dari kesulitan dalam membuat MUI berfungsi di RN setidaknya secara eksperimental.

peralihan ke emosi tampaknya telah menghilangkan 2/3 kesulitan dalam membuat MUI berfungsi di RN

Kami menantikan POC Anda 😄

Kami menantikan POC Anda 😄

Saya ingin bermain-main dengannya jika saya memiliki kesempatan. Tetapi orang-orang umumnya tidak repot-repot membuat POC untuk hal-hal yang tidak diminati oleh pengelola. Tidak ada gunanya membangun sesuatu ketika atmosfer saat ini mungkin akan ditinggalkan begitu saja. Oleh karena itu mengapa saya ingin menjauhkan dari mengabaikan nilai RN atau nilai RN sebagai kemungkinan untuk masa depan.

Dua pertanyaan:

1. Bisakah Anda menggunakan solusi gaya baru tanpa HOC? Saya untuk satu cinta API React hook yang saat ini dimiliki MUI ... tidak yakin apakah sintaks yang ditata juga merupakan HOC di bawah tenda tetapi itu akan mengalahkan upaya (cukup banyak di mana-mana di perpustakaan React) untuk menjauh dari HOC.
2. Akankah classes prop sebagian besar komponen masih didukung (ini akan memberikan fleksibilitas penuh dalam solusi penataan gaya apa yang dapat digunakan pengguna)?

fast-refresh diaktifkan secara default di create-react-app v4 . haruskah kami menambahkan dukungan penyegaran cepat sebagai persyaratan baru?

Mencoba ini dengan gatsby. Ketika saya melakukan import { Link } from '@material-ui/core' saya mendapat:

Can't resolve '@emotion/core' in 'node_modules/@material-ui/styled-engine'
File: node_modules/@material-ui/styled-engine/index.js

Can't resolve '@emotion/styled' in '/node_modules/@material-ui/styled-engine'
File: node_modules/@material-ui/styled-engine/index.js

Ketika diubah menjadi import Link from '@material-ui/core/Link' masalah hilang.

Jika saya menginstal @emotion/styled @emotion/core saya mendapat:

Tidak dapat menyelesaikan '@ emosi / bereaksi' di '/ node_modules / @ emosi / gaya / dist'

Kemudian saya menginstal @emotion/react .

Kesalahan waktu proses masuk.

Error: The `@emotion/core` package has been renamed to `@emotion/react`. Please import it like this `import { jsx } from '@emotion/react'`.
./node_modules/@emotion/core/dist/emotion-core.cjs.dev.js
node_modules/@emotion/core/dist/emotion-core.cjs.dev.js:3

Versi paket yang terlibat:

    "@emotion/core": "^11.0.0",
    "@emotion/react": "^11.0.0",
    "@emotion/styled": "^11.0.0",
    "@material-ui/core": "^5.0.0-alpha.15",
    "@material-ui/lab": "^5.0.0-alpha.15",

Instal paket Emosi versi v10

Oh 11 adalah versi "terbaru" sekarang jadi saya pikir mui perlu memutakhirkan atau mendokumentasikannya

Oh 11 adalah versi "terbaru" sekarang jadi saya pikir mui perlu memutakhirkan atau mendokumentasikannya

Kami telah mendokumentasikannya melalui rentang versi di peerDependencies . Kami tidak menyebutkannya secara eksplisit dalam instruksi pemasangan karena kami berencana untuk segera memperbaruinya ke v11.

Pengingat ramah bahwa ini adalah alfa dan emosi 11 yang baru berumur beberapa hari. Sebagai pengguna awal, Anda harus mengharapkan beberapa sisi kasar.

Halo semuanya, saya baru di sini, dan saya sedang melihat solusi material-ui css dan datang ke masalah ini.
Hanya memberikan 2 sen saya untuk ini, saya ingin menyarankan Linaria https://github.com/callstack/linaria.
Ini adalah pustaka runtime nol, dengan ekstraksi css dan variabel CSS sebagai alat peraga React.

Semoga ini bisa membantu di RFC ini 😄.