Material-ui: Refactor CSS menjadi Javascript

Saya suka itu, tapi saya tidak tahu cara kerjanya di dunia nyata. Bayangkan memiliki banyak elemen, setiap elemen akan memiliki gaya kustom. Ini akan membuat dom besar. Bukankah ini masalah kinerja? (Saya telah membuat UI yang sama seluruhnya di react.js dengan gaya dan semuanya bekerja dengan baik, tetapi merupakan proyek uji kecil)

@ totty90 ya saya bertanya-tanya tentang ini, tetapi dari slide masalah di Facebook dari suara itu adalah bahwa semua file CSS dan kelas CSS adalah masalah kinerja.

Mungkin @vjeux dapat menjelaskan hal ini dan solusi yang disarankan dalam tayangan slide itu.

Mungkin untuk beberapa komponen yang lebih kecil ini mungkin solusi yang lebih baik?

Sunting: Hal lain yang saya tidak yakin adalah bagaimana menangani pertanyaan media dan daya tanggap?

Sudah memintanya untuk menunjukkan aplikasi dunia nyata menggunakan teknik ini. Ini menyelesaikan salah satu masalah terbaik: komponen datang dalam satu file. Saya dapat berbagi file dengan Anda dan Anda mendapatkan komponen saya diberikan persis seperti milik saya tanpa pengaturan apa pun dari bagian Anda. Tidak ada masalah css.

Ada proyek lain yang bertujuan untuk menyediakan cara yang baik untuk mengintegrasikan CSS-in-JS dan React - https://github.com/js-next/react-style dan juga beberapa pekerjaan awal pada komponen Material UI yang menggunakannya - https: //github.com/SanderSpies/react-material

Proyek ini memiliki lebih banyak daya tarik saat ini dan lebih banyak komponen yang diimplementasikan, tetapi react-material memiliki keuntungan bahwa komponen bekerja secara mandiri tanpa harus memaketkan file CSS. Anda juga mendapatkan semua manfaat yang diuraikan dalam presentasi @vjeux darinya.

Akan sangat bagus jika kedua proyek itu bisa digabungkan!

Proyek lainnya jauh lebih buruk. Satu-satunya bagian yang menarik adalah css di js.

Saya suka konsep menggabungkan JS dan CSS tetapi gaya inline buruk untuk kinerja browser dan menerapkan CSP. Mungkin menggunakan WebPack jika Anda khawatir?

Webpack tampaknya menjadi satu-satunya cara yang "masuk akal" untuk mengimpor gaya. Miliki require('component.css'); - tetapi kemudian Anda memiliki ketergantungan untuk komponen Anda. Mereka juga harus menggunakan Webpack! Saya tidak suka solusi itu. Seseorang harus dapat berbagi komponen dengan mudah, cukup instal, gunakan, dan untung.

Pendekatan saat ini di sini terlihat ramah pengguna. Ini tidak sempurna, tetapi menyalin beberapa baris impor cukup sederhana. Meskipun saya menyarankan agar menggunakan Less sekali lagi mengunci pengguna ke dalam preprocessor itu ...

Sulit membuat segalanya menjadi sederhana! Ada yang punya saran? Ini jauh lebih luas dari sekedar proyek ini. Seluruh komunitas reaksi / polimer / komponen membutuhkan solusi.

PS - menggabungkan CSS di dalam JS Anda sepertinya ide yang buruk. Untuk satu Anda akhirnya menulis CSS palsu dengan properti cased unta dan nilai yang dirangkai dan Anda secara kognitif mencampur masalah sehingga lebih sulit untuk bernalar tentang kode Anda. Saya tidak pernah mengalami masalah dalam menulis CSS. Ya, bisa jadi sulit dan ada yang salah (namespace global, konsekuensi yang tidak diinginkan, dll.) - tetapi mengalihkannya ke JS TIDAK akan memperbaiki masalah. Menulis CSS yang lebih baik.

@ pspeter3 apakah Anda memiliki tolok ukur? :)

Terutama dua JsPerf ini, http://jsperf.com/class-vs-inline-styles/2 dan http://jsperf.com/classes-vs-inline-styles. Namun http://jsperf.com/inline-style-vs-css-class/9 tampaknya menyiratkan sebaliknya. Buruk untuk kinerja adalah pernyataan yang berlebihan. Saya yakin Anda juga dapat menyebabkan kinerja buruk pada lembar gaya dengan menggunakan pemilih yang buruk. Apakah Anda memiliki saran tentang penerapan Kebijakan Keamanan Konten saat menggunakan gaya sebaris?

@bayu_joo

PS - menggabungkan CSS di dalam JS Anda sepertinya ide yang buruk. Untuk satu Anda akhirnya menulis CSS palsu dengan properti cased unta dan nilai yang dirangkai dan Anda secara kognitif mencampur masalah sehingga lebih sulit untuk bernalar tentang kode Anda. Saya tidak pernah mengalami masalah dalam menulis CSS. Ya, bisa jadi sulit dan ada yang salah (namespace global, konsekuensi yang tidak diinginkan, dll.) - tetapi mengalihkannya ke JS TIDAK akan memperbaiki masalah. Menulis CSS yang lebih baik.

Saya telah menulis banyak CSS dan CSS ke dalam JS. Yang pertama lebih mudah tetapi dalam proyek besar menjadi berantakan, yang lain saya pikir (karena saya hanya membangun aplikasi kecil) akan bekerja lebih baik di aplikasi yang lebih besar. Cobalah untuk memprogram aplikasi js dengan semua hal global + penggabungan, itu neraka !!! (Atau saya selalu salah melakukannya ...)

Ini tes yang saya lakukan dengan react.js http://jsperf.com/react-class-name-vs-inline-css2

Ya, saya berharap ada jawaban yang mudah untuk ini. :) Pada akhirnya, saya pikir ada manfaat dari kedua pendekatan tersebut.

Perhatian terbesar saya dengan memasukkan gaya di dalam komponen JS berkaitan dengan pemeliharaan kode. Misalnya, apa yang terjadi pada CSS yang diperlukan untuk penyetelan ulang lintas browser? Apakah gaya tersebut juga masuk ke dalam komponen? Juga, kami mendapatkan banyak kemudahan dengan menggunakan LESS seperti mixin, variabel, dll yang entah bagaimana akan kami ganti dan abstrak di dalam JS.

Dengan itu, kami telah memberi nama semua kelas CSS yang digunakan dalam proyek ini dengan "mui" dan kami mencoba untuk menulis CSS berorientasi objek. Di masa mendatang, mungkin harus ada beberapa proses yang memungkinkan pengguna memilih dan memilih komponen mana yang akan diunduh ke dalam build khusus.

Terima kasih atas masalahnya. Poin bagus yang diangkat adalah diskusi!

Apa yang sebenarnya membuat gaya sebuah komponen bukan menjadi bagian dari komponen itu daripada strukturnya (html) dan fungsionalitasnya (js)? Tampaknya bagi saya bahwa kita telah salah mengira metode untuk mengurangi satu masalah (pemeliharaan kode) sebagai pola desain yang secara inheren bijaksana dan lupa bahwa itu benar-benar sebuah tambalan. Arguably React adalah solusi yang lebih elegan untuk pemeliharaan masalah kode daripada membagi struktur, fungsionalitas dan gaya ke dalam bahasa mereka sendiri. Ini memiliki masalah sendiri (kecepatan dalam css case), tetapi jika kita setuju bahwa cara penyatuan kembali komponen penulisan ini baik, kita dapat mulai mencoba menyelesaikan masalah kecepatan.

Perlu dicatat bahwa menurut saya ini adalah salah satu kegagalan spesifikasi komponen web. Di mana ia mengelompokkan bahasa yang berbeda ke dalam satu modul, React menantang gagasan html dan css.

@mcwhittemore Ya, gayanya tidak kurang dari bagian komponen daripada HTML atau JS. Bersama-sama mereka bergabung untuk membuat satu komponen. Ini tidak mengharuskan komponen harus ditulis sebagai satu 'unit', begitulah cara mendistribusikannya.

Bereaksi dengan erat memasangkan struktur dan fungsionalitas. Ini memaksa Anda ke dalam pola ini dan menurut saya ini sederhana dan logis. Saya dapat dengan mudah memahami kode yang saya lihat, otak saya tidak kelebihan beban.

Di sisi lain CSS di dalam file JS membuat kode lebih sulit untuk saya pahami. Deskripsi gaya visual tidak sesuai dengan fungsionalitas dan struktur. Saya tidak hanya terganggu olehnya, saya bingung dan melambat karena saya harus memproses banyak masalah. Ini juga secara erat memasangkan gaya dengan komponen yang mempersulit penulis lain untuk menulis gaya mereka sendiri.

Saya ingin mendistribusikan komponen saya sebagai satu bundel. Pengembangan blok lego adalah impiannya! Sepertinya kita semua berada di halaman yang sama dengan tujuan akhir itu. CSS sebaris terdengar seperti perbaikan yang bagus tetapi saya tidak percaya ini adalah perbaikan yang tepat.

@jarsbe 100% setuju bahwa gaya membaca dalam komponen tidak cukup jelas. Hanya menemukan di mana gaya dibuat terkadang bisa sulit. Saya telah menggunakan file style.json dimana defaults dan permanents digabungkan dengan this.props.style banyak untuk kejelasan.

{
  "defaults": {
    "backgroundColor": "#efefef"
  },
 "permanents": {
    "width": "100%"
  }
}

Argumen lain yang menentang melakukan gaya di JS vs CSS adalah bahwa atribut style tidak memiliki kekuatan yang sama sebagai pemilih CSS. Misalnya saya tidak berpikir *:after saat ini kurang mungkin untuk diterapkan.

@mcwhittemore mencoba mendapatkan elemen psuedo persis apa yang membuat saya berkata, "huh? oh ya itu tidak ada dalam konteks ini ...". Ya, ekstraksi ke file lain memang membantu. Saya harus melihat sistem pada bespoke.js untuk menata tema baru. Saya pernah mendengar bahwa mengimplementasikan CSS di JS tetapi saya lelah.

@mcwhittemore mengapa Anda membutuhkan *:after ?

@ totty90 Saat ini bagian dari CSS. Mungkin ada cara untuk mengatasi masalah ini, tetapi ini bukan situasi "ubah css Anda ke js" yang sederhana. Apakah Anda memiliki solusi untuk pemilih :after atau :before yang tidak terpikirkan oleh saya?

IMO: setelah dan: sebelum adalah jenis peretasan dan saya tidak pernah membutuhkannya, saya ingin tahu untuk apa Anda membutuhkannya untuk memberi Anda solusi / pendapat.

@ totty90 Saya akan menyebutkan Anda dalam terbitan lain pada proyek lain agar tidak mengacaukan yang ini.

@ hai-cea Dengan mengingat alur kerja SMACSS (https://smacss.com/book/categorizing), pendekatan yang baik mungkin dengan menyimpan css untuk kategori _Base_, _Layout_ dan (mungkin) _Theme_ di file css lama yang bagus . _Module_ dan _State_ css sepertinya kandidat yang baik bagi saya untuk melakukan gaya JS.

@WRidder Terima kasih untuk tautannya - itu sangat masuk akal.

Pikiran acak yang saya tidak tahu harus meletakkannya di mana ... Bagaimana komponen asli menerapkan gaya? Saya membayangkan bahwa komponen react harus serupa dengan komponen asli. Ini mungkin tempat yang bagus untuk mencari ide.

Saya sangat skeptis dengan pendekatan penempatan CSS dalam JS ini - presentasi itu sendiri berbicara tentang masalah menghubungkan gaya dengan komponen seolah-olah belum ada upaya selama bertahun-tahun untuk melakukan hal itu dengan Shadow DOM. standar. Sekarang jelas React tidak menggunakan mekanisme itu saat ini tetapi saya tidak akan terkejut jika itu dilakukan pada waktunya.

Standar itu berfungsi karena menyediakan cara bagi pembuat komponen untuk mengaitkan beberapa set minimal gaya dasar dengan komponennya yang kemudian dapat diganti oleh desainer yang menjangkau shadow DOM. Masih jauh dari jelas bagaimana seorang desainer akan mengganti gaya yang diatur murni dalam Javascript jika mereka sendiri tidak menggunakan komponen dengan react secara langsung.

Saya baru saja kembali dari react conf dan terima kasih banyak kepada @vjeux karena telah mengaturnya. Saya juga skeptis dengan pendekatan ini, tetapi menurut saya pendekatan ini memiliki kelebihan. Proyek ini memiliki beberapa tantangan yang ingin saya selesaikan dengan bantuan jika kita menggunakan pendekatan ini.

1. Kami ingin komponen ini dapat diberi tema. Mereka akan memiliki beberapa gaya default, tetapi pengembang harus dapat mengubah tampilan agar sesuai dengan kebutuhan mereka. Saat ini, mereka dapat melakukannya dengan mengganti variabel tertentu di LESS. Bagaimana kami bisa menawarkan kemampuan yang sama menggunakan gaya js?
2. Sering kali, komponen akan menghasilkan turunan bersarang. Bagaimana kami mengizinkan developer menyesuaikan gaya pada anak bertingkat. Naluri saya adalah bahwa kita hanya boleh mengekspos alat peraga gaya pada anak-anak yang dapat disesuaikan? Tetapi apakah ini akan memasangkan gaya kita dengan erat dengan struktur dom komponen? Yang saya maksud adalah, jika kita akhirnya mengubah struktur dom sebuah komponen, apakah kita juga akan mengubah alat peraga gayanya?

Terima kasih atas semua bantuan dan umpan balik Anda sejauh ini - Saya menantikan pendapat semua orang.

Apakah ada video tentang ide ini di konferensi React?

@vjeux Menyinggung sedikit di pembicaraan React Native - http://conf.reactjs.com/schedule.html#react -native

Dia juga bercerita tentang ceramah yang dia berikan di NationJS, tapi saya tidak tahu apakah ada audio?
http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html

Hai @ hai-cea,
Tim saya memiliki eksperimen yang sangat kecil pada masalah tema. Solusi tim saya adalah pustaka materi ui mengekspos fungsi untuk mengatur tema:
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/src/index.js

Saat kita menggunakan material-ui kita memanggil fungsi ini dengan properti custom define. Dan material-ui akan memanggil pembaruan fungsi ini. Anda dapat melihat di:
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/src/js/scaffold-styles.js

dan contoh yang kami gunakan di file ini:
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/src/js/raised-button.jsx
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/example/src/app/custom-styles.js
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/example/src/app/components/main.jsx

Terima kasih @ cuongcua90 - Saya punya ide yang sama seperti milik Anda.

Akan ada objek tema yang akan menangani semua variabel yang ditentukan di custom-variable.less . Pengembang dapat mengganti variabel ini saat inisialisasi aplikasinya dengan metode pembantu seperti ini:

//Override Theme Variables
Theme.set({
  textColor: 'red'
});

Untuk memberikan kontrol gaya yang lebih terperinci, setiap komponen akan menggunakan alat peraga gaya yang akan digabungkan dengan gaya default:

//merge styles that are passed in
var styles = this.mergePropStyles(defaultStyles, this.props.style);

Juga, temui beberapa tantangan lain dalam pengujian saya:

1. Bagaimana kita menangani prefiks vendor?
2. Bagaimana dengan pertanyaan media?

hey @ cuongcua90 dan @ hai-cea - bagaimana jika kita memanfaatkan framework lain untuk melakukan ini? Saya belum banyak membaca tentangnya, tetapi tampaknya http://jhudson8.github.io/fancydocs/index.html#project/jhudson8/react -css-builder? Focus = outline mungkin cocok.

Ini mendukung mixin dan variabel.

Tuan-tuan,

Saya telah membuat cabang css-in-js untuk menangani masalah ini dan memiliki prototipe di folder contoh.

Pengembang memiliki 2 poin untuk penyesuaian. Pertama adalah mengganti variabel tema default. Variabel akan mencakup hal-hal seperti warna komponen, tampilan font, dll.
https://github.com/callemall/material-ui/blob/css-in-js/example/src/app/app.jsx#L16

Untuk kontrol yang lebih terperinci, pengembang juga dapat mengganti gaya komponen default melalui props:
https://github.com/callemall/material-ui/blob/css-in-js/example/src/app/components/main.jsx#L10

Berikut adalah contoh bagaimana kami akan mengimplementasikan komponen di sisi MUI:
https://github.com/callemall/material-ui/blob/css-in-js/src/js/svg-icons/svg-icon.jsx

Anda dapat melihat bahwa kami akan menangani penggabungan dalam vars tema, props gaya, dan juga prefiks otomatis berdasarkan deteksi fitur.

Ada masukan tentang pola ini?

Memindahkan semua CSS ke dalam sistem berbasis JS akan menyenangkan, dan akan menyelesaikan # 316. Saya tidak yakin seberapa banyak yang diketahui dalam hal pemeliharaan, dan beberapa gaya umum berlaku untuk elemen _all_ (mis. Reset dan hal-hal di less/core/ ), jadi saya tidak yakin apa yang direncanakan untuk bagaimana mendapatkannya gaya tersebut menjadi aplikasi orang. Beberapa pertanyaan terbuka, tapi pasti sangat menarik.

kita bisa membuat semacam sistem pewarisan klasik untuk membuat objek gaya. dengan cara itu untuk gaya umum hanya ada objek BaseStyle yang dapat diwariskan.

Saya ingin tahu untuk memahami masalah sebenarnya yang Anda coba selesaikan dengan mencampurkan CSS ke JS.

1- Buat bangunan lebih mudah karena kita tidak perlu khawatir tentang "Di mana CSS yang saya perlukan untuk ini?"
2- Tema JavaScript?
3- Ganti gaya?

Masalah ini ada sejak awal, dan dalam kasus saya semuanya diselesaikan dengan memiliki struktur folder sederhana ditambah "halaman. (Css | less | sass)" dengan aturan @import , semuanya relatif terhadap file.

Bisakah seseorang menjelaskan / menjelaskan / berbagi mengapa mencampurkan CSS ke JS adalah ide yang bagus?

Terima kasih atas waktunya!

Saya bukan pembuat paket, tetapi membuat gaya secara dinamis dengan JS adalah sesuatu yang menjadi lebih populer belakangan ini.

Ada sejumlah masalah dengan CSS secara umum. CSS dikompilasi dengan sejumlah variabel statis, seperti (misalnya) ukuran grid Anda, warna tipe utama Anda, dan lain-lain. Anda tidak dapat mengubahnya setelah itu, kecuali jika Anda secara manual memilih elemen yang terpengaruh dan menyetel gaya khusus yang menggantikan CSS yang dikompilasi.

Menempatkan CSS di JS berarti itu menjadi sepenuhnya dinamis, dan Anda dapat mengubah variabel apa pun yang mendasarinya sesuka hati. Ini juga berarti (khususnya dalam kasus React) bahwa Anda dapat menyimpan gaya yang relevan di dalam komponen.

Saya tidak 100% menjualnya. Ini juga berarti Anda tidak memiliki gaya sampai JS selesai memuat. Bukan masalah besar dalam kasus aplikasi satu halaman, tetapi sesuatu yang mungkin memerlukan pemikiran di masa depan. (Atau mungkin rendering sisi server sudah menangani ini dengan cara yang efisien? Saya juga berharap mendengar dari seseorang yang memiliki lebih banyak pengalaman benar-benar melakukan ini.) Memiliki file CSS terpisah juga berarti browser dapat mulai memuat gaya secara paralel .

@dendril - Presentasi yang diberikan @vjeux menjelaskan masalah dengan CSS dalam skala besar. Beberapa masalah yang menggunakan JS untuk memecahkan CSS penulis meliputi:

• Modul, variabel, kalkulasi, dan mixin semuanya dapat menggunakan alat yang sudah ada yang sudah dimiliki JS - modul CommonJS, variabel JS, ekspresi JS daripada harus menggunakan sintaks dan seperangkat alat terpisah untuk mengelolanya.
• Anda dapat menggunakan alat JS yang ada untuk mencari tahu di mana gaya tertentu dirujuk. Anda dapat mengambil ini lebih jauh dengan FlowType dan TypeScript untuk mendapatkan kesalahan waktu kompilasi jika Anda salah mengetik nama kelas misalnya.
• Anda dapat menentukan struktur, tampilan, dan logika di satu tempat - yang merupakan langkah berguna untuk mempermudah penggunaan kembali komponen. Komponen Web memecahkan masalah ini dengan impor HTML. Mendefinisikan segalanya dengan satu bahasa adalah pendekatan lain.
• Melakukan hal-hal dinamis dengan CSS lebih mudah. Karena gaya statis dan dinamis diterapkan dalam bahasa yang sama, Anda dapat berbagi konstanta, dll. Di antara keduanya.

Sebagai contoh, saya memiliki implementasi tombol gaya Desain Material menggunakan gaya inline TypeScript + di sini: https://github.com/robertknight/passcards/blob/master/webui/controls/button.ts .

• Tema + struktur tombol ada di satu tempat, yang berguna untuk pengembangan dan penggunaan kembali. Dengan menggunakan IDE, Anda dapat dengan mudah menemukan di mana semua elemen tema tertentu direferensikan.
• Dalam fungsi render () saya bisa membangun gaya untuk tombol tergantung pada props dengan mereferensikan bagian dari tema dengan cara yang sederhana tanpa harus menggabungkan string nama kelas.
• Saat menentukan tema, saya dapat menggunakan JS untuk menghitung warna tertentu menggunakan rumus yang ditentukan oleh spesifikasi desain material (Lihat colors.premultiplyColor() )

Ada trade-off di sini yang merupakan trade-off yang biasa dari pendekatan deklaratif vs. imperatif untuk menentukan sesuatu. Bahasa imperatif (JS) memberi Anda banyak kekuatan. Sintaksnya lebih bertele-tele dan fleksibilitasnya terbuka untuk penyalahgunaan. Untuk komponen yang kompleks dengan banyak gaya dinamis, keseimbangannya berpihak pada JS. Untuk gaya statis yang mudah diekspresikan dalam CSS, tidak terlalu banyak. Saya tidak akan menggunakan pendekatan ini untuk konten seperti dokumen.

@msikma - Menentukan gaya di JS tidak harus berarti menggunakan gaya sebaris atau menunggu aplikasi Anda dimuat. Anda dapat menggunakan JS hanya sebagai bahasa untuk membuat gaya yang dikompilasi ke JS - pada dasarnya alternatif untuk SASS atau LESS. Gabungkan ini dengan rendering sisi server dan output aktual yang didapat browser dapat terlihat sangat mirip dengan CSS dan berfungsi dengan baik dengan alat pengembang browser.

@robertknight Terima kasih banyak atas jawaban Anda, Anda baru saja menambahkan informasi yang cukup untuk memahami gagasan sepenuhnya.

Saya lebih suka evolusi SASS / LESS daripada menambahkan lebih banyak JavaScript ke pertunjukan, pada akhirnya, jika Anda ingin menggunakan kembali mekanisme, kami dapat meningkatkan LESS yang dikodekan dalam JavaScript, dan menggunakan kembali sebanyak yang kami inginkan dari JavaScript, tetapi tampaknya mudah untuk mendesain API baru dan mulai menggabungkan semuanya dalam satu file.

Semoga kita menemukan solusi yang lebih baik, karena kehilangan ide deklaratif CSS bukanlah ide yang baik, dan kurang ketika kita membuat semuanya deklaratif daripada imperatif. \Hai/

@msikma - Menentukan gaya di JS tidak harus berarti menggunakan gaya sebaris atau menunggu aplikasi Anda dimuat.

Apakah mungkin untuk mendeklarasikan gaya secara global (dengan membuat elemen gaya secara dinamis)? Menurutku begitu, karena itu penting.

Bagaimana Anda menghindari keharusan menunggu JS dimuat?

@ikma - Ya. Dalam contoh yang saya tautkan, semua gaya dalam 'theme' var yang didefinisikan di bagian atas file dikompilasi ke CSS pada waktu pembuatan. Dalam fungsi render (), ada panggilan ke style.mixin (theme.someElement, otherProps) yang mengembalikan objek dengan properti className yang merupakan daftar nama kelas yang dipisahkan spasi biasa. Jika Anda menjalankan React di server, Anda akan mendapatkan string HTML normal dengan elemen yang memiliki atribut 'class' dan 'style' yang dapat dirender pada klien tanpa menjalankan kode apa pun.

@dendril - Alternatif untuk CSS deklaratif tidak harus JS wajib. JS dapat ditulis dengan cara fungsional / deklaratif - semua gaya statis dapat berupa objek Javascript sederhana. Jika Anda perlu mereferensikan konstanta yang sama (mis. Warna atau ukuran font) dalam gaya dinamis dan gaya statis, itu menjadi mudah dilakukan.

Terima kasih untuk penjelasannya, terdengar sangat bagus.

Saya baru saja masuk ke utas ini, tetapi saya tertarik karena saya mencoba mengembangkan proyek dengan material-ui. Saya telah beralih ke versi SASS, setelah menemukan bahwa tidak ada sistem grid yang diimplementasikan dalam material-ui dan kemudian menyadari bahwa versi SASS tidak sinkron. Jadi saya cukup penasaran untuk mengetahui arah proyek ini di masa depan. Tampaknya ada begitu banyak pengorbanan dengan menempatkan css ke dalam komponen itu sendiri sehingga itu bukan pilihan yang jelas. Secara intuitif, saya menemukan ide itu agak berbahaya karena ini adalah bentuk keberangkatan radikal yang sampai saat ini menjadi praktik web dev. Di sisi lain, React!

@ hai-cea Sudahkah Anda mempertimbangkan perpustakaan JSS ? Saya telah menggunakannya untuk proyek React baru yang sedang saya kerjakan, dan sejauh ini saya sangat menyukainya. Yang menyenangkan adalah Anda memiliki opsi untuk menyatakan nama kelas global jika Anda membutuhkannya pada kesempatan langka. Hampir semua hal yang dapat Anda lakukan di css dapat Anda lakukan di JSS karena JSS membuat kelas dengan namespace sendiri dan menambahkannya ke tag <style> di <head> .

Ada proyek baru tentang gaya React untuk Anda pertimbangkan. Ini tautannya: Radium

Baru saja melihat utas ini dan berharap saya telah menemukannya sebelumnya. Kami melakukan CSS di JS pada tema iOS yang termasuk dalam reapp-ui . Itu dalam pengembangan selama beberapa bulan sebelum rilis.

Sebenarnya @ hai-cea saya mendapatkan sistem yang sangat mirip dengan milik Anda.

1. Muat " konstanta " (pikirkan: warna, deteksi fitur). Kami sebenarnya melakukan dua tingkat konstanta, pertama adalah deteksi fitur dan warna, kedua adalah konstanta untuk komponen tertentu .
2. Muat gaya untuk komponen . Ini sebenarnya memiliki struktur yang konsisten. Objek dengan kunci yaitu "ref" => "stylesObj".
3. Muat animasi .

Inilah cara Anda memuat tema bersama-sama dengan tiga elemen. Dan inilah cara Anda memuat tema kustom yang mencampur dan mencocokkan tema dasar dengan variabel Anda sendiri ke "theme" -nya.

Ini memiliki beberapa manfaat yang sangat luar biasa:

1. Pengguna tidak perlu memuat gaya tambahan yang tidak mereka butuhkan.
2. Komponen memiliki nama dan deklarasi gaya yang konsisten.
3. Semuanya dapat bertema di setiap level.
4. Mudah menambahkan tema untuk platform lain.

Kami menggunakan gaya reaksi untuk semua ini dan ini bekerja dengan sangat baik. Bersama dengan campuran Bergaya yang memungkinkan kita melakukan penambahan gaya deklaratif yang sangat mengagumkan. Itu, dan mixin Tappable juga memberikan status Fokus / Aktif. Keduanya akan diekstraksi dalam waktu singkat.

Sebenarnya ada sedikit lebih banyak dari itu semua yang ingin saya tulis di dokumen resmi segera.

Langkah kami selanjutnya sebenarnya adalah membuat tema UI material di Reapp, dan saya telah menandai proyek ini untuk sementara waktu. Ingin tahu apakah kita tidak bisa bekerja sama dalam hal itu!

@ hai-cea Objek Theme akan benar-benar cocok dengan fitur konteks React. Jika Anda tidak terbiasa dengannya, konteks pada dasarnya adalah alat peraga yang secara otomatis diturunkan ke hierarki komponen Anda. Pada tingkat tertentu dalam hierarki, komponen dapat menanyakan konteksnya untuk beberapa nilai.

Dalam kasus Anda, saya akan merekomendasikan pengaturan variabel theme pada konteks. Ini akan bekerja seperti ini:

var App = React.createClass({
  childContextTypes: {
    theme: React.PropTypes.instanceOf(Theme)
  },
  getChildContext() {
    return {
      theme: CustomTheme
    };
  },
  // ...

Kemudian, dalam komponen <Button> Anda dapat melakukannya

var Button = React.createClass({
  contextTypes: {
    theme: React.PropTypes.instanceOf(Theme)
  },
  getTheme() {
    return this.context.theme || DefaultTheme;
  },
  render() {
    return <button style={this.getTheme().getButtonStyle()}>...</button>;
  }
});

Hal yang saya suka tentang pendekatan ini:

• Tidak ada objek Theme global
• Seluruh bagian UI dapat diberi tema hanya dengan mengubah konteks dalam satu komponen induk (pikirkan bertema seluruh modal dengan satu deklarasi)

Bagaimanapun, pekerjaan luar biasa yang kalian lakukan di sini. Saya harap ini membantu :)

Hy!
Saya telah membuat perpustakaan untuk menulis css ke dalam tampilan react, lihatlahhttps: //github.com/hackhat/smart-css

Kegunaan: Menulis CSS dalam JavaScript dengan namespace, nama yang tepat, tidak ada konflik dan hasil yang diharapkan untuk react.js.

@mjackson Saya sangat suka pendekatan Anda dalam mengirimkan konteks tema ke bawah hierarki, tetapi bagian ini

this.getTheme (). getButtonStyles ()

Tidak cukup skalabel karena tema harus tahu tentang gaya. Saya pikir tema harus berupa nama, palet warna dan beberapa definisi jarak, tapi bukan gaya css yang lengkap. Ini akan mengaktifkan komponen dan aplikasi yang benar-benar dapat disesuaikan dan dapat diskalakan.
Bagaimana menurut anda?

@ mjackson Saya suka konteks Idea. Kami menggunakan dekorator yang pada dasarnya melakukan hal yang sama.

@hackhat Ya, jika Anda melakukan konstanta dengan benar, Anda dapat memuat sebanyak yang Anda inginkan sehingga Anda dapat melapisinya. Mulailah dengan "dasar" untuk warna, lalu miliki "komponen" untuk spesifik, dll. Ini adalah bagaimana kita dapat mengizinkan "tema" untuk bekerja dari materi ke iOS ke Window (di masa mendatang).

Bagaimanapun, semoga berhasil dengan semuanya! Saya pikir kita sedang menuju ke arah yang sama tapi itu hal yang baik. Jika Anda tertarik untuk bergabung, hubungi kami. Karena kami telah membangun seperangkat hal yang sangat besar untuk iOS dan Anda Android dan kami telah menjelajahi cukup banyak hal-hal CSS / JS, bisa jadi berguna. Apa pun itu, saya telah menambahkan beberapa dokumen di sini tentang kontribusi untuk itu: https://github.com/reapp/reapp-ui/issues/29.

Maaf untuk threadjack, baru saja melihat peluang untuk beberapa kerja tim: +1:

@natew Senang mendengar tentang proyek Anda. Sepertinya kita berada di jalur yang benar. :)

@mjackson Terima kasih telah memberi tahu saya tentang fitur konteks React - Saya belum pernah menggunakannya sebelumnya, tetapi saya mendengarnya disebutkan di konferensi react dan juga melihatnya digunakan di React Router. Sepertinya solusi yang bagus - saya pasti akan mencobanya.

Kami telah membuat kemajuan yang cukup baik dalam memindahkan gaya ke js. Menurut saya salah satu keuntungan terbesar yang saya lihat adalah kami menjadi lebih eksplisit tentang gaya setiap komponen. Sejauh ini, kami belum merasa perlu menggunakan library seperti JSS, Radium, atau React Styles. Meskipun saya bisa diyakinkan sebaliknya.

Saya tidak sabar untuk menyelesaikan perubahan arsitektur ini sehingga kita dapat kembali memperkuat komponen yang ada.

Apakah perubahan ini akan mempersulit penggantian gaya default?

@DylanPiercey pertanyaan bagus. Seperti yang disebutkan @ hai-cea, kami belum merasa perlu menggunakan pustaka terkait gaya. Semua gaya komponen akan ditentukan sebaris, jadi tidak akan ada lagi file Less (selain yang ada di situs dokumen).

Ini adalah pendekatan kami untuk mengganti gaya saat ini:

• Komponen juga akan diberi style prop untuk mengganti gaya sebaris dari elemen akar komponen. Ini akan dilakukan oleh mixin StylePropable .
  
  
  
  • Komponen _Some_ akan memiliki props tambahan untuk menata elemen komponen internal. Komponen tanpa alat peraga tambahan ini tidak akan memiliki akses untuk mengganti gaya ini. Ini adalah perubahan kerusakan yang
  
  
• Untuk pengguna yang masih menggunakan Less, komponen akan diberi className prop ke elemen root mereka, sehingga pengguna dapat menambahkan gaya tambahan (ini adalah tujuan saat ini untuk mixin Classable kami).
• Perubahan lain yang semua file Less termasuk variabel Less. Ini akan mengubah mui dari css-framework dan kumpulan komponen react menjadi _only_ menjadi satu set komponen react. Kami yakin bahwa pergeseran ini lebih tepat karena kami terus menyelesaikan lebih banyak komponen Desain Material.

Satu hal terakhir: Kami juga akan menyediakan file Tema menggunakan fitur konteks react seperti yang disarankan oleh @mjackson untuk penyesuaian tambahan.

Apa pendapat semua orang tentang pendekatan ini?

Omong-omong kami merilis tema melalui konteks dengan reapp-ui . Anda melakukannya seperti ini:

const theme = {
  styles: {
    List: {
      self: { background: '#000', ... }
    }
  },
  animations: {},
  constants: {}
}

// top level component
export default React.createClass({
  render() {
    return (
      <Theme {...theme}>
        <RouteHandler />
      </Theme>
    );
  }
});

Lihat file Tema untuk mengetahui cara mengatur konteksnya:
https://github.com/reapp/reapp-ui/blob/4355556dee24407e5e7827df7a484944aeaf32cc/helpers/Theme.jsx

Kami juga merasa terbantu menggunakan konstanta sebagai lapisan tingkat pertama sehingga Anda dapat menyetel semua jenis properti dari isRetina hingga listBorderColor dan kemudian konstanta tersebut diteruskan ke gaya saat dimuat melalui helper . Penggunaan seperti ini:

import UI from 'reapp-ui';

UI.addConstants({
  borderColor: '#000'
});

UI.addStyles({
  List: c => ({
    firstItem: {
      border: `1px solid ${c.borderColor}`
    }
  })
})

// exports the theme object you need for the <Theme /> helper
export default UI.makeTheme()

Saya pikir ini mungkin berguna untuk dilihat saat kalian menyelami lebih dalam.

@natew Saya telah condong ke arah pendekatan ini. Bisakah Anda menjelaskan arti dari c ? Saya tidak terlalu akrab dengan fungsi panah lemak ES6. Apakah c parameter konstanta baru? Saat ini, gaya-sebaris diganti menggunakan gabungan dangkal React melalui mixin StylePropable kami.

Namun, metode ini tidak menangani objek json bersarang kecuali mereka diteruskan secara eksplisit. Kami telah berbicara tentang menggunakan penggabungan rekursif, tetapi ini akan mahal karena setiap komponen akan menggunakan fungsi penggabungan beberapa kali. Melihat bahwa kami sudah menggunakan ES6, ini terlihat menjanjikan.

Saya suka ide refactoring material-ui's CSS menjadi Javascript!

Tapi saya mengalami beberapa masalah buruk ketika saya mencoba menggunakan gaya inline di JS daripada LESS di salah satu proyek saya ...

Safari: Bug gaya riak pada komponen tombol

Masalah terbesarnya adalah yang ini: https://github.com/callemall/material-ui/issues/496
Saya hanya bisa mengatasi masalah Safari dengan menggunakan grunt-autoprefixer
Tapi autoprefixer hanya bekerja untuk KURANG / CSS. Jadi pada saat itu saya harus meninggalkan gaya sebaris dan menulis ulang aplikasi saya untuk menggunakan LESS. (Itu menyedihkan ...)

Gaya semu dan pemilih media tidak didukung

Beberapa fitur CSS seperti semua gaya semu dan pemilih media tidak didukung oleh gaya sebaris react. Pada awalnya saya menggunakan LESS untuk bagian yang hilang dan gaya sebaris untuk sisanya.

Menambahkan "px" secara otomatis ke angka

Ada banyak properti di mana react inline styles memutuskan untuk menambahkan px ke sebuah angka. Misalnya order: 1 menjadi order: 1px , yang tidak masuk akal.
Harus berurusan dengan px tidak diinginkan tampaknya menjadi masalah umum, lihat https://github.com/facebook/react/pull/3499

Dukungan minifikasi yang buruk

Saya harus menggunakan Closure Compiler Google dengan ADVANCED_MODE untuk proyek saya. Ketika saya mencoba menggunakan gaya react inline, saya akhirnya mengeluarkan setidaknya properti ini:

/**
* <strong i="27">@type</strong> {*}
*/
var __REACT_DEVTOOLS_GLOBAL_HOOK__;

/**
* <strong i="28">@type</strong> {*}
*/
var Symbol;

/**
* <strong i="29">@type</strong> {*}
*/
var MSApp;

Selain itu, saya harus menggunakan string untuk nama properti seperti backgroundSize dan float .
Misalnya, alih-alih menggunakan

var iconStyle = {
  backgroundSize: "300px 400px",
  float: "left"
};

Saya harus menggunakan string sebagai gantinya untuk dapat mengkompilasi dengan Closure Compiler Google di ADVANCED_MODE

var iconStyle = {
  'backgroundSize': "300px 400px",
  'float': "left"
};

Tapi selain masalah itu semuanya baik-baik saja!
Jangan salah paham: Saya pikir gaya sebaris adalah cara yang tepat. Hanya ada beberapa gundukan di sepanjang jalan. Saya berharap semua masalah itu akan diatasi oleh Facebook, yaitu @vjeux.

Terima kasih atas masukan semua orang, kami dapat menyelesaikan lebih sedikit refaktor untuk gaya sebaris kemarin! Master saat ini berisi prarilis v0.8.0 untuk kalian periksa, dan kami akan sangat senang dengan masukan yang mungkin Anda miliki.

Anda juga dapat menjalankan situs dokumen secara lokal untuk melihat dokumentasi yang diperbarui. Berikut beberapa sorotan tentang apa yang dapat kami capai:

1. Semua gaya komponen sekarang dilakukan sebaris. Ini tidak hanya memungkinkan kami untuk lebih eksplisit tentang gaya yang ada di setiap komponen, tetapi juga membuat setiap komponen jauh lebih portabel. Karena tidak ada ketergantungan kurang / css eksternal, Anda seharusnya dapat meminta setiap komponen yang Anda butuhkan. Selain itu, gaya dari pustaka MUI tidak akan bertentangan dengan gaya dari aplikasi Anda sendiri.
2. Kustomisasi dapat dicapai pada 2 level. Anda dapat mengganti variabel tema yang akan mempengaruhi semua komponen anak menggunakan objek konteks tema. Selain itu, setiap komponen menerima prop gaya yang dapat Anda gunakan untuk mengimplementasikan kustomisasi grain yang lebih halus.
3. Awalan vendor otomatis dilakukan melalui deteksi fitur menggunakan Modernizr yang dibuat khusus dan ringan. Prefixing hanya dilakukan saat dibutuhkan dan menjadi bagian terbaik? Ini dilakukan secara otomatis untuk Anda dalam setiap komponen.

Saya ingin memiliki master panggang ini selama satu atau 2 minggu sebelum merilisnya. Selama waktu ini, kami akan bekerja untuk mengumpulkan kode contoh dan mengonversi beberapa gaya situs dokumen untuk menggunakan gaya sebaris.

Sekali lagi terima kasih atas masukan dan kesabaran semua orang. Kami sangat menantikan untuk merilis ini dan kembali menangani masalah dan menambahkan komponen baru. :)

Apakah kita perlu melakukan sesuatu selain hanya menggunakan komponen?

Perhatikan bahwa saya mencoba mengemasnya sebagai paket meteor (pada dasarnya menggunakan browserify untuk menggabungkan semua komponen) dan saya mungkin melakukan kesalahan.

Sepertinya kita harus membuat instance ThemeManager dan menyetelnya sebagai tema childContext pada komponen tempat kita menggunakan komponen material-ui.

EDIT: theme telah diganti namanya menjadi muiTheme

Hai @ukabu , ThemeManager hanya perlu dibuat di bagian paling luar komponen aplikasi Anda. Itu kemudian akan diwariskan kepada semua anak dan cucunya. Anda dapat membaca lebih lanjut tentang fitur konteks React di sini dan di sini .

Sertakan kode ini di komponen terluar Anda:

Jika Anda menggunakan ES6

var React = require('react');
var mui = require('mui');
var ThemeManager = new mui.Styles.ThemeManager();
class OuterMostParentComponent extends React.Component {
  // Important!
  getChildContext() { 
    return {
      muiTheme: ThemeManager.getCurrentTheme()
    };
  }
};
// Important!
OuterMostParentComponent.childContextTypes = {
  muiTheme: React.PropTypes.object
};
module.exports = OuterMostParentCompone

Jika Anda menggunakan ES5

var React = require('react');
var mui = require('mui');
var ThemeManager = new mui.Styles.ThemeManager();
var OuterMostParentComponent = React.createClass ({
  // Important!
  childContextTypes: {
    muiTheme: React.PropTypes.object
  },
  // Important!
  getChildContext: function() { 
    return {
      muiTheme: ThemeManager.getCurrentTheme()
    };
  }
});
module.exports = OuterMostParentComponent

Dokumentasi lebih lanjut tentang cara menggunakan Tema dapat dilihat jika Anda menjalankan dokumen secara lokal dan membuka #/customization/themes

Terima kasih. Ini berfungsi sekarang: +1:

Sekarang semua gaya menjadi sebaris, kita masih perlu mengatur ulang css. Sepertinya tidak ada file css atau lebih sedikit di dalam src / tree. Apakah Anda berencana menambahkan satu?

@ hai-cea @mmrtnz Selamat! Apakah Anda memiliki resep untuk kode yang bergantung pada CSS Pseudo-class ? Saya pasti akan melewatkan :hover , lihat https://github.com/reactjs/react-future/issues/13 . @vjeux merekomendasikan menggunakan onMouseOver tapi itu merepotkan . Apakah 0.8.0 dilengkapi dengan kode pengganti yang berguna untuk :hover ?

@bparadie Saya berubah pikiran tentang ini. Saya rasa saya ingin yang berikut ini berhasil:

<div
  style={{color: 'blue'}} 
  hoverStyle={{color: 'red'}}
/>

@vjeux apakah Anda berbicara di tingkat kerangka kerja React atau apakah itu hal yang akan diterapkan oleh proyek secara individual? karena pada level kerangka itu akan menyenangkan ...

Itu meminta beberapa variasi meskipun seperti pressedStyle focusedStyle disabledStyle (untuk input) dll.

Juga, selamat kepada semua orang yang telah mengerjakan ini, pencapaian besar: senyum:

Saya bertanya-tanya meskipun mungkin lebih baik menggunakan kunci konteks yang lebih spesifik untuk temanya? misalnya muiTheme - maka ini tidak akan konflik jika ada pustaka lain di halaman yang juga ingin menggunakan kunci konteks itu, atau jika saya ingin menggunakan context.theme di aplikasi saya untuk milik sendiri.

@vjeux Saya suka itu!

@tokopedia

Ini adalah kegunaan yang telah saya coba untuk membuat gaya hover sedikit kurang menyebalkan ...

'use strict';

const React = require('react');

const withHoverStyle = (Component, compType) => {
  class ComponentWithHover extends React.Component {
    _handleMouseOver() {
      const theme = this.context.theme.component[compType];

      React.findDOMNode(this).style.backgroundColor = theme.hoverColor;
    }

    _handleMouseOut() {
      const theme = this.context.theme.component[compType];

      React.findDOMNode(this).style.backgroundColor = theme.color;
    }

    render() {
      const hoverProps = {
        onMouseOver: this._handleMouseOver.bind(this),
        onMouseOut: this._handleMouseOut.bind(this)
      };

      return React.createElement(Component, Object.assign({}, this.props, hoverProps));
    }
  }

  ComponentWithHover.contextTypes = {
    theme: React.PropTypes.object
  };

  return ComponentWithHover;
};

module.exports = withHoverStyle;

https://github.com/troutowicz/geoshare/blob/css-in-js/app/utils/withHoverStyle.js

Bisa digunakan seperti ini:

'use strict';

const React = require('react');
const FlatButton = require('material-ui/lib/flat-button');

const withHoverStyle = require('../utils/withHoverStyle');

class AuthButton extends React.Component {
  render() {
    return <FlatButton {...this.props} />;
  }
}

AuthButton.propTypes = {
  label: React.PropTypes.string,
  onClick: React.PropTypes.func
};

AuthButton.defaultProps = {
  label: 'Login',
  onClick() {}
};

module.exports = withHoverStyle(AuthButton, 'flatButton');

https://github.com/troutowicz/geoshare/blob/css-in-js/app/components/AuthButton.jsx

Saya menginginkannya di level React dan juga di level dom :) Tidak jelas kapan saya akan mengimplementasikannya

@troutowicz Terima kasih telah berbagi!

Hy!
Saya pernah melihat Anda berbicara tentang css di js untuk sementara waktu. Berikut adalah perbandingan CSS dalam JS https://github.com/hackhat/css-in-js-comparison . Sudah mengulas 3 libs, mungkin menarik untuk melihat pendekatan yang berbeda untuk masalah ini.

Lihat juga di https://github.com/hackhat/smart-css , Anda tidak perlu onMouseOver untuk menambahkan ": hover"

Adakah yang punya umpan balik tentang ide saya untuk menggunakan kunci konteks yang berbeda untuk theme ? misalnya muiTheme

@vjeux jika Anda mengarahkan saya ke arah yang benar untuk mengimplementasikannya di React, saya akan senang untuk

Saya harap ini sepenuhnya diuji dengan modul react lain yang bergantung pada konteks, karena sejauh ini saya telah menemukan setidaknya satu perpustakaan yang mengganggu konteks dari perpustakaan lain - flocks.js. Penulis di sana sedang mengerjakannya, tapi harap pastikan bahwa material-ui tidak akan clobber react-router atau modul lain yang menggunakan konteks. Ide bagus, senang melihat gaya sebaris dan berharap itu akan membuat hidup kita lebih mudah untuk menggunakan materi ui: +1:

@ JedWatson Ya, menurut saya itu ide yang bagus. Kami pasti akan melakukannya.

@ hai-cea mengagumkan, senang mendengarnya: smile:

@anyong / @vjeux / anyone - apakah ada dokumentasi yang tersedia tentang bagaimana konteks berperilaku ketika ada banyak perpustakaan yang menggunakannya? yaitu bagaimana kita (sebagai penulis perpustakaan) memastikan bahwa kita bermain dengan baik? Saya belum melakukan banyak pengujian terhadap cara kerja mendefinisikan konteks pada tingkat yang berbeda.

@bparadie Saya ingin menambahkan mixin atau kelas seperti contoh @troutowicz untuk pemilih semu dalam waktu dekat, tetapi untuk saat ini Anda harus menggunakan acara seperti onMouseOver . Meskipun saya setuju itu bisa menyakitkan.

@JedWatson Ide bagus, saya akan segera membuat pembaruan.

@ukabu Saat ini tidak ada rencana untuk membaca file resets.css . Kami memutuskan untuk mengubah Material-UI dari kerangka css menjadi hanya satu set komponen React. Namun, resets.css dapat ditemukan online jika diperlukan.

@mmrtnz Saya mengerti, tetapi seperti sekarang, beberapa komponen tidak akan ditampilkan dengan benar dengan gaya agen pengguna. Contoh: jika saya tidak menyertakan css, h1 memiliki margin atas (gaya agen pengguna), yang mencegah judul AppBar disejajarkan dengan benar.

@ukabu Saya mengerti maksud Anda, terima kasih telah menunjukkan hal ini. Komponen yang gayanya bergantung pada resets.css dan file css dukungan terkait lainnya telah didefinisikan ulang secara inline. Ini tampaknya menjadi contoh yang saya lewatkan selama refactoring. Jika ditemukan lebih banyak masalah terkait dengan kebutuhan resets.css atau stylesheet lainnya, kami dapat menambahkannya kembali, tetapi tidak sebelum mencoba menyelesaikan masalah di tingkat komponen terlebih dahulu.

Untuk hover dll saya membuka # 684.

Terima kasih untuk semua orang untuk diskusi yang luar biasa ini. Kami dapat merilis fitur ini di v0.8.

Saya menantikan untuk menggunakan perpustakaan ini tetapi melihat semuanya menggunakan gaya sebaris adalah penolakan besar, saya tidak mengerti mengapa Anda melakukan ini, saya membaca slide tentang mengapa hal itu dilakukan tetapi tidak masuk akal, mengapa menggabungkan penampilan, tampilan dan logika menjadi satu hal, pemisahan perhatian orang, itulah salah satu pernyataan paling solid untuk rekayasa perangkat lunak.

Pablo, kekhawatiran ini tidak terpisah. Jika Anda ingin semuanya terlihat
berbeda Anda dapat menggunakan pengelola tema, pemisahan perhatian yang sebenarnya.
Selebihnya, komponen apa yang harus dilakukan dan html serta cssnya sangat dekat
digabungkan, dan memisahkan itu hanya membuat segalanya lebih kompleks.

On Sun, 23 Agustus 2015, 05:35 Pablo Fierro [email protected] menulis:

Saya tidak sabar untuk menggunakan perpustakaan ini tetapi melihat semuanya menggunakan
gaya inline adalah penolakan besar, saya tidak mengerti mengapa Anda melakukannya
ini, saya membaca slide tentang mengapa itu dilakukan tetapi tidak masuk akal, mengapa bergabung
penampilan, pandangan dan logika menjadi satu hal tunggal, pemisahan perhatian
orang, itu salah satu pernyataan paling solid untuk rekayasa perangkat lunak.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/callemall/material-ui/issues/30#issuecomment -133778140
.

Wout.
(diketik di ponsel, alasan singkatnya)

Saya setuju dengan @pablofierro - gaya inline tidak dapat di-cache oleh browser dan kami kehilangan fungsionalitas CSS yang cukup mendasar seperti :hover , penyeleksi saudara atau gagasan tentang gaya bertingkat.

Ini adalah kompromi untuk menggunakan gaya inline untuk mengaktifkan aplikasi hanya sisi klien statis dan menghindari ketergantungan pada toolchain pra-pemrosesan (webpack, dll), tetapi itu memungkinkan proyek yang lebih besar dengan kemampuan ekstra (aplikasi isomorfik paling menonjol). Saya ingin opsi menggunakan stylesheet eksternal atau penggunaan dukungan Modul CSS tetapi itu akan mengacaukan kasus yang lebih sederhana.

@grrowl cascades tetap dianggap praktik yang buruk dalam basis kode stylesheet besar. Lihat misalnya pendekatan BEM .

@Kagami dianggap praktik buruk oleh? Jika Anda memecah stylesheet menjadi modul yang dapat digunakan kembali (mirip dengan filosofi react), ini menjadi sangat mudah dipelihara. Bahkan halaman web React menyebutkan bahwa ini adalah Tampilan untuk komponen Anda dan bukan tampilan, keputusan untuk memaksa segala sesuatunya menjadi sebaris ini benar-benar konyol.

Ini perlu diubah. Menyebariskan tentu memiliki manfaatnya dalam beberapa kasus penggunaan, tetapi markup yang dihasilkan adalah:

• membengkak - satu ton bandwidth akan digunakan hanya untuk menurunkan gaya. Dalam setiap permintaan. 5x LEBIH BESAR untuk beberapa operasi aplikasi pabrik. Dan bagaimana jika Anda memiliki aplikasi dengan banyak, banyak simpul DOM? Dan bagaimana hal itu memengaruhi overhead dan kinerja memori? Ini membawa banyak implikasi yang seharusnya tidak kita tangani.
• jelek - bersenang-senang membaca apa yang dihasilkannya, ini sama menyenangkannya dengan membaca css yang dikecilkan mentah / tidak diformat.
• dan _stupid_ - kembali ke spesifikasi CSS 1 , WW3C menyertakan kelas karena suatu alasan. Gaya pendekatan ini memberikan fleksibilitas / pembuatan prototipe cepat / fungsionalitas yang diperoleh komunitas dengan membuat LESS / SCSS / etc. dll. keluar dari jendela. Anda sudah dapat melihat roda diciptakan kembali; gulir ke atas melalui utas ini dan lihat semua komentar yang menyarankan pustaka yang berbeda / apa pun untuk mengekstrak css dari javascript.

Tapi tunggu! Masih ada lagi:

• Tidak ada dukungan IDE di luar kotak
• Tidak ada dukungan psuedoclass

Guys: _ini adalah sesuatu yang bisa dilakukan jquery_. Mengapa kita harus mengeruk ini ke permukaan? apalagi memaksanya secara default?

kasus yang menyenangkan

Buka Alat Pengembang Chrome
Cobalah melakukan beberapa pengeditan gaya - ubah warna latar belakang atau sesuatu - ke halaman yang memiliki beberapa komponen mui dengan jenis yang sama, _mis. <MenuItem ...> dalam menu navigasi._

itu hanya mengubah komponen _that_. Bagaimana dengan React Devtools? tidak sama.

Saya tidak bermaksud menjadi brengsek - meskipun saya pasti terdengar seperti itu, tetapi seperti yang dikatakan @pablofierro , ini konyol. Fungsionalitas ini mungkin keren, kurangnya dependensi css sangat menarik. Tapi merobek .css tidak masuk akal.

Saya harus menambahkan; Saya akan sangat senang untuk membuat PR. Saya hanya ingin mendengar apa yang dikatakan komunitas tentang penerapan ulang ini; mudah-mudahan sampai pada semacam konsensus tentang bagaimana melakukan hal ini.

Apa yang Anda sarankan untuk dilakukan? Untuk kasus penggunaan saya (aplikasi Cordova) pendekatan inline sangat bagus.

@oliviertassinari sepertinya keuntungan terbesar dari gaya sebaris adalah bahwa proyek tidak perlu memiliki lembar gaya eksternal sebagai ketergantungan.

Jika ini masalahnya, saya akan merekomendasikan kembali ke kelas (karena tampaknya banyak yang menginginkannya dan tampaknya membuat segalanya lebih sederhana) dan alih-alih mengekspos semua CSS melalui string.

/*styles.css for people who are fine with a separate file*/
.my-styles {...}

// styles.js (expose as "material-ui/theme" or something)

var css = { __html: "injected styles.css content" };

// alternatively we could expose a component.
module.exports = (
    <style dangerouslySetInnerHTMLIfYouAreSureItIsWhatYouWantToDo={ css }/>
);

Dengan cara ini orang dapat menggunakan tema secara langsung dengan JavaScript dengan:

theme = require("material-ui/theme");

MyJSX = (
    <div>{ theme }</div>
);

Kelebihan:

• itu hanya css
• berpotensi banyak tema tanpa semuanya dibundel
• dapat diimpor melalui js, css pre processor atau manual di html.

Kekurangan:

• banyak waktu dihabiskan untuk membuat semua gaya sebaris.

@rozzzly +1111111000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Dengan MUI -> http://recordit.co/9mBknPLZUb
Tanpa MUI -> http://recordit.co/6MkzWhQiBt

Nah @rozzly saya tidak setuju.

• kembung . Tentu, kami menggunakan lebih banyak bandwidth untuk mengirim gaya saat pengguna tiba di situs.
  Tetapi latensi dan bukan bandwidth, adalah penghambat kinerja untuk sebagian besar situs web. untuk lebih detail .
  Jadi, menurut saya pengiriman gaya sebaris ke bawah pada waktu render pertama. Dan inilah yang paling penting bagi pengguna. Anda tidak perlu menunggu RTT (waktu pulang-pergi) untuk memiliki gayanya.
• jelek . Ya, itu tidak mudah dibaca. Mengapa Anda perlu membacanya?
• dan bodoh . Facebook menjelaskan motivasi mereka menggunakan gaya sebaris. Cukup meyakinkan. Tautan

Saya telah menggunakan gaya sebaris secara eksklusif selama lebih dari 6 bulan dan ini merupakan pengalaman yang membebaskan. Gaya menjadi lebih mudah diatur, fleksibel dan dengan kejutan yang jauh lebih sedikit dibandingkan dengan CSS.

Saya pribadi setuju dengan @rozzzly yang merinci masalah dengan baik. Ini bukan ide yang bagus dalam skala besar. CSS bekerja. Kami menciptakan kembali roda agar lebih "portabel". Perubahan gila ini bermuara pada memperbaiki satu masalah - termasuk css. Ini akan membutuhkan 1 baris penjelasan di readme. Belum lagi, bahkan pengembang pemula pun berpengalaman dalam memasukkan CSS dalam HTML atau dengan alat pembuatannya. Ini bukan orang baru.

Sebagai gantinya kami membangun kembali gaya untuk halaman web di JS. Sepertinya konyol. Fitur gaya yang benar-benar dasar seperti elemen semu? Hilang. Kompilasi SASS / LESS? Hilang.

Hai semuanya. Saya mulai menggunakan material-ui dalam proyek sampingan dan telah mengikuti diskusi di sini dan di sini .

Saya ingin menambahkan beberapa poin ke dalam campuran:

Apakah ini masuk akal untuk aplikasi yang lebih kecil?
Saya telah menulis banyak aplikasi web internal yang lebih kecil untuk bisnis yang menggunakan bootstrap dan sejenisnya. Saya tidak pernah merasa sangat sakit ketika harus memasukkan lebih banyak komponen-css di samping markup dan js-nya. _Ini adalah upaya satu kali_. Konflik sangat jarang menjadi masalah dan sering kali mudah diselesaikan.

Tapi saya benar-benar merasa kesakitan melihat DOM di alat pengembang saya sekarang. Bahkan melihat struktur pohon dasar jauh lebih sulit dengan semua gaya sebaris. Dan rasa sakit ini bukan hanya satu kali - datang kembali setiap kali saya membuka alat pengembang.

Apakah kita mengasingkan desainer yang paham CSS di sini dengan pendekatan ini?
Dengan semua gaya yang disematkan dalam JavaScript, tampaknya sulit bagi desainer yang terbiasa membuat draf dan mengedit bekerja di file CSS. Bukankah mereka sekarang dipaksa untuk mempelajari JavaScript, ES6, transpiler, buildtools dll dan jauh lebih mungkin untuk merusak barang?

Mungkin itu bukan hal yang buruk - saya semua untuk tim lintas fungsi dan saya belum pernah bekerja dengan "desainer komponen", tapi saya ingin memastikan desainer dipertimbangkan dalam diskusi ini juga.

Juga:

1 untuk pemisahan masalah - gaya dan logika ui harus dipisahkan dalam buku saya
1 untuk mempertimbangkan kurangnya Dukungan IDE

Saya sangat setuju bahwa ada masalah dengan CSS terutama dalam skala besar. Saya harap diskusi ini mengarah ke tempat yang lebih baik bagi kita semua dalam hal ini.

Yah, saya juga menemukan pembicaraan itu meyakinkan tetapi dalam praktiknya kebanyakan menggunakan css with
penggantian nama berbasis modul dan mungkin beberapa gaya sebaris adalah yang paling mudah
bekerja dengan imho.

Pada Sel, 24 Nov 2015, 09.49 Owen Campbell-Moore [email protected]
menulis:

Untuk apa nilainya, penggunaan gaya sebaris adalah alasan besar saya menjadi a
penggemar berat MUI. Saya menemukan pembicaraan oleh Facebook sangat meyakinkan dan
secara pribadi merasa bahwa gaya dan struktur tidak masuk akal untuk dipisahkan
saat membuat UI.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/callemall/material-ui/issues/30#issuecomment -159198060
.

Wout.
(diketik di ponsel, alasan singkatnya)

Poin menarik @mpseidel. Namun saya berpikir karena semakin banyak kerangka kerja bergerak menuju komponen, menurut saya menjaga JS dan CSS bersama sebagai bagian dari komponen lebih masuk akal daripada memiliki css yang lebih global yang mencakup berbagai komponen, halaman, dll. Namun, konsep komponen bertema membuat saya bingung .. Saya tidak tahu banyak tentang CSS, jadi mungkin ada cara mudah bagi komponen untuk mengambil gaya bertema untuk menimpa gaya defaultnya sehingga penulis komponen dapat menyesuaikan komponennya dengan gaya tema keseluruhan? Jika ada, saya ingin lebih memahaminya.

Ada diskusi besar di sini. Dan sulit untuk menebak arah secara keseluruhan.
Adakah yang bisa memperkirakan kemungkinan gaya akan dikembalikan ke tempatnya?

Saya belum menggunakan material-ui. Dan dari sudut pandang "segar" saya, saya melihat masalah ini yang membuat saya waspada dalam menggunakan proyek ini di masa mendatang:

• presentasi dan lapisan logika kacau
• penurunan kinerja karena gaya sebaris
• sulit untuk menambahkan gaya sendiri
• DOM tidak terbaca jelek

Saya tidak melihat manfaat apa pun dari gaya sebaris.

Akan lebih baik untuk mengatur ulang lebih sedikit / sass / css dengan cara yang lebih mudah dibaca dan dipelihara daripada mencoba untuk mengubah gaya dari awal.

Diskusi ini cukup banyak selesai.
Ikuti https://github.com/callemall/material-ui/issues/684.

@oliviertassinari .. artinya tidak ada jalan kembali ke CSS?

Ini berarti bahwa kami sedang menjajaki opsi untuk meningkatkan pendekatan gaya saat ini (Modul CSS, Radium, Tampilan, react-themeable).