Material-ui: [Core] Harus ada solusi gaya yang lebih canggih.

Dibuat pada 22 Apr 2016  ·  100Komentar  ·  Sumber: mui-org/material-ui

@ callemall / material-ui silakan tinggalkan beberapa masukan di sini bila Anda bisa 👍

Kita perlu memutuskan solusi gaya untuk 0.16.0 yang akan membantu mengatasi masalah yang sudah berlangsung lama. Di luar masalah kinerja, ada peretasan dan props di mana-mana untuk menebus fakta bahwa kami kehilangan beberapa fitur canggih di CSS yang tidak dapat digunakan dengan gaya inline - kelas semu, kueri media (tanpa matchmedia ), dll.

Dari apa yang saya pahami, konsensus umumnya adalah kami menginginkan solusi gaya JS yang memiliki kemampuan untuk menulis gaya ke stylesheet aktual di DOM.

Berikut adalah beberapa solusi terawat yang melakukan ini:
https://github.com/rofrischmann/react-look
https://github.com/Khan/aphrodite
https://github.com/jsstyles/react-jss

Berikut adalah beberapa hal yang perlu kami pertimbangkan saat menerapkan solusi baru (IMO):

  1. Apakah itu sejalan dengan tujuan kita? (disentuh ringan di atas)
  2. Mengimplementasikan kueri media yang mengikuti breakpoint tingkat tinggi yang dirinci dalam spesifikasi yang dapat dengan mudah digunakan dalam komponen dengan mixin stylesheet (atau penerapan apa pun yang kami gunakan menyebutnya). Jika kita merombak implementasi gaya, ini adalah momen yang tepat untuk menanam benih untuk dukungan UI responsif yang jauh lebih baik di pustaka ini. Akan lebih baik lagi jika alat ini tersedia di userland juga 👍
  3. Haruskah kita membuat komponen layout helper dan / atau mixin untuk membantu menyatukan implementasi layout flexbox di seluruh lib?
  4. Apakah tema perlu diubah untuk memaksimalkan penggunaan terbaik dari solusi baru? Meskipun tema adalah salah satu komponen gaya yang konsisten, kita juga harus melihat ke dalam membuat variabel untuk banyak gaya material umum seperti garis kunci global / ukuran font / spasi / margin / dll. Saya sangat menyarankan agar kami meningkatkan konsistensi tipografi kami dengan membuat gaya tipe yang telah ditentukan sebelumnya yang cocok dengan panduan tipografi material-ui, dan mencoba mencocokkan elemen komponen seperti judul dll sebaik mungkin dengan variabel gaya tipe global ini sebagai default.
  5. Jika menggunakan pustaka sebesar react-look , coba dan lihat bagaimana kita dapat mengimpor modul untuk ukuran build minimal. Akan lebih bagus jika kami dapat meminimalkan dampak pada ukuran bangunan. Saya menyadari bahwa 9kb di antaranya adalah https://github.com/rofrischmann/inline-style-prefixer yang sudah kami gunakan ... 😄
discussion performance umbrella

Komentar yang paling membantu

Apakah solusi styling sudah selesai?

Semua 100 komentar

Beberapa pertanyaan lebih lanjut:
6) Apakah kita akan menghapus atau bertujuan untuk menghapus xxxxStyle props dan meminta pengguna memasukkan xxxClassName untuk mengganti gaya? Atau akankah ini gratis?
7) Akankah kita mengizinkan penggantian gaya melalui CSS dan menyederhanakan antarmuka komponen kita. Jadi jika saya ingin mengganti menuItemStyle di IconMenu, apakah saya membuat penimpaan jenis style = StyleSheet.create({ IconMenu: {MenuItem: { color:red }}) ?

@chrismcv Pendapat pribadi saya adalah bahwa kita pasti perlu memanfaatkan solusi untuk menghapus props super spesifik yang kami lihat diusulkan: [TextField] tambahkan floatingLabelFocusStyle prop # 4043

Sebelum kita menyadarinya, orang akan meminta props untuk gaya subkomponen untuk setiap kemungkinan fokus / aktif / hover / status apa pun.

Saya melihat begitu banyak masalah yaitu "cara menata XXXX", "tidak bisa memberi gaya XXX di dalam YYYY", "tolong tambahkan somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle prop ke XXX"

@chrismcv di 6. tentang props xxxxStyle lebih umum vs classNames, bagaimana menurut Anda? dengan beberapa komponen kami, Anda harus dapat menjangkau dengan satu atau lain cara (untungnya kami akan dapat menggunakan :hover dll!).

@chrismcv Saya pikir bahwa xxxxStyle props harus ditempatkan di properti style , bukan objek gaya yang di -ified className .

@nathanmarks Terima kasih telah

Di luar masalah kinerja

Bagi saya, itulah salah satu perhatian utama saya dengan solusi yang akan kami pilih.
Kami tidak memiliki banyak tolok ukur, jadi kami dapat dengan mudah membayangkan bahwa kami kehilangan banyak siklus CPU dengan pendekatan kami saat ini. Siklus CPU hilang ke dalam alokasi memori dan pengumpulan sampah untuk objek gaya sebaris kita.

@oliviantri

Saya sedang bermain-main dengan beberapa solusi gaya JS saat ini. Ini menarik tetapi jelas bahwa ini masih "hari-hari awal" untuk berbicara.

Satu hal yang saya pikirkan - di luar properti gaya dinamis (misalnya, jika komponen memiliki color prop), haruskah kita mengubah cara kita membuat objek gaya dasar?

Sepertinya dengan libs gaya JS, untuk mendapatkan kinerja maksimum Anda harus menggunakan metode StyleSheet.create() sekali dan memiliki kunci (css "kelas") di objek itu untuk props / state seperti open={true} daripada secara dinamis membangun objek gaya secara literal dengan beberapa properti bersyarat dan meneruskannya ke metode pabrik stylesheet setiap render untuk setiap gaya.

Meskipun pemilih stylesheet di-cache dalam arti hanya ditulis sekali ke DOM (dan di beberapa lib hanya ditulis ke DOM bila diperlukan untuk render() ), kami masih membuang-buang sumber daya dengan beberapa perhitungan + pembuatan objek + pengumpulan sampah seperti yang Anda sebutkan di atas jika kita membuat objek gaya baru setiap render hanya untuk membuangnya.

Hmmm ... Saya meninggalkan komentar di sini kemarin (Minggu). Apakah itu terhapus?

@rvbyron Saya ingat dengan jelas. Saya pasti tidak menghapusnya.

@rvbyron Aku juga mengingatnya. Saya tidak tahu apa yang terjadi.

@rvbyron - sudah ada di email saya, jadi kembali ke sini dalam bentuk kutipan!

Baiklah, saya ingin melihat beberapa hal terjadi.

A) Ya, tentu saja singkirkan penggunaan parameter gaya elemen di tingkat perpustakaan. Semua komponen harus ditentukan menggunakan className. Memiliki komponen yang menggunakan gaya menghancurkan semua kekuatan yang ditawarkan CSS.
B) Akan sangat bagus jika classNames secara otomatis dilampirkan ke elemen root dari setiap komponen (misalnya, komponen RaisedButton secara implisit akan memiliki className = "mui-rise-button" pada elemen root komponen). Ini akan membuat penataan jauh lebih mudah. Itu bahkan bisa dikonfigurasi.
C) Hapus tema dari file muiTheme.js secara bersamaan. File muiTheme.SCSS tema akan jauh lebih baik karena akan memungkinkan properti apa pun yang dipilih oleh pembuat tema untuk diterapkan dan bukan hanya yang secara khusus diizinkan oleh komponen. Tentu saja ini mungkin membutuhkan B diimplementasikan dan aktif.
D) React-look tampaknya merupakan kompromi yang baik karena mengubah objek JSON yang berisi properti gaya menjadi classNames. Itu membuat segalanya lebih mudah untuk ditimpa. Namun, seperti yang saya katakan di C di atas, saya masih ingin basis tema dibuat di SCSS. Saya cukup terbuka tentang paket bantuan CSS mana yang akan digunakan. Tapi saya akan menjauh dari apa pun yang ingin menggunakan parameter gaya elemen di atas parameter className.

@chrismcv Terima kasih

Menurut saya, apa yang dikatakan @rvbyron penting karena dalam beberapa hal, gaya JS merupakan pergeseran paradigma dari CSS biasa. Kebanyakan orang tidak menggunakan gaya JS dalam pekerjaan sehari-hari mereka dan ini membutuhkan cara berpikir yang berbeda + mempersulit desainer yang biasanya berkontribusi pada proyek yang tidak begitu mahir dalam JS.

Penting untuk mempertimbangkan semua sudut di sini.

@oliviertassinari @oliviertassinari

Satu hal yang saya sadari tentang react-look adalah Anda perlu membungkus semua komponen Anda di look HoC . Ini tampaknya cukup invasif, bahkan membajak fungsi render() , menyimpan super.render() dalam const dan melakukan operasi resolusi gaya seperti itu. Beberapa solusi lain seperti Khan / aphrodite hanya memerlukan pembungkus fungsi di sekitar referensi styles.xxxx dari Stylesheet.create() di dalam className={} .

Membajak fungsi render() hanya untuk css tampaknya terlalu direkayasa bagi saya. Ini memberi tahu saya bahwa React built in tooling / support untuk jenis fungsionalitas gaya yang sangat terintegrasi ini tidak ada di sana, saya tidak yakin tentang gagasan pembantu CSS HoC yang mengendalikan render untuk semua komponen kita.

Pikiran?

Halo tim Material-UI!

Telah mengikuti Anda beberapa lama dan sekarang, melihat topik ini, saya juga ingin berkontribusi dengan beberapa pemikiran mengapa berpindah dari gaya sebaris ke css mungkin merupakan ide yang bagus. Saya telah membaca banyak diskusi di repo ini yang mencakup kinerja rendering, styling children / nested element, media queries, pseudo-element, dll., Jadi saya akan fokus pada hal lain yang belum saya bahas, tapi yang menurut saya juga relevan. Dan itu adalah organisasi gaya. Inilah yang saya maksud:

  • Beberapa gaya berasal dari default komponen (yang ditetapkan di folder node dan tidak dapat disentuh)
  • Beberapa berasal dari parameter komponen (misalnya parameter komponen Avatar size={40} menetapkan lebar, tinggi dan tinggi baris menjadi 40px )
  • Ketika default komponen disesuaikan (warna tema) gaya berasal dari tempat kustomisasi tema
  • Ketika gaya komponen lainnya dimodifikasi, gaya tersebut berasal dari implementasi komponen, yang merupakan bagian lain dalam kode

Saat menyesuaikan gaya, setidaknya ada 4 lokasi berbeda (👆) untuk dilihat, sehingga sulit untuk menyelidiki masalah.

Ketika gaya datang dengan css, Anda akan melihat selektor dan tahu persis di mana harus memperbaikinya. Dengan gaya sebaris, perlu waktu untuk memahami dari mana properti tertentu berasal, dan di mana serta apa yang harus dimodifikasi. Dan jika pengembang memodifikasinya di tempat yang salah (katakanlah di area styles alih-alih parameter size , karena tidak ada yang benar-benar mengatakan bahwa size adalah gayanya) itu akan mempengaruhi seluruh kinerja blok width=height=line-height=40px , atau akan menyebabkan penulisan lagi width/height/line-height yang akan membuat parameter size tidak dapat diterapkan.

Selain itu, juga menyulitkan untuk menyelidiki elemen induk mana yang memiliki properti spesifik yang diterapkan, karena yang dapat Anda lihat di inspektur adalah element.style .
image

Ketika gaya datang dengan penyeleksi (nama kelas) itu memberikan lebih banyak kontrol atas struktur gaya daripada gaya-sebaris.

Pembaruan: Lupa menyebutkan saran (tentang topik ini):

/component
--component.js
--component.css (or sass that is converted to css when the page is rendering)

Struktur ini akan menjaga komponen tetap dalam ruang lingkup, tetapi akan memberikan kontrol lebih besar atas gaya. Dan konvensi BEM className akan membantu menghindari penumpukan yang tidak perlu:

.mui-component {}
.mui-component__child {}

Yang secara keseluruhan akan membantu menerapkan, menyesuaikan, dan mempertahankan gaya Material-UI.

@rumahsakitotak

Terima kasih telah menemukan email tersebut dan memasukkannya ke dalam komentar!

Pendekatan perilaku terbaik dari kedua dunia?

Bagaimana dengan konsep "perilaku" dalam mengimpor teknik penataan yang paling sesuai dengan kebutuhan Anda. Impor "StyleTheme" atau "ClassTheme" dapat digunakan untuk memilih perilaku. StyleTheme dapat merujuk pada objek muiTheme material-ui yang dimiliki saat ini dan membuat pengembang gaya yang berpusat pada komponen senang. Atau, ClassTheme yang akan menggunakan file SCSS yang dibangun dari objek muiTheme.js (disinkronkan) membuat pengembang yang terpusat pada CSS senang. Itu berarti bahwa semua komponen kemudian perlu mengakomodasi {... theme.ComponentName} dalam elemen render.

Untuk menawarkan contoh yang sangat sederhana, komponen RoundButton akan memiliki metode render seperti:

render() {
    return (<button {...theme.RoundButton} />);
}

Untuk perilaku StyleTheme, theme.RoundButton akan berisi:

{ 
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

Untuk perilaku ClassTheme, theme.RoundButton akan berisi:

{ 
    className: 'mui-round-button'
}

Kombinasi keduanya dapat diambil sebagai perilaku ClassStyleTheme, theme.RoundButton akan berisi keduanya:

{ 
    className: 'mui-round-button',
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

File mui-theme.scss akan dibuat dari file muiTheme.js dan mencerminkan di SCSS properti persis yang dimiliki file JS. Casing unta dari nama JS akan diubah menjadi nama kelas yang lebih standar:

mui-round-button {
    display: inline-block;
    border-radius: 20px;
    width: 40px;
    height: 40px;
}

Setiap penyesuaian CSS pada komponen MUI akan menjadi kelas identik yang dimuat setelah file mui-theme.scss dimuat, sehingga menimpa properti mui-theme.

@oliviantri

Saya pikir menggunakan sesuatu seperti scss (+ modul css untuk namespacing / hashing) memiliki banyak manfaat. Apakah ini sesuatu yang 100% Anda lawan? Saya mungkin sedikit bias karena itulah yang biasa saya gunakan di tempat kerja, tetapi banyak orang berada di perahu yang sama.

Masalah utama saya dengan situasi styling JS adalah sepertinya semua solusi masih dalam proses. Tidak banyak evaluasi kinerja dunia nyata di luar sana untuk dilihat, libs yang kita lihat belum terbukti dan saya merasa seolah-olah kita menghabiskan banyak waktu untuk mencoba mencari cara bagaimana melakukan gaya di JS dengan benar. Tujuan utama dari lib ini adalah untuk mengimplementasikan spesifikasi desain material dan saya tidak bisa tidak merasa bahwa ini sedang melemahkan kami saat ini. (kami pasti perlu menyortir masalah dampak kinerja)

Saya pikir kami memiliki kekhawatiran yang berbeda tentang hal ini.

  1. Di mana meletakkan gaya statis (mudah, file css bisa melakukannya)
  2. Cara mengganti beberapa gaya tergantung pada input (saklar className)
  3. Cara menerapkan gaya dinamis (gaya sebaris bisa melakukannya)

Semua tampak bagus saat Anda menulis aplikasi, tidak ada orang di luar kode Anda yang perlu mengubah apa pun.

Tetapi dengan perpustakaan semuanya berbeda, semua masalah di atas ada, ditambah yang berikut ini:

  1. Bagaimana cara mengaktifkan pengguna untuk menyesuaikan gaya statis?
  2. Bagaimana cara mengimplementasikan tema sedemikian rupa sehingga mudah untuk beralih, menyesuaikan dan terisolasi (subpohon berbeda tema berbeda)?
  3. Bagaimana cara menghindari pencemaran namespace global sehingga kita bisa bermain baik dengan orang lain?
  4. Bagaimana cara pengguna mengganti gaya dinamis sebaris?
  5. transformer! (rtl, prefixer, dll)

Apa yang kami miliki saat ini, entah bagaimana, menangani semua masalah itu dengan peringatan berikut:

  1. Performa!
  2. Komponen yang sangat bertingkat sulit untuk disesuaikan, seperti yang dikatakan @nathanmarks : somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
  3. Kami tidak dapat memanfaatkan kekuatan beberapa fitur css.

Jika kita mengubah pendekatan gaya kita, kita harus melakukannya lagi. Jika itu yang terjadi, kami harus memastikan untuk menjawab semua itu sebelum memulai migrasi.

Menurut pendapat saya yang sederhana, saya pikir CSS dan apa pun yang mengkompilasinya bukanlah bagian dari masa depan. Saya pikir kita semua setuju bahwa gaya sebaris membuat hidup kita jauh lebih mudah. Sejujurnya, satu-satunya batasan yang saya lihat dengan gaya sebaris adalah :hover !

Kami dapat menyelesaikan masalah tersebut dengan melakukan sedikit desain.

  1. memoize the styles object, untuk komponen yang memiliki state, kita dapat memecah state tersebut dan meletakkannya dalam komponen yang lebih kecil sehingga obyek style di dalamnya dapat di memoisasi berdasarkan props yang diteruskan yang merupakan state komponen yang lebih tinggi. Ini mudah dipecahkan!
  2. hancurkan mereka! mengapa kita memiliki ListItem dengan BANYAK fungsi kecil yang tertanam di dalamnya? kita dapat memecahnya dan membuatnya dapat disusun, lalu kita tidak perlu menambahkan monster seperti somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
  3. meh! semua yang kita dapatkan kinerja dengan :hover Saya pikir kita bisa hidup dengan itu sampai browser atau bereaksi melakukan sesuatu tentang itu.

Maksud saya adalah, kami telah mengatasi sejumlah besar masalah dengan pendekatan gaya kami saat ini. Ini memiliki batasan karena kami tidak mengikuti semua pola di sekitar gaya sebaris. jika kita mulai memecah komponen kita dan membuatnya lebih mudah disusun maka kita tidak perlu khawatir tentang apa pun. ambil MeuItem Saya mengeluarkannya dan membuatnya dapat disusun, Anda melihat betapa mudahnya digunakan dan bagaimana kinerja dapat ditingkatkan dengan menggunakan rendering murni!

Jadi, alih-alih mengubah pendekatan kita dan menyelesaikan semua masalah ini lagi, mari kita investasikan waktu untuk meningkatkan apa yang sudah kita miliki. kita tidak perlu mendukung kueri media, kita dapat mengubah komponen kita dengan cara yang mudah bagi orang lain untuk mengimplementasikan ketanggapannya. Sulit melakukan debug? jika kita memecah komponen kita maka gaya sebaris akan lebih kecil dan lebih mudah dibaca. bisa diperdebatkan! Maksud saya semua yang Anda butuhkan adalah titik istirahat untuk melihat apa yang berpartisipasi dalam Object.assign untuk melihat dari mana gaya berasal.

Itu tentu saja pendapat saya sendiri. Saya sangat terbuka untuk diskusi.

@alitaheri

Anda meningkatkan beberapa poin bagus. Terima kasih. Saya bertanya-tanya apakah semacam solusi hybrid adalah sebuah kemungkinan. Tampaknya tidak peduli sudut mana yang kami ambil, ada banyak masalah 😆

Saya punya waktu untuk mengerjakan ini minggu depan - mari kita mengobrol dan melihat apakah kita bisa mendapatkan ide yang cerdas.

Saya setuju dengan mencoba meminimalkan jumlah perubahan dan harus menyelesaikan kembali masalah yang sudah diselesaikan. Ada 2 tujuan penting di sini dalam pikiran saya:

  1. Performa
  2. Pengalaman pengembang (JS libs gaya banyak membantu di sini dengan memungkinkan pengembang untuk menggunakan kelas dalam aplikasi mereka dengan mudah)

Perlu memikirkan hal ini lebih lanjut 😄 tetapi selama kami berhasil menyelesaikan 2 poin tersebut, saya akan senang dengan solusi kami.

Catatan acak lainnya - akan sangat bagus jika kami memiliki cara otomatis untuk menerapkan konvensi kode tertentu dan pola desain untuk inline / jsstyle / apa pun di seluruh lib.

Apakah ini sesuatu yang 100% Anda lawan?

@nathanmarks Saya tidak 100% menentang penggunaan SCSS (_Saya menggunakannya di tempat kerja_). Tapi dari sudut pandang saya, ini jalan buntu .
Salah satu keuntungan utama React adalah mengabstraksi kekhususan rendering browser: DOM.
Sejauh yang saya tahu, tujuan jangka panjang dari React Core Team adalah menyediakan API untuk menulis komponen lintas platform. Sebenarnya, mereka sedang bereksperimen ke arah ini. SCSS tidak akan membantu.

Saya sepenuhnya setuju dengan @alitaheri. Kita bisa mulai dengan dua langkah itu:

  • Gunakan pola getStyles mana saja agar kita dapat lebih mudah bermigrasi nanti.
    Apakah kami dapat menggunakan codemod? Siapa tahu.
  • Menguraikan setiap komponen seperti yang diusulkan oleh @alitaheri.

@oliviertassinari Saya setuju dengan kesimpulan buntu - ini bukan masa depan. Saya membahasnya sebagian besar untuk merangsang percakapan tentang bagaimana membuat gaya JS bekerja untuk kita. Saya tahu beberapa orang di sekitar sini memiliki beberapa ide bagus seputar masalah ini 😄 Berharap FB sedikit_ lebih jauh dengan eksperimen mereka!

Saya benar-benar berpikir pola getStyles() yang kita gunakan saat ini memiliki masalahnya sendiri. @alitaheri dan saya berbincang cukup bagus hari ini tentang apa yang harus dilakukan untuk meningkatkan pengaturan gaya JS kami (termasuk tema!). Saya akan membalasnya besok dengan beberapa info lagi setelah saya mendapat kesempatan untuk menulis beberapa catatan!

Minggu depan saya sedang berlibur dan saya akan bereksperimen dengan solusi untuk masalah kita saat ini sambil mempertahankan semua gaya berbasis JS.

Baca saja postingan ini di Lessons Learned At React Amsterdam (https://medium.com/@kitze/lessons-learned-at-react-amsterdam-51f2006c4a59#.o12h794or) dan salah satu presentasinya adalah tentang solusi untuk styling di React: http : //slides.com/kof/javascript-style-sheets#/ Presentasi tepat waktu untuk diskusi ini.

Satu persyaratan yang terus saya pikirkan dan yang belum saya lihat dinyatakan secara eksplisit (setidaknya yang saya ingat) adalah kebutuhan untuk mendukung web-only vs. web dan bereaksi secara native. Jika tujuannya hanya untuk web (yaitu bereaksi asli bukanlah persyaratan) maka solusi yang memanfaatkan browser apa yang sudah didukung secara efisien dan kuat dan orang-orang sangat akrab akan menjadi hal yang baik. Jika mendukung react native adalah suatu keharusan maka itu akan membuka seperangkat kebutuhan & persyaratan yang berbeda. Hanya sesuatu untuk dipikirkan dan diingat saat pilihan teknologi, kompromi, dll. Dievaluasi.

@tokopedia

Terima kasih telah membagikan presentasi itu!

@alitaheri

Kami mungkin ingin melihat lib yang disebutkan dalam presentasi itu ( berikut demo ). Ini bisa menghemat banyak pekerjaan. Saya pernah melihatnya sebelumnya tetapi ada beberapa hal yang tidak saya sukai (seperti persyaratan untuk membungkus setiap komponen dalam HoC berpemilik). Namun, ada beberapa diskusi tentang beberapa hal yang terjadi di sini . Dia menyebutkan bahwa menerapkan perubahan seperti ini akan memungkinkan penggunaan bebas HoC. Saya lebih suka metode / desain itu untuk penulisan lembar (juga terlihat di aphrodite ).

Alternatifnya, kita selalu bisa membuat react binding kita sendiri untuk jss yang bisa bekerja dengan mixout .

Penulis lib juga mengatakan ini, yang sejalan dengan pemikiran saya tentang masalah ini 👍:

Namun Anda perlu memahami bahwa tidak semuanya masuk akal untuk menjadi style sheet. Untuk perubahan paling dinamis, Anda harus menggunakan gaya sebaris.

@nathanmarks Penerapannya agak sangat kecil dan sangat mudah untuk dicampur: senyum:
https://github.com/jsstyles/react-jss/blob/master/src/index.js
Menurut saya perpustakaan ini dapat membantu kita: +1:

@alitaheri Ya saya setuju!

Saya bereksperimen dengan beberapa binding kustom untuk jss juga - ada beberapa masalah / batasan yang ingin saya coba atasi. (Satu meskipun mungkin memerlukan pekerjaan pada lib inti)

Tampaknya ada sentimen yang berlaku di komunitas React bahwa gaya JavaScript adalah solusi terbaik. Sentimen itu baik-baik saja, saya tidak berselisih dengan mereka yang memilikinya. Namun, cara penerapan gaya JavaScript hampir selalu tanpa memperhatikan pengembang CSS. Penerapannya terlalu sering mendukung style=/[element property]= lebih dari className= dan mencegah pengembang CSS melakukan tugasnya.

Seperti yang saya berikan di komentar sebelumnya, saya pikir keduanya bisa hidup bersama dengan baik. Seseorang harus mengambil pendekatan perilaku untuk menerapkan properti gaya. Pustaka harus mengakomodasi aplikasi langsung properti gaya ke sebuah elemen, atau harus mengizinkan pendekatan tidak langsung dalam membuat nama kelas yang terdiri dari properti gaya tersebut. Pustaka yang memungkinkan pengembang memilih perilaku tampaknya merupakan solusi yang ideal.

Ada banyak alasan pengembang CSS tidak ingin mengabaikan pendekatan mereka begitu saja. Telusuri "mengapa menggunakan css" untuk mengetahui mengapa orang menganggapnya bermanfaat. Anda akan menemukan abstraksi gaya dan bahasa pemilih yang kuat di antara manfaatnya. Jangan lupakan sejumlah besar kode yang ada saat ini yang menguntungkan pengguna CSS.

Sekali lagi, ini tidak dimaksudkan sebagai komentar CSS pro dengan cara apa pun. Ada sebagian dari kita yang ingin menggunakan CSS untuk gaya. Komentar ini dimaksudkan untuk mendorong pendekatan gaya arsitektural netral yang memberdayakan pengembang untuk memiliki pilihan.

@rvbyron Salah satu alasan utama kami ingin mengubah pendekatan kami saat ini adalah untuk mempermudah penyesuaian komponen menggunakan css juga. menggunakan pustaka seperti jss akan memungkinkan kita untuk menggunakan fitur css sambil memanfaatkan js-styles. Dan karena gaya tersebut mengubah gaya tersebut menjadi css, gaya tersebut dapat dengan mudah diganti dengan nama kelas tambahan tanpa peretasan !important jelek.

@alitaheri Senang mendengarnya! Saya sangat menantikan untuk melihat material-ui mengakomodasi pendekatan berbasis className.

Sekali lagi, luar biasa mendengar tentang pendekatan className. Dengan pemikiran ini, saya memiliki beberapa pertanyaan tentang bagaimana itu dapat diterapkan:

  • Menurut Anda, seperti apa konvensi penamaan nama kelas itu?
  • Akankah semua nama kelas memiliki "mui-" atau awalan lainnya?
  • Akankah kelas menjadi notasi tanda hubung dari nama komponen?
  • Akankah nama kelas diterapkan pada elemen root setiap komponen?

@bayu_joo

Idealnya:

Awalan yang dapat disesuaikan. Notasi dasbor untuk pengalaman dev yang lebih baik dan sufiks berciri yang juga dapat disetel ke string tetap (jadi tidak akan berubah jika pengaturan tema diubah) menggunakan ID tema khusus. Termasuk opsi produksi yang tidak terlalu bertele-tele, atau bahkan fungsi panggilan balik untuk disesuaikan. Dan saya akan berasumsi bahwa kelas di root biasanya akan selalu diperlukan.

Saya rasa ada banyak persyaratan yang tercantum dan saran yang ditawarkan. Jadi, apakah ada yang bisa diambil dari semua diskusi ini? Apa tindakan selanjutnya? Apakah ada pekerjaan yang sedang dilakukan untuk mengimplementasikan react-jss ke dalam material-ui ini?

@rvbyron Ya, kami sedang bereksperimen dengan beberapa ide kasar di balik layar. Akan memperbarui masalah ini ketika kami memiliki beberapa ide konkret.

Menurut pendapat saya yang sederhana, saya pikir CSS dan apa pun yang mengkompilasinya bukanlah bagian dari masa depan. Saya pikir kita semua setuju bahwa gaya sebaris membuat hidup kita jauh lebih mudah. Sejujurnya, satu-satunya batasan yang saya lihat dengan gaya sebaris adalah: hover!

Masalahnya adalah: hover adalah bagian gaya yang sangat mendasar dan sangat penting. Mengesampingkan futurisme, mungkin bijaksana untuk menghindari komitmen prematur terhadap solusi yang harus menggunakan cara curang dan solusi untuk mengimplementasikan kembali fitur asli.

@wtgtybhertgeghgtwtg kami sedang mengerjakan solusi yang menggunakan stylesheet nyata sehingga fungsionalitas seperti :hover didukung.

Mengingat poin utama telah diputuskan (gaya JSS melalui className dan elemen root classNames), apakah ada peta jalan dan garis waktu untuk rilis material-ui v0.16.0?

@rvbyron Kami tidak memiliki timeline yang dijanjikan, tetapi untuk saat ini, pendekatan dan performa styling adalah fokus utama kami untuk rilis v0.16.0 dan sesuatu yang sedang kami kerjakan secara aktif sekarang. Kami kemungkinan akan menggunakan masalah ini dalam waktu dekat untuk umpan balik komunitas setelah kami menetapkan arah yang benar di beberapa area lain yang berkaitan dengan internal, API, migrasi, dll.

@newoga Terima kasih Neil! Saya menghargai pembaruannya. Adapun masalah lainnya, saya ingin menambahkan bahwa hanya pergi ke sistem berbasis className dapat menjadi perubahan yang secara visual merusak bagi banyak orang dan saya akan menyarankan untuk membatasi rilis ini hanya untuk itu. Perubahan lain selain itu mungkin benar-benar menghambat migrasi. Namun, saya tahu tim Anda akan memilih keseimbangan terbaik.

@newoga di sini jss telah dipanggil sebagai masa depan sistem gaya untuk material-ui. Apakah ini rencana yang cukup konkret sehingga orang lain dapat mulai memasukkan jss ke dalam proyek kita sekarang, untuk mengantisipasi rilis 16.0?

@sorah belum

@sorahn Masalah ini dirancang untuk mendapatkan umpan balik komunitas tentang apa yang masih menjadi masalah yang benar-benar menantang untuk dipecahkan. Tidak ada keputusan resmi yang dibuat. Untuk saat ini, setiap orang seharusnya hanya memilih dan menggunakan pustaka gaya atau pendekatan yang mereka nilai terbaik untuk mereka dan proyek mereka.

Sebagai catatan, tujuan dari perubahan gaya ini bukan untuk memigrasi semua orang ke beberapa standar yang berbeda, tetapi untuk membuatnya lebih mudah digunakan dan mengatur gaya komponen Material-UI terlepas dari pendekatan gaya apa yang Anda gunakan dengannya.

tl; dr Tidak! Lakukan yang terbaik untuk Anda, bukan yang orang lain katakan :)

@nathanmarks @newoga Terima kasih atas pembaruannya!

Kami mengalami keterbatasan desain responsif + rendering sisi server dengan semua gaya sebaris, jadi kami sedang menyelidiki alternatifnya. Tidak ada opini yang terlalu kuat tentang (s) css-modules atau csx atau apapun, tapi kami menyukai material-ui jadi akan sangat bagus untuk mengikuti apapun yang akan kalian lakukan :)

Saya menemukan pertanyaan media, membaca utas ini (dan lainnya). Saya mempelajari beberapa solusi dan artikel potensial.

Saya sangat menyukai solusi JSS + CSX (dari perspektif pengembang _joy_).

Manfaat & Kinerja JSS

Mirip dengan @sorahn , saya akan dengan senang hati mengadopsi standar material-ui, saya harap @nathanmarks berfungsi ke arah ini untuk memvalidasi pendekatan ini. Selain itu, tampaknya pengembang CSX / JSS sangat ingin membantu dan mempromosikan adopsi perpustakaan mereka.

@rosskevin Mengerjakannya saat kita berbicara - ada hal-hal yang perlu dipertimbangkan di sini yang belum tercakup dalam solusi apa pun hingga saat ini.

Persyaratan kami jauh lebih luas daripada yang mampu didukung oleh solusi yang ada karena keterbatasan atau pendapat desain. Ini sebagian besar karena solusi yang ada telah dikembangkan dengan mempertimbangkan aplikasi di mana Anda memiliki kontrol penuh atas konsumsi API komponen Anda versus pustaka tempat Anda memiliki beragam pengguna yang ingin menata komponen mereka dengan alat yang berbeda.

@sorahn Pertanyaan cepat - apa yang Anda lakukan tentang prefiks vendor dengan rendering sisi server? Apakah Anda hanya merender semua prefiks di server? Atau apakah Anda lulus UA?

@nathanmarks Kami mengirimkan agen pengguna ke browser, tetapi saya pribadi tidak suka mengandalkan itu. Bagaimana dengan menempatkan semuanya secara default, dan mengizinkan orang untuk menimpanya melalui props di objek muiTheme, atau sebaliknya, tidak melakukan apa pun secara default, dan mengizinkan orang untuk ikut serta.

muiTheme: {
  // other stuff...
  stylePrefixes: ['webkit', 'moz', 'ms']
}

@sorahn Anda dapat melakukan apa pun yang Anda inginkan, awalan, bukan awalan, berikan all , berikan UA, dll.

@nathanmarks Saya baru saja merilis [email protected]. Perubahan paling penting - pembuatan id deterministik, berikut adalah contoh ssr dengan react http://jsstyles.github.io/examples/index.html

Hanya memasukkan $ 0,02 saya di sini ... sementara saya sangat menyukai gagasan gaya inline dan aphrodite menarik bagi saya, rasanya akan lebih mudah jika gaya didasarkan pada format perpustakaan di scss seperti bootstrap 4.

Apa yang biasanya saya lakukan adalah menyalin file bootstrap.scss dan file _variables.scss saat membuat file _mixins.scss ... dengan salinan itu di bawah ./lib/style, saya memperbarui file bootstrap.scss lokal untuk referensi lokal variabel dan mixins, saat menggunakan jalur ke versi node_modules dari yang lainnya ...

Saya kemudian mengatur konfigurasi webpack saya untuk membuat ./lib/style bagian dari jalur pencarian untuk konfigurasi sassLoader.

Dengan cara ini, saya dapat memiliki file main.scss yang memuat bootstrap, dll ... Saya dapat dari sana variabel referensi dan / atau mixin dalam sisa proyek saya, dan ketika saya membangun / memaketkan output, gaya yang sesuai adalah termasuk.

Sisi negatifnya, apakah itu akan meresepkan penggunaan material-ui sebagai sumber (bukan pra-bangun) dan webpack untuk menyertakan scss dalam bundel. Karena itu, ini mungkin akan menjadi jalur paling mudah untuk menggunakan variabel, kelas, dan campuran gaya yang ada.

Sekali lagi, saya sangat menyukai ide gaya JS, dan seperti apa yang ditawarkan Aphrodite ... Saya sedang mengerjakan sesuatu yang serupa (akan menyebutnya derma) sebagai pustaka gaya untuk gaya sebaris, tetapi Aphrodite sudah melakukan semua yang saya lakukan. direncanakan dan banyak lagi.

Apakah solusi styling sudah selesai?

Apakah ada pembaruan tentang ini?

Ya, cabang next menggunakan jss

Saya baru saja menemukan proyek ini dan saya sangat bersemangat karena tampak hebat, halaman contoh membuatnya sangat mudah untuk mengetahui bagaimana menggunakan komponen dan sepertinya itu banyak digunakan; namun, saya sangat kecewa dengan stile inline dan saya senang melihat kalian menjauh dari mereka. Salah satu hal yang ingin saya tunjukkan adalah bahwa apa pun yang berkaitan dengan tata letak di luar komponen ini harus dibuang dan biarkan gaya komponen induk menanganinya. Komponen level terendah tidak boleh memiliki margin atau bantalan di atasnya dengan cara apa pun yang akan mendorong elemen di sekitarnya ... terutama karena hampir tidak mungkin untuk menimpa tanpa mengacaukan stile inline yang berarti saya perlu menggali dan mencari tahu bagaimana melakukannya bahwa. Saya belum benar-benar menggali lebih jauh ke dalam proyek ini karena sayangnya saya merasa tidak dapat digunakan. Saya pasti banyak membaca diskusi tentang gaya inline versus css. Bagaimanapun, Anda kehilangan saya di TextField. Ada margin di atas yang 14 piksel dan di bawah 16 piksel. Saya tidak keberatan TERLALU banyak menulis gaya sederhana untuk menimpanya, tetapi itu tidak mungkin karena gaya sebaris dan akan sangat gila bagi saya untuk membuat komponen tingkat yang lebih tinggi hanya untuk membalikkannya seperti membungkus komponen Anda dengan div dan melakukan margin: -14px 0 -16px atau sedikit menyesuaikannya dengan kalkulasi seperti yang saya inginkan, tetapi harus mengoreksinya dengan cara apa pun seharusnya tidak terlalu diperlukan. Saya lebih suka jika Anda mengizinkan className untuk diteruskan sebagai prop seperti yang sudah Anda lakukan sehingga gaya tata letak dapat diterapkan ke komponen dengan cara yang diinginkan komunitas Anda untuk menatanya. Bagaimanapun, itu $ 0,02 saya.

Sebagai tambahan, membuat komponen tipe layout untuk ini atau membuat props tambahan untuk menangani properti layout mungkin ideal seperti menggunakan sistem grid seperti foundation dan bootstrap. Misalnya menggunakan alat peraga seperti ukuran, talang, lebar, kolom, dll, tetapi mulailah tanpa gaya di sekitar bagian luar yang terlihat dengan komponen.

Saya sepenuhnya dengan @ jbsmith969

akan benar-benar gila bagi saya untuk harus membuat komponen tingkat yang lebih tinggi hanya untuk membalikkannya seperti membungkus komponen Anda dengan div dan melakukan margin: -14px 0 -16px atau sedikit menyesuaikannya dengan perhitungan seperti yang saya inginkan

@ jbsmith969 Saya setuju bahwa komponen tingkat rendah seharusnya tidak memiliki logika
IMHO, itulah salah satu pola terkuat yang dimungkinkan oleh React (berkat properti isolasi).

@oliviertassinari @ jbsmith969 Itulah yang kami lakukan! Kami membuat CustomTextField komponen yang saya berikan seperti 2 params ke (nama bidang, dan warna), dan itu hanya melakukan sedikit logika di sekitarnya, kemudian menghasilkan material-ui/TextField dengan apa pun yang kami ingin.

Komponennya benar-benar turun!

Jadi dengan react kita mengambil html kita dan memasukkannya ke js kita dan itu bagus dan keren. Tapi mengambil css kita dan memasukkannya ke dalam html kita? Apakah itu tidak cocok dengan orang lain?

Apa keuntungan pindah dari sass?

Sebut saya kuno, tapi apa yang salah tentang memisahkan js / html dan css kita?

Saya secara sah mencari beberapa jawaban di sini ...

Terkait dengan https://github.com/callemall/material-ui/issues/3614#issuecomment -249095805, gaya hanya menjadi komponen.

Saya melihat kelas CSS sebagai komponen baru: (misalnya btn-danger -seperti dari boostrap)

const DangerButton = ({ hoverColor, style, ...others }) => {
    return (
        <MUI.FlatButton
            hoverColor={hoverColor || Colors.pink100}
            style={{ color: Colors.black, ...style }}
            {...others}
        />
    );
};

Transisi memang menyebalkan ..

(untuk @ jbsmith969 , MUI mengikuti spesifikasi Desain Material. Jika saya tidak ingin mengikuti spesifikasi tersebut, saya akan melakukan beberapa solusi. Namun, saya setuju bahwa MUI sulit untuk diretas, tetapi ini terutama karena keanehan yang tidak konsisten alat peraga komponen, bukan karena gayanya sebaris)

@vizath benar saya pasti memiliki pemikiran yang sama. Tapi apa keuntungan dari solusi ini?

Jika ada solusi yang benar-benar berfungsi setidaknya sebaik CSS, saya akan mempertimbangkan untuk mencobanya. Namun, karena saat ini tidak ada solusi (yang saya ketahui) yang dapat melakukannya tanpa peringatan, saya tidak melihat permintaannya.

Mengapa repo ini mencoba mengadopsi apa yang tampaknya merupakan ide tahap alfa untuk solusi menjadi basis kode yang sangat berguna? Saya hanya tidak berpikir kita ada di sana dengan tec, saya juga tidak berpikir bahwa ini adalah testbed yang tepat untuk tec itu.

@nathanmarks dapatkah Anda memberi saran tentang cara menimpa gaya komponen menggunakan JSS? Saya menggunakan kode terbaru di next

EDIT: Oke, hanya mengetahui bahwa itu masih belum sepenuhnya diterapkan. Salahku! 😬

Saya belum menemukan cara yang baik untuk menghilangkan kode mati dalam kunci objek, dan dengan JSS itu membuatnya wajib untuk menggunakan objek untuk menyimpan gaya.

Contoh acak dalam komponen cabang next (yang belum selesai): https://github.com/callemall/material-ui/blob/b372f6223ec2528dbe02f100e4802334f88445b7/src/IconButton/IconButton.js#L36
Saya tidak dapat menemukan cara untuk memastikan bahwa kelas primary dan accent tidak digunakan.

Saya juga tidak suka cara MUI mengelola gaya sebaris sebelumnya, karena alasan yang sama (lint akan menangkap variabel yang tidak sesuai jika gaya ditentukan secara terpisah, lihat https://github.com/callemall/material-ui/blob/ 60a202fdc9645aa00f20c52e5152f168a1b0031b / src / IconButton / IconButton.js # L26).

Apa keuntungan pindah dari sass?

@gdaunton Itu tergantung pada sisi Anda tentang tidak menggunakan pendekatan inline-style / sass.

Dari sudut pandang pengguna , ini akan memberikan peningkatan berikut:

  • Metode rendering bereaksi lebih cepat, karena kita akan mengandalkan lembar CSS yang dibuat dalam cache.
  • Penimpaan gaya yang disederhanakan, karena prioritas CSS lebih rendah daripada gaya sebaris dan pengguna dapat menggunakan DevTools untuk mengidentifikasi sheet yang akan diubah.
  • Paint pertama yang lebih cepat saat melakukan rendering sisi server.

    • Pengguna akan dapat menyebariskan lembar CSS penting, dan hanya yang digunakan di halaman. Itu adalah sesuatu yang TIDAK BISA Anda lakukan dengan _Bootstrap_ karena monolitnya yang besar 🙈.

    • Pengguna harus dapat melakukan uglify pada kunci nama kelas dalam produksi.

  • Tidak ada dependensi rantai bawaan seperti _scss-loader_ atau _Webpack_.

Dari sudut pandang kontributor / pengelola , ini akan memberikan peningkatan berikut:

  • Tidak ada lagi CSS linter
  • Tidak ada lagi CSS pra-prosesor
  • Tidak ada sintaks CSS untuk dipelajari
  • Bahasa yang jauh lebih kuat untuk menata komponen: JavaScript
  • Buka kemungkinan untuk mengabstraksi mesin gaya. Misal dengan menggunakan react-with-styles

Mengapa repo ini mencoba mengadopsi apa yang tampaknya merupakan ide tahap alfa

Tergantung pada apa yang Anda maksud dengan ide tahap alfa.
Kami jauh dari satu-satunya yang menggunakan pendekatan ini. Misalnya AirBnB, Khan Academy, ReactNative.

bekerja setidaknya sebaik CSS

CSS dirancang dari awal untuk mengatur gaya dokumen , bukan komponen .
Itu adalah perubahan besar dalam industri kami.

Dari sudut pandang saya, Ini menyebalkan untuk komponen styling.
Orang-orang di belakang spesifikasi web sangat menyadari masalah ini dan mencoba mengatasinya dengan gaya cakupan lokal _Web Components_.
Pernahkah Anda memperhatikan semua proyek baru itu sejak React diluncurkan untuk meningkatkan CSS dan menulis gaya berbasis komponen?

Ya, cabang selanjutnya menggunakan jss

@nathanmarks di mana saya bisa mengikuti perubahan ini?

Menemukannya: https://github.com/callemall/material-ui/blob/next/docs/customization/themes.md

@bramick sepertinya bukan tentang next karena ini bekerja mulai dari 0.15.0

Oke, jadi saya melewatkan apa yang baru ... Ada?

@bramick next belum sepenuhnya didokumentasikan (namun ia memiliki situs dokumentasi). Untuk saat ini Anda harus membaca sumber dan Anda dapat merujuk kode sumber situs dokumentasi untuk melihat cara kerjanya. Sadarilah beberapa di antaranya mungkin masih menjadi target yang bergerak.

@oliviertassinari Wow! Terima kasih atas tanggapan yang mendalam.

Saya tidak bisa mengatakan saya sepenuhnya setuju, tetapi Anda dengan menantang menjawab beberapa pertanyaan yang saya miliki.

Saya setuju, kita harus (dan sedang) bergerak menuju dunia di mana gaya kita berbasis komponen, dan css tidak bagus untuk itu. Namun, (menurut saya) masih ada beberapa kerutan yang harus diperbaiki sebelum kita harus mengadopsi ini dalam skala besar.

Saya penasaran, adakah yang melihat apakah ada perbedaan kinerja antara ini dan css standar? Saya merasa css mungkin masih memiliki keunggulan pada javascript; setelah memuat itu masih harus menghasilkan dan menyuntikkan gayanya.

@gdaunton baca tentang kinerja https://github.com/cssinjs/jss/blob/master/docs/performance.md

Ini adalah css standar seperti yang dirender, ditambahkan ke halaman, tetapi dibuat di dalam komponen. Saya menggunakan cabang next dan bekerja dengan cukup baik.

@newoga dapatkah Anda mengirimkan saya tautan ke apa yang Anda maksud?

@bramick OMG! Itu sangat sederhana, bukan? Misalnya, untuk Tombol di next lihat di sini .

Saya memahami daya tarik meletakkan CSS di dalam file JavaScript, setelah keberhasilan JSX, tetapi saya tidak yakin apakah itu ide yang baik untuk melakukan hal yang sama dengan semua CSS dari sebuah aplikasi. Saya tahu bahwa JSS memiliki beberapa kasus penggunaan yang baik, misalnya saat berhadapan dengan gaya dinamis yang sangat kompleks.

Kekhawatiran terbesar saya adalah informasi gaya pada akhirnya akan mengacaukan definisi komponen . CSS yang diekspresikan dengan objek JavaScript jauh lebih bertele - lebih sulit untuk diatur . Misalnya, dalam komponen Button direferensikan di posting sebelumnya, hampir separuh kode adalah informasi gaya. Tidak ada lagi pemisahan kekhawatiran . Saya tahu Anda dapat memindahkan kode gaya ke file terpisah, tetapi tidak ada gunanya menyimpannya di JavaScript di tempat pertama.

Untuk developer, kerugian terbesar adalah mereka kehilangan semua informasi intelek untuk properti CSS dan nilainya. Sebenarnya, saya menyukai semua struktur kode dan ekspresi yang bagus yang dapat diberikan oleh preprocessor CSS kepada Anda, jika digunakan dengan benar.

Saya tidak keberatan menambahkan kerumitan pada proyek saya, jika itu membawa nilai lebih. Jadi saya tidak pernah memikirkan CSS tambahan, pra-prosesor, pemuat, dan sintaks tambahan yang harus saya pelajari. Saya juga mencoba untuk tetap terbuka tentang JSS, hanya saja setelah pandangan pertama tidak meyakinkan saya.

Kekhawatiran terbesar saya adalah informasi gaya pada akhirnya akan mengacaukan definisi komponen.

Ini sepenuhnya terserah Anda, tergantung pada bagaimana Anda mengatur kode Anda, jika Anda berpegang pada beberapa aturan, tidak ada hal buruk yang terjadi (berbicara dari pengalaman produksi 2 tahun).

CSS yang diekspresikan dengan objek JavaScript jauh lebih bertele-tele dan lebih sulit untuk diatur.

Ini sebenarnya kurang bertele-tele karena Anda memiliki tingkat penggunaan ulang kode yang lebih tinggi dan pengulangan yang lebih sedikit.

Untuk developer, kerugian terbesar adalah mereka kehilangan semua informasi intelek untuk properti CSS dan nilainya.

Saya pikir tujuannya di sini adalah memberi pengguna material-ui pilihan untuk menggunakan apa pun yang mereka inginkan untuk penataan. Pelengkapan otomatis untuk CSS adalah argumen yang sering saya dengar. Sebagian besar berasal dari orang-orang yang tidak banyak menggunakan cssinj dan hanya takut kehilangan beberapa kemudahan yang biasa mereka gunakan.

Saya tidak keberatan menambahkan kerumitan pada proyek saya, jika itu membawa nilai lebih.

Saya pikir intinya adalah mengurangi kompleksitas dan membuat basis kode lebih konsisten dan mudah digunakan dan dipahami, tetapi semua skenario kompleks tercakup pada waktu yang sama.

Kekhawatiran terbesar saya adalah informasi gaya pada akhirnya akan mengacaukan definisi komponen.

Dalam proyek kami, kami mengekstrak informasi gaya dari komponen dalam file terpisah dan memuatnya dengan webpack. Manfaat utamanya adalah bahwa semuanya terorganisir dengan baik dan webpack dapat memaketkan kode per komponen, sehingga pemisahan kode kode js DAN informasi gaya dimungkinkan.

Juga pemisahan perhatian diberikan, ketika Anda memisahkan logika untuk menghasilkan aturan gaya Anda. Salah satu contohnya adalah, kami memperkenalkan fungsi pabrik gaya yang menghasilkan stlying seperti mixin di preprosesor css yang terkenal.
Maksud saya adalah, Anda mendapatkan lebih banyak fleksibilitas untuk memodelkan alur kerja spesifik Anda sendiri dan beradaptasi paling baik dengan kebutuhan proyek dan tim.

Sudah cukup terlambat dalam permainan untuk mengubah teknologi, tetapi saya setuju bahwa komponen bergaya sangat menjanjikan. Menangani SSR, kueri media, sintaks yang cukup bagus, dan sebagainya. Dibandingkan dengan JSS, JSS juga menangani autoprefixing dan tema.

Sejauh yang saya tahu, ini menggunakan postcs di dalamnya, yang tidak akan memberikan kinerja yang dapat diterima saat digunakan saat runtime, karena ini adalah parser css penuh dengan banyak penanganan kasus tepi dan plugin. Saya bisa membayangkan untuk melakukan praproses ini ke JSS JSON, tetapi jujur ​​saya tidak melihat banyak nilai dalam menggunakan bahasa CSS dan mencampurnya dengan variabel JS dan pemanggilan fungsi vs. hanya menggunakan JS sepenuhnya.

Sebut saja, build komponen bergaya saat ini adalah 250kb, sudah diperkecil . Agar adil itu karena mereka menggabungkan React dan co, tetapi tetap saja, bahkan parser PostCSS sendiri memiliki 13kb (tidak diminimalkan, mungkin 2kb ~) yang sudah hampir seukuran JSS atau Fela.

Ini bagus untuk pembuatan prototipe cepat & sederhana dari komponen (presentasi), tetapi saya tidak melihat manfaat / fitur apa pun yang tidak dapat disediakan oleh solusi lain.

Saya setuju, saya mencobanya di perpustakaan yang saya kembangkan dan terlalu berat untuk diterbitkan. Saya yakin mereka akan membuat kemajuan dengan itu, tetapi tampaknya pekerjaan JSS di sini hampir selesai dan menawarkan sebagian besar manfaat yang sama.

Saya telah menggunakan react-toolbox belakangan ini, mereka menggunakan modul CSS untuk tema yang pada dasarnya hanya bergantung pada sassLoader webpack. Bagi saya ini bekerja dengan sangat baik. Mungkin perlu diselidiki.

Hei, saya harus setuju dengan pendapat dukungan bertema react-toolbox sangat menakjubkan - saya beralih karena menyesuaikan tampilan komponen adalah aspek terpenting dari cerita frontend.

Saya tidak berpikir ada orang yang mengharapkan gaya CSS lama yang baik untuk menjadi warga kelas satu di Material UI, itulah alasan react-toolbox dimulai

Setidaknya itulah kesan saya setelah membaca banyak isu dan postingan tentang topik ini. Saya samar-samar dapat mengingat hal-hal seperti tim berusaha keras untuk kompatibilitas React Native yang lebih baik dan banyak komentar tentang kasus tepi gaya yang jauh lebih mudah untuk diselesaikan dengan JSS.

Namun informasi itu hilang di antara banyak diskusi. Karena ini adalah topik yang kontroversial, saya pikir akan menjadi nilai yang luar biasa jika seseorang dapat memiliki halaman Wiki tentang tujuan dan filosofi proyek (ditulis oleh pengelola inti) dengan komentar yang kuat tentang mengapa gaya Javascript begitu mendarah daging ke dalam kerangka.

Saya sangat menyukai Material UI karena ini adalah framework penataan material yang paling aktif dan terpoles untuk React. Namun JSS sepenuhnya membuat saya pusing ketika saya ingin mempertahankan gaya terpadu dengan komponen pihak ketiga.

Bagi saya sendiri, saya menghargai cara Material-UI melakukan penataan dibandingkan dengan sesuatu seperti react-toolbox, dan inilah alasannya: Dalam salah satu proyek kami, kami memiliki kemampuan bagi pengguna untuk memilih tema dinamis:

Imgur

Karena pengguna mungkin memilih pasangan warna yang tidak dapat kami tentukan sebelumnya, skema tema apa pun yang kami gunakan harus sangat dinamis. Dengan, perubahan pada tema dapat terjadi secara langsung, b / c semua gaya dihasilkan secara inline: yang harus saya lakukan adalah memberinya warna primer / aksen.

Dalam react-toolbox et. al., ini tampaknya lebih merupakan tugas dari apa yang bisa saya lihat.

@jrop yeah dalam kasus yang sangat khusus ini Anda memerlukan JSS dinamis tetapi untuk banyak aplikasi itu bukan persyaratan penting dan cerita terkini tentang penyesuaian (bahkan tidak berbicara tentang pengujian UI) material-ui sama sekali tidak dapat diterima. Kami sedang membangun aplikasi yang sangat visual dan dirancang yang tidak bisa hanya menggunakan tampilan material-ui default, karena kami sebagian besar membutuhkan / menginginkan bagian perilakunya.

@DominikGuzei Anda dapat menyesuaikan next cabang menggunakan jss. Ini _bukan_ apa yang Anda lihat pada rilis saat ini.

Teman-teman, saya merasa seperti kita mengalahkan kuda mati di sini. Cabang next telah memilih jalur yang berbeda (jauh lebih baik) dengan tema dan memungkinkan untuk diganti. Itu tidak lagi menggunakan gaya sebaris dan memberikan fleksibilitas yang saya lihat telah diminta. Untuk orang lain yang menginginkan lebih banyak penyesuaian, mereka dapat menggunakan HOC di atas komponen next dan menulis lembar gaya mereka sendiri.

@nathanmarks , karena keputusan ini telah dibuat (sejauh yang saya tahu, dan bekerja dengan cukup baik 👍), saya sarankan Anda menulis ringkasan dan menutup / mengunci masalah ini sehingga mereka yang menemukannya memahami jalan ke depan.

jika seseorang dapat memiliki halaman Wiki tentang tujuan dan filosofi proyek (ditulis oleh pengelola inti) dengan komentar yang kuat tentang mengapa gaya Javascript begitu tertanam dalam kerangka kerja.

@fgarcia Saya telah memberikan presentasi di acara lokal di Paris awal minggu ini tentang evolusi pendekatan gaya yang digunakan oleh Material-UI. Anda mungkin tertarik untuk melihat slide dan _notes_: Perjalanan menuju gaya yang lebih baik . Saya fokus pada Tantangan, Masalah dan Solusi.

pengguna untuk memilih tema dinamis

Aspek generasi gaya statis dari Modul-CSS memiliki beberapa konsekuensi.
Gaya penginjeksian pada waktu proses lebih hemat biaya tetapi memungkinkan kita untuk:

  • Memberi kami lebih banyak fleksibilitas dengan penerapan gaya. Misalnya, CircularProgress memiliki thickness ditautkan ke bagaimana animasi keyframe CSS diimplementasikan. Dengan gaya dinamis, kita dapat menambahkan properti ketebalan sehingga pengguna dapat mengubah nilainya secara dinamis. ⚠️ untuk tidak disalahgunakan.
  • Pada aplikasi berskala besar, ini memungkinkan untuk memasukkan hanya gaya yang diperlukan untuk komponen yang ditampilkan di layar. Mengurangi jumlah pekerjaan yang dibutuhkan oleh browser untuk mem-bootstrap halaman. Karenanya, waktu lebih cepat untuk mengecat pertama setelah interaksi. Misalnya menyebariskan CSS kritis dengan SSR.
  • Izinkan pengguna untuk menggunakan tema dinamis dan variasi komponen. Misal mengubah warna sebuah tombol dengan semua variasi warna yang dibutuhkan.

@oliviertassinari Senang mendengarnya. Saya mungkin memiliki sudut pandang non-standar tentang modul CSS, tetapi saya rasa mereka tidak sepadan dengan semua keributan. Saya sangat senang mendengar tentang JSS melalui material-ui karena alasan ini. Tampaknya lebih sejalan dengan filosofi JavaScript daripada modul CSS.

@oliviertassinari terima kasih atas ringkasan manfaatnya. Sangat menarik jika Anda melihat aspek-aspek ini. Kelemahan dari JSS dan ekosistemnya (juga postcs) saat ini adalah bahwa semua itu sangat luar biasa dan Anda tidak dapat mengandalkan rantai alat dan basis pengetahuan yang mapan seperti dengan modul css + SASS sederhana. Tapi itulah harga yang Anda bayar untuk inovasi, itu hanya tergantung apakah Anda memiliki persyaratan tertentu / bersedia membayar harga bug dan jalur yang kurang terdokumentasi.

JSS telah dibuat sebelum modul-css. Modul CSS menjadi populer lebih cepat karena memecahkan masalah bagi sebagian besar pengguna tanpa mengubah sintaks terlalu radikal.

Meskipun demikian, Anda menggunakan react, yang juga merupakan teknologi "baru". Jika Anda ingin SASS, mungkin Anda juga harus memilih vanilajs atau backbonejs)

@kof React adalah cerita yang sangat berbeda karena digunakan oleh ratusan ribu pengembang dan dikelola oleh Facebook (tidak akan hilang dalam semalam), jadi ini mungkin "baru" tetapi sangat solid (belum mengalami banyak masalah dengan itu sejauh ini).

SASS adalah salah satu preprosesor css yang paling mapan dan dapat digunakan dalam proyek apa pun - sangat solid dan memberikan banyak nilai ke tabel. Jadi saya hanya akan memilih sesuatu seperti JSS jika benar-benar diperlukan (misalnya: karena tema dinamis) tetapi tidak suka membuang tahun pengalaman / kerangka kerja / basis pengetahuan dll dalam proyek perangkat lunak komersial dengan beberapa pengembang. Jadi saya bahkan akan mempertimbangkan untuk membangun hanya aspek tema dinamis di JSS dan sisanya dengan sass / css-modules.

Saya memahami cara berpikir ini, tetapi saya juga menganggapnya sebagai kontraproduktif dan menyalahkannya karena memperlambat inovasi dan industri.

Kenapa kamu tidak mendukung keduanya? Gaya yang ditulis dalam JavaScript DAN gaya yang ditulis dalam modul css? Jika saya melihat https://github.com/callemall/material-ui/blob/next/src/Button/Button.js misalnya, akan sangat mudah untuk menggunakan nama kelas yang diteruskan oleh prop ( https://github.com/javivelasco/react-css-themr) alih-alih menggunakan:

const classes = this.context.styleManager.render(styleSheet);

Bukan?

Sepertinya diskusi tentang penggunaan JSS atau CSS tidak menemukan akhir (belum?). Bagi saya itu terlihat seperti lima puluh / lima puluh saat ini.

Mengenai SASS, react-toolbox sedang bermigrasi darinya demi solusi postCSS lengkap , saya pribadi berpikir postCSS (dengan plugin sassLike) adalah pilihan yang lebih baik, lebih kuat tanpa build deps.

Styling di semua JS, dan khususnya di React, jelas masih dalam evolusi yang cepat. Jadi, apa pun yang Anda lakukan, saya akan mencoba untuk menghindari opini-opini - sesuaikan saja dengan serangkaian penggunaan saat ini.

Pertimbangkan hanya menambahkan prop * className di mana pun ada prop * style. Titik.

Pengungkapan penuh: Saya adalah pengguna Aphrodite yang bahagia.

Menambahkan className masih membutuhkan !important hacks karena gaya inline (dari style property) lebih diutamakan.

@ ligaz Tentu saja, Anda benar. Aphrodite menambahkan !important ke semuanya secara default, jadi mungkin pemikiran saya tentang "penggunaan yang luas" tidak tepat.

@ligaz @estaub - next sudah dikodekan _without_ style dan memungkinkan pengguna untuk mengganti komponen dengan menyediakan className (dan beberapa nama kelas ke berbagai bagian komponen kompleks) .

Setup paradigma styling pada cabang next oleh pengelola menggunakan JSS. Sangat menyenangkan untuk digunakan dan mudah diganti berdasarkan individu atau tema.

Kuda ini sudah mati. Mari berhenti menghajarnya. @oliviertassinari Saya sarankan Anda menutup dan mengunci masalah ini dengan pernyataan arah pada next .

Hai @rosskevin - dapatkah Anda menunjukkan kepada saya contoh apa pun tentang cara kerjanya selanjutnya?

Saat ini saya sedang mencari kerangka kerja untuk proyek baru, saya ingin menggunakan Material UI tetapi kami memerlukan perubahan yang Anda sebutkan di berikutnya. Saya telah menambahkan cabang berikutnya ke proyek pengujian dan menambahkan komponen sederhana dan saya melihat inspektur penuh gaya sebaris, jadi saya rasa saya melakukan sesuatu yang salah?

Detail lebih lanjut akan sangat membantu!

Terima kasih

@giuseppepaul next tidak diterbitkan pada npm karena ini adalah pra-alfa dan belum selesai. Anda dapat mengkloning https://github.com/callemall/material-ui.git#next dan menjalankan docs/site untuk melihat bahwa tidak ada lagi gaya sebaris. Ini juga memiliki jumlah demo yang masuk akal.

Saya menerbitkan versi pribadi saya selanjutnya (sehingga saya dapat mengontrol pembaruan) dan saya menggunakannya dalam aplikasi produksi segera.

Kuda ini sudah mati. Mari berhenti menghajarnya. @oliviertassinari Saya sarankan Anda menutup dan mengunci masalah ini dengan pernyataan arah selanjutnya.

Kuda itu belum mati sepenuhnya. Tapi pasti di tempat sempit 🔫.
Saya setuju, mari kita tutup masalah ini.

Terima kasih banyak kepada @nathanmarks atas kerja kerasnya pada cerita itu 👏!
Saya telah mengumpulkan lebih banyak informasi tentang perjalanan ke depan dengan # 5718.

Halo,
IconButton memiliki properti CSS3 transition untuk efek riak. Dalam interaksi kompleks dokumen Card @next , Anda telah menambahkan transition ke transformasi untuk menambahkan transisi saat ikon terbalik.
Jika saya melakukan hal yang sama pada aplikasi saya, satu transisi (riak atau pengembalian) menimpa yang lain (elemen tidak dapat memiliki dua properti, jika tidak, salah satu akan menimpa yang lain).
Namun ikon chevron Anda berhasil menerapkan dua transitions padanya. Karena bagaimanapun juga Anda menggabungkan transisi yang disediakan oleh IconButton dan transisi yang ditentukan dalam kode Anda. Bagaimana Anda mencapai itu?
Beberapa barang lain tidak jelas bagi saya dan saya tidak dapat menemukan dokumen terkait. theme memiliki banyak metode / properti sebagai breakpoints (tidak digunakan di sini) transitions (digunakan di sini). Apakah sudah ada dokumen tentang properti theme dari apa yang dikembalikan MuiThemeProvider.createDefaultContext() karena tampaknya berguna terutama karena digunakan secara ekstensif di dalam kode Anda.
this.context.styleManager.render(styleSheet) ? Apa ?
Anda juga menggunakan jss-theme-reactor yang saya masih belum mengerti maksudnya dibandingkan dengan react-jss .

@NitroBAY Utas ini selesai. Silakan ajukan pertanyaan Anda di saluran yang tepat. Jika Anda melihat bug atau ingin dokumentasinya diperbaiki, buka masalah. Jika tidak, Anda dapat menggunakan StackOverflow dari gitter.im.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat