Material-ui: [RFC] Bermigrasi ke komponen bergaya

@kybarg Terima kasih telah membuka masalah itu! CSS-in-JSS adalah bidang yang bergerak, pilihan yang kami buat di masa lalu mungkin tidak lagi valid karena masalah dan solusi berubah.

Mengapa tidak gaya-komponen di masa lalu?

Kami telah membandingkan berbagai solusi penataan yang tersedia sebelum memilih JSS.

Kami tidak memilih komponen gaya karena alasan berikut:

• Biaya abstraksi. css-in-js-perf-tests adalah sumber yang bagus, komponen gaya menggunakan glamor secara internal.
  
  
  
  • 126 kb membuka ritsleting lebih dari 22 kb untuk JSS
  
  
  • Waktu untuk melukis pertama lebih lambat. Bandingkan waktu untuk pertama kali melukis pada demo setara https://github.com/MicheleBertoli/css-in-js , JSS berkinerja 40% lebih baik.
  
  
• Mengekspos className dan kekuatan pemilih dalam CSS memungkinkan implementasi yang berkinerja. Misalnya dengan <Grid /> : #6010.
• Tidak ada konkurensi rendering sisi server yang memungkinkan. Ini mengandalkan singleton untuk mengumpulkan gaya sementara JSS membuat instance baru untuk mengumpulkan gaya pada setiap permintaan. Mengukus benar-benar terbatas.

Sebenarnya, komponen bergaya bahkan bukan apa-apa (ada) ketika @nathanmarks mulai bekerja untuk menjauh dari gaya sebaris.

tabel perbandingan

Mendukung CSS global

Dengan https://github.com/cssinjs/jss-global Anda dapat menulis hal-hal seperti

const styles = {
  '<strong i="35">@global</strong> body': {
    color: 'green'
  }
}

Mudah ditimpa

Bagaimana ini tidak mudah? Sisi Material-UI kami memiliki tabel pesanan injeksi yang telah ditentukan. Di wilayah pengguna, mereka dapat menggunakan afrodisiak yang mengimplementasikan API override aphrodite yang hebat.

Tidak ada komponen pembungkus

Kami tidak memiliki komponen pembungkus di sisi Material-UI. Kami bisa saja menggunakan withStyles tetapi kami tidak melakukannya karena alasan kinerja. Kami memaparkan Komponen Tingkat Tinggi itu kepada pengguna untuk mengabstraksi implementasi konteks.

Bertema

Kami menggunakan jss-theme-reaktor secara internal. JSS mengekspos API tingkat rendah yang memungkinkan.

Dukungan ReactNative

Itu poin yang bagus, API reaksi-dengan-gaya cukup menarik. Itu sesuatu yang bisa kami tingkatkan!

Masa depan

Ke depan, saya pikir jalur yang paling menjanjikan adalah memiliki API yang memungkinkan untuk mengganti implementasi gaya. Itu akan memberi kita dua manfaat:

• Material-UI kurang digabungkan dengan solusi penataan gaya apa pun
• Pengguna yang menggunakan komponen gaya / aphrodite/... di pihak mereka dapat menghemat overhead JSS yang digunakan secara internal.

react-toolbox mengikuti jalur itu. Satu-satunya kekhawatiran saya adalah dengan biaya tambahan yang ditambahkan. Maksudku, apakah itu layak?

Saya menambahkan @kof dan @mxstbr ke loop.

@kybarg Sebenarnya, saya tidak yakin untuk sepenuhnya memahami apa yang Anda sarankan.
Kami tidak menggunakan react-jss seperti yang disarankan pertanyaan Anda.

Ketika Anda mengatakan kami, apakah Anda berbicara tentang pengguna atau Material-UI?

Poin saya adalah:

• styled-components adalah pustaka tingkat yang jauh lebih tinggi daripada inti JSS, Anda pasti dapat menggunakannya di lapisan aplikasi Anda.
• Tabel perbandingan di atas adalah tentang react-jss, bukan inti JSS dan merupakan pendapat subjektif dari Max. Ini sebagian tidak benar dan sebagian hanya melihat dari beberapa perspektif tertentu yang tidak kita lihat dari tabel.
• Kami sedang mengerjakan rendering aturan dinamis untuk penataan dinamis yang lebih efisien, jss-theme-reactor sudah melakukan tugasnya sekarang, ini hanya masalah pengoptimalan, yang mungkin tidak terlalu relevan untuk MUI.
• Apa yang digunakan MUI secara internal harus benar-benar di luar perhatian pengguna akhir. Semua yang perlu dilakukan pengguna harus dimungkinkan tanpa mengetahui apa yang digunakan MUI secara internal atau setidaknya sintaks cssinjs yang kurang lebih biasa untuk tema.
• Kita perlu mendapatkan kasus penggunaan yang tidak didukung MUI sekarang dan menyelesaikannya. Saya selalu senang membantu proses integrasi dan tersedia di gitter.
• Apa itu dukungan asli-reaksi? Bukankah itu hanya bagian dari platform web? Jika demikian seharusnya berfungsi, jika tidak, beri tahu saya apa yang perlu dilakukan JSS untuk mendukung reaksi asli, inilah masalahnya .

Tabel tersebut memang sangat subjektif dan berdasarkan pengalaman saya sendiri. FWIW, styled-components berfungsi dengan pustaka komponen pihak ketiga mana pun:

import { Button } from 'material-ui'

const MyButton = styled(Button)`
  // Only these styles will be overridden
  background: red;
`

Ini berfungsi selama komponen melampirkan prop className secara internal ke beberapa simpul DOM:

const MaterialUIButton = (props) => {
  /* ... */
  // As long as props.className is attached, the above usage will work
  return <button className={`bla ${props.className}`} />
}

Apa itu dukungan asli-reaksi? Bukankah itu hanya bagian dari platform web?

Tidak, tidak semudah itu Menambahkan dukungan ke JSS seharusnya tidak sulit, karena yang harus Anda lakukan hanyalah meneruskan objek gaya ke StyleSheet.create() . Ini membutuhkan sedikit lebih banyak usaha dari sisi styled-components untuk membuat string CSS berfungsi.

Saya sudah berbicara dengan @javivelasco untuk sementara waktu sekarang dan suka ke mana dia pergi dengan react-toolbox . Implementasinya luar biasa, dan saya ingin melihat semua perpustakaan komponen pihak ketiga mengadopsinya. Ping dia sehingga dia bisa berpadu dengan ide-idenya di sini!

Tidak ada konkurensi rendering sisi server yang memungkinkan. Ini mengandalkan singleton untuk mengumpulkan gaya sementara JSS membuat instance baru untuk mengumpulkan gaya pada setiap permintaan. Mengukus benar-benar terbatas.

Sama sekali tidak terkait, keberatan berkomentar dalam masalah ini dengan ide Anda untuk API yang memungkinkan hal ini terjadi? Kami belum memutuskan apa yang akan kami lakukan, jadi masukan Anda akan sangat kami hargai.

Hai, saya bertanya tentang ini di gitter. Hanya untuk mendapatkan pandangan orang lain, saya akan mempostingnya di sini juga:

Saya tahu material-ui _next_ banyak diinvestasikan dalam solusi jss khusus.
Adakah yang menemukan keuntungan serius menggunakan jss daripada komponen gaya?

Sementara jss bagus karena memungkinkan beberapa pola seperti dekorator (injectstyles) dan plugin, saya pikir pendekatan langsung komponen gaya jauh lebih bersih karena tidak perlu dekorator, pengaturan khusus, dan plugin karena tidak perlu.

Di styled-comp setiap komponen sudah ditata jadi tidak perlu meneruskan gaya. dan Anda melewati alat peraga yang dapat dievaluasi untuk menghasilkan gaya yang berbeda
tidak ada pengaturan (createJss)
tidak ada plugin (awalan)
tidak ada JSON DSL

Seseorang harus mengunci utas ini.

@rainice jss tidak memiliki dekorator, HOC adalah detail implementasi dari react-jss dan tidak digunakan di sini.

Mengapa ini harus dikunci? Ini diskusi yang waras IMO

Karena konten berbasis pengguna akhir di sini (bukan pengelola lib) sangat dangkal dan ini dapat dimengerti karena mereka tidak membaca satu baris kode pun di belakang apa yang mereka gunakan.

Karena pilihan solusi penataan telah dibahas panjang lebar , rasional di balik keputusan yang didokumentasikan , dan pekerjaan pengembangan menuju rilis besar berikutnya sedang berlangsung , ini bukan masalah yang berguna, jadi saya akan menutupnya.

Semoga orang-orang cukup dewasa untuk tidak melanjutkan posting ke utas yang ditutup, tetapi kami dapat menguncinya jika diperlukan.

Saya berharap kami dapat memajukan utas itu dengan solusi penataan yang kurang berpasangan!
Namun, saya pikir prioritas kami, untuk saat ini, adalah menyelesaikan migrasi/peningkatan komponen secara keseluruhan.

@mxstbr terima kasih untuk komponen gaya

Ini berfungsi selama komponen melampirkan prop className secara internal ke beberapa simpul DOM

ini mungkin layak disorot di suatu tempat di panduan penggunaan Anda saat mui:next dirilis. Komentar ini baru saja menyelamatkan saya.

Gaya fleksibel untuk IE10 tidak berfungsi dengan jss tetapi bekerja dengan komponen gaya seperti pesona

@yhaiovyi Material-UI tidak mendukung IE10.

Awalan vendor evtl. Akan segera diperbaiki untuk jss, tidak berarti meskipun itu akan memperbaiki semua masalah jika mui tidak pernah diuji pada IE10

Pokoknya saya belum menemukan masalah lain selain css flex dengan IE10 sejauh ini

Sepertinya kami memiliki 3 cara (bisa lebih mudah, tetapi tidak semuanya adalah bunga) untuk mengganti gaya UI Material dengan Komponen Bergaya. Inilah Intisari saya.

Anda juga bisa mendapatkan API komponen bergaya seperti dengan beberapa baris kode: https://material-ui-next.com/customization/css-in-js/#styled -components-api-15-lines-

Anda juga dapat menggunakan styled-jss , contoh: https://codesandbox.io/s/32mvjyjyxq

satu-satunya downside dengan JSS secara umum adalah kurangnya pelengkapan otomatis dalam editor kode, seperti yang dikatakan di sini juga , tetapi manfaatnya ada di sana, penguraian css ke js seperti pada komponen gaya agak berlebihan

edit: baru perhatikan masalah yang dirujuk tepat di atas, menarik

Yang mengganggu adalah konteks Mui dan withStyles HOC tampaknya tidak cocok dengan inti react-jss dan styled-jss ThemeProvider https://codesandbox.io/s/32mvjyjyxq (Saya mencoba meletakkan Typography tapi itu tidak berhasil, edit: nvm, masih mengutak-atiknya)

Saya ingin tahu apakah nanti (posting v1 saya kira) tidak ada gunanya menyederhanakan lapisan ganda src/styles/withStyles dan MuiThemeProvider + JSSProvider, dan memiliki sesuatu yang sedikit lebih sederhana seperti bagaimana react-jss dan styled-jss miliki

Benar-benar untuk itu!

Pada 13 Maret 2018 13:55, "Cyril Auburtin" [email protected] menulis:

Yang mengganggu adalah konteks Mui dan withStyles HOC sepertinya tidak bermain
baik dengan inti react-jss dan styled-jss ThemeProvider
https://codesandbox.io/s/32mvjyjyxq

Saya ingin tahu apakah nanti (posting v1 saya kira) tidak layak untuk disederhanakan
src/styles/withStyles dan MuiThemeProvider + JSSProvider lapisan ganda

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/mui-org/material-ui/issues/6115#issuecomment-372655385 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AADOWAbwLOnRoypx9ANCZnKyalZyD0M9ks5td8HNgaJpZM4L-GwD
.

penguraian css ke js seperti pada komponen gaya agak berlebihan

Sama seperti mem-parsing objek ke CSS adalah :wink: Parsing string memiliki kecepatan yang sama, sejujurnya tidak masalah. https://github.com/A-gambit/CSS-IN-JS-Benchmarks/blob/master/RESULT.md

Solusi | Gunakan CSS | Gunakan Inline-Styles | Waktu Pemasangan (md) | Waktu render ulang (md)
:--- | :--- | :--- | :--- | :---
...
gaya-komponen | + | - | 182 | 146,84
gaya-komponen-decouple-sel | + | - | 213.53 | 152,39
...
reaksi-jss | + | - | 198,97 | 297,74

@mxstbr parser css lengkap yang ditulis dalam js saat runtime pasti ada harganya. Tolok ukur itu tidak mengukur biayanya.

parser css lengkap yang ditulis dalam js saat runtime pasti memiliki harga.

Tentu, tetapi tidak lebih dari parser CSS lengkap yang menangani objek daripada string. Selain itu parser CSS yang beroperasi pada string CSS yang sebenarnya telah dioptimalkan dan dieksplorasi untuk waktu yang lama, apalagi dengan yang menangani objek. :merah:

Saya ingin tahu tentang membandingkan bootstrap CSS sebagai objek dengan parser Anda vs bootstrap CSS dengan stylis, parser kami, tapi saya cukup yakin perbedaannya akan sangat kecil.

Saya ingin tahu tentang membandingkan bootstrap CSS sebagai objek dengan parser Anda vs bootstrap CSS dengan stylis, parser kami, tapi saya cukup yakin perbedaannya akan sangat kecil.

Ya itu akan menjadi patokan yang tepat, saya telah menguji sedikit, bekerja dengan objek jauh lebih cepat, seperti 10-20x lebih cepat.

Tetapi sekali lagi, itu tergantung pada plugin jss mana yang akan Anda sertakan, kami memiliki banyak plugin gula sintaksis.

Juga tbh. tidak masalah jika kita semua pindah ke ISTF.

Saya telah menguji sedikit, bekerja dengan objek jauh lebih cepat, seperti 10-20x lebih cepat.

Tentu tapi 10 ms (itulah berapa lama stylis yang dibutuhkan untuk mengurai seluruh stylesheet bootstrap) vs 1 ms dari parsing seluruh CSS aplikasi tidak akan menjadi masalah dalam skema besar, Anda tahu? Itu tidak akan membuat atau merusak aplikasi siapa pun.

Bagaimanapun, mari kita berhenti mengganggu orang dalam masalah ini dengan lebih banyak notifikasi daripada yang diperlukan.

Omong-omong. tolok ukur ini tampaknya lebih akurat: http://necolas.github.io/react-native-web/benchmarks/ Saya tidak yakin meskipun tidak bergantung pada cache setelah penguraian pertama.

@mxstbr Sementara masalah ini sekarang terkunci, sedikit persaingan yang sehat baik untuk semua orang. Kembalilah kapan saja - Anda dapat menemukan kami di obrolan gitter jika suatu masalah bukanlah tempat yang tepat untuk diskusi.

Masalah ini sudah lebih dari satu tahun. Teman-teman, tolong berhenti mengomentarinya. Kita bisa memindahkan diskusi ke yang baru. Banyak yang telah berubah sejak diskusi dimulai.

Tapi mari kita coba untuk menghindari masalah penguncian. Kita perlu terus mengumpulkan umpan balik sebanyak mungkin untuk membuat keputusan yang lebih baik.

Saya pikir mengunci masalah sebagai alat untuk mengomunikasikan dengan jelas ini baik-baik saja, tidak ada yang tersinggung dengan ini atau kebebasan berbicara diambil. Dalam hal ini benar-benar baik-baik saja.

Saya membuka kembali untuk mengumpulkan lebih banyak umpan balik, saya ingin tahu apakah ini sesuatu yang masih diminati orang:

Kami memiliki survei pengembang yang sedang berjalan, kami akan menggunakan hasilnya untuk memperbarui ROADMAP kami.
Kami memiliki persyaratan berikut dengan solusi gaya:

1. Ukuran bundel . Kami ingin orang dapat menggunakan satu komponen tanpa harus membayar 20 KB gzip untuk itu. Berdasarkan peringkat:
   
   
   
   1. emosi adalah kandidat terbaik dalam arah ini: 10kB gzip . Namun, itu digunakan oleh beberapa orang. Jika Anda melihat statistik unduhan, 80% berasal dari buku cerita ?
   
   
   2. berat komponen gaya sekitar 16 KB gzip . Keuntungannya berasal dari jumlah orang yang menggunakannya. Mungkin 20% dari pengguna Bereaksi?
   
   
   3. JSS dengan bobot pembungkus reaksi sekitar 15 KB di-gzip. Jika Anda melihat statistik unduhan, banyak penggunaan berasal dari Material-UI.
   
   
2. Kinerja . Kami ingin orang lain dapat menyesuaikan komponen kami. Mereka harus secepat mungkin. Patokan yang bisa saya lakukan menghasilkan peringkat berikut:
   
   
   
   1. emosi
   
   
   2. jss
   
   
   3. gaya-komponen
   
   
3. API Kustomisasi . Menyesuaikan varian harus mudah, menyesuaikan elemen bersarang harus mudah, menambahkan varian baru harus mudah. Saat ini, kami memiliki classes API, theme.overrides API, dan kemampuan untuk memiliki nama kelas deterministik global.
4. Interoperabilitas . Menggunakan !important bukanlah solusi.
5. dukungan RTL

Saya hanya menyebutkan komponen gaya, emosi, dan JSS tetapi mereka adalah alternatif yang berbeda: linaria, SASS, dll.

Saya percaya mungkin perlu menambahkan dua masalah berikut karena dapat membantu memengaruhi keputusan ketika Anda punya waktu untuk mengerjakan pustaka CSS-in-JS yang digunakan oleh Material-UI:

• https://github.com/mui-org/material-ui/issues/15660
• https://github.com/cssinjs/jss/issues/1102
  Singkatnya, kedua masalah ini mencakup inkonsistensi JSS yang memengaruhi pengalaman pengembang.

@o-alexandrov Apakah JSS mengikuti strategi yang sama dari komponen gaya? Saya tidak mengerti maksud Anda. Bisakah Anda mengklarifikasi? Apa bedanya? Bagaimana itu lebih baik atau layak?

@olivietassinari
Dalam pesan sebelumnya, saya tidak mengatakan apa-apa tentang styled-components , kecuali bahwa saya menyambut baik ide untuk mengevaluasi penggunaan styled-components atau pustaka CSS-in-JS lainnya yang akan memiliki keseimbangan sempurna:

• pengalaman dev (keakraban dan fleksibilitas, kontribusi lebih lanjut, penggunaan aktual oleh devs, dll.)
• pertunjukan

Tautan ke dua masalah di atas hanya membahas aspek negatif saat ini dari bekerja dengan JSS.
Saya lupa di mana saya melihat yang berikut, tetapi saya ingat Anda membuat poin bagus bahwa untuk dapat membuat keputusan, pertama-tama kita harus menambahkan semua jenis tolok ukur sehingga keputusan dapat dievaluasi lebih mudah.

Secara pribadi, saya suka:

• komponen gaya di atas jss untuk adopsi komunitas yang lebih luas.
  Saya percaya adopsi oleh komunitas adalah aspek kunci yang harus dipertimbangkan oleh Material UI.

@o-alexandrov Oke, dalam hal ini, saya menandai komentar pertama Anda sebagai di luar topik. Di v5, kami ingin mengisolasi komponen inti dari solusi penataan gaya. Saya berharap kami dapat menyediakan versi komponen telanjang, JSS, emosi, linaria dan gaya-komponen (sebagai default). Itulah visinya. Sekarang implementasinya akan menantang!

Ukuran bundel

styled-components telah terbukti meningkatkan 12.3kB di @5.0.0-beta.8

API Kustomisasi

Jika mereka memperkenalkan https://github.com/styled-components/styled-components/pull/2625 baik dalam paket atau paket eksternal, saya percaya paritas API ke Mui karena tidak ada API komponen non-gaya yang kadang-kadang kita perlukan , terutama dalam sistem lawas tetapi saya tidak berpikir Anda akan membutuhkan API itu di Mui sendiri sesering itu.

Di luar itu,

Saya tidak yakin info apa yang ingin Anda kumpulkan karena dari pengalaman pribadi saya styled-components menawarkan fitur yang kami butuhkan.

Interoperabilitas.

Apa ini untuk Anda dalam konteks ini? Anda dapat mengesampingkan hal-hal di styled-components seperti kerangka kerja lain sejauh yang saya tahu.

dukungan RTL

Bukankah ini didasarkan pada bagaimana kita mengkodekan komponen? Apa sebenarnya yang ditawarkan styled-components atau pustaka CSS-in-JS apa pun untuk ini?

Pikiran saya

Kecepatan

Dulu lebih lambat dibandingkan dengan solusi lain tetapi dukungan dan upaya luar biasa dari kontributor berhasil mencapai titik di mana menjadi lebih cepat daripada JSS.

Ukuran

v5 menjadi lebih ramping seperti yang saya katakan 12.3kB dari 16.2kB yang mewakili upaya mereka dalam topik ini.

Keakraban

Orang-orang akrab dengan API karena ini adalah yang paling populer, pada kenyataannya, kebanyakan orang memanggil styled-components merujuk ke API daripada paket sebenarnya ketika kami menggunakan styled(...) ... API, untuk sebagian besar.

Bereaksi Asli

Itu sangat berat bagi Mui adalah web, tetapi orang akan terus mengadopsi styled-components karena itu.

Tim inti

Tim Inti yang Kuat, pada hari ini 81 edisi dan 14 PR terbuka, ini adalah angka yang bagus untuk jumlah orang yang menggunakan paket.

Juga, orang-orang seperti @mxstbr benar-benar menggunakan paket di spectrum sehingga dia memiliki pengalaman dunia nyata menggunakan paket, itu luar biasa, itu berarti dia benar-benar tahu bagaimana rasanya menggunakan paket.

Mengambilnya

Yah, tidak bisa lebih baik https://www.styled-components.com/docs/tooling

Untuk penulis UI

Mulai hari ini, adopsi styled-components untuk komponen Sistem Desain telah meningkat pesat; Atlassian, GitHub, Orbit dan banyak lainnya.

Ini bagus untuk Mui karena Anda tidak akan sendirian jadi mungkin orang sudah menghadapi situasi potensial yang mungkin Anda hadapi dan mereka menemukan cara untuk menghadapinya.

TL;DR

Saya mendukung styled-components .

Saya suka JSS karena sintaks objek untuk CSS menjadi lebih mudah bagi saya, terkadang saya malas dan saya bahkan hanya melewatkan gaya itu sebagai style={{styles.dialogTitle}} gaya sebaris, mudah untuk refactor nanti

Dan itu dapat digunakan dengan cara yang berbeda, dengan pembungkus elemen seperti komponen-gaya https://material-ui.com/styles/basics/#styled -components-api

@caub https://www.styled-components.com/docs/advanced#style -objects

Saya sangat menyukai komponen gaya, tetapi baru-baru ini saya menemukan bahwa hal itu menimbulkan sejumlah masalah yang menyulitkan untuk membuat pengocokan pohon bekerja secara konsisten. Saya tahu tim material-ui baru saja melakukan banyak pekerjaan untuk membuat tree-shaking bekerja sepenuhnya untuk perpustakaan ini, dan jelas regresi apa pun yang harus dihindari.

Untungnya sebagian besar masalah pohon-goyang diselesaikan dengan menggunakan babel-plugin-styled-components dan pengaturan pure: true (lihat https://www.styled-components.com/docs/tooling#dead-code-elimination ). Tapi masih ada beberapa masalah yang tersisa. Sebagai contoh:
https://github.com/styled-components/babel-plugin-styled-components/issues/245

Lain adalah bahwa menggunakan fungsi pembantu eksternal di dalam gaya Anda dapat merusak goyangan pohon (kecuali jika Anda mengonfigurasi terser/uglify untuk mengabaikan fungsi spesifik itu), misalnya:

const Button = styled.button`
  font-size: ${externalHelperFunction()};
`

Saya pikir itu mungkin untuk memperbaiki semua masalah ini agar pengocokan pohon berfungsi dengan benar, tetapi itu pasti bisa rumit dan tidak hanya bekerja dengan cara yang ideal di luar kotak seperti yang ada saat ini. Saya sebenarnya masih berpikir bahwa beralih ke komponen gaya mungkin merupakan ide yang bagus, tetapi hanya jika masalah ini dapat diselesaikan.

@mrowne Saya tidak dapat mereproduksi masalah apa pun dengan goyangan pohon dan komponen gaya. Masalahnya tidak termasuk contoh yang dapat direproduksi, jadi saya mencoba menirunya dengan

// components.js
import React from "react";
import styled from "styled-components/macro";

const Wrapper = styled.div`
  color: blue;
`;

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

MyComponent.displayName = "FancyName";

export function OtherComponent() {
  return "only";
}

// App.js
import React from 'react';
import { OtherComponent } from "./components";

/* code */

dengan default create-react-app . MyComponent tidak akan muncul di bundel produksi.

Apakah ini hanya masalah rollup ? Saya akan menghargai contoh yang dapat direproduksi untuk memahami masalah ini.

@ eps1lon Saya pikir masalah muncul ketika mengatur properti statis pada komponen gaya, dapatkah Anda mencobanya?

const Wrapper = styled.div`
  color: blue;
`;

Wrapper.displayName = "FancyName";

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

@mxstbr Ya meskipun dalam kedua kasus komponen gaya dibundel. Saat menyetel displayName pada MyComponent tidak menyertakan MyComponent dalam bundel, ia masih menyertakan styled-components . Ini pada dasarnya menghapus apa pun yang dilakukan pada MyComponent itulah sebabnya saya awalnya menganggapnya sebagai goyangan pohon (baru saja mencari FancyName .

Tapi itu masih termasuk styled-components . Bahkan jika Anda menganggap panggilan styled memiliki efek samping, saya akan mempertimbangkan

import React from "react";
import styled from "styled-components";

export function Wrapper() {
  // nonsense
  return styled.div``;
}

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

sebagai bebas efek samping saat mengimpor { OtherComponent } tetapi komponen gaya akan tetap muncul dalam bundel (ini bahkan tanpa makro). Jadi ini adalah beberapa bug atau saya kehilangan sesuatu yang besar. Bahkan

// Wrapper.js
import React from "react";
import styled from "styled-components";

export default function Wrapper() {
  // side-effect free module even if styled has side-effects
  const Component = styled.div``;
  return <Component />;
}

// components.js
// commenting this out removes styled-components from the bundle
export { default as Wrapper } from "./Wrapper";

export function OtherComponent() {
  return "only";
}

// index.js
import React from 'react';
import ReactDOM from 'react-dom';
import { OtherComponent } from "./components";
import * as serviceWorker from './serviceWorker';

ReactDOM.render(<OtherComponent />, document.getElementById('root'));

// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();

akan menyertakan styled-components (https://github.com/eps1lon/styled-components-shake).

Mungkin bug dalam skrip reaksi, paket web, atau komponen gaya. Bagaimanapun men-debug masalah ini sangat sulit tanpa repro.

Masuk akal, terima kasih telah menyelidiki itu.

Untuk kasus penggunaan ini, saya rasa tidak masalah apakah styled-components disertakan dalam bundel (karena semua komponen harus menggunakannya), melainkan apakah komponen yang tidak Anda gunakan disertakan—yang tidak terdengar seperti itu, jadi itu bagus, kan?

@mxstbr Ini bisa menjadi perhatian penting, kami memiliki beberapa komponen yang tidak bergaya, dan generik (Modal, Popper, TextareaAutosize, useMediaQueries, dll.), katakanlah seseorang menggunakan

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

dengan SASS. Kami mengharapkan peningkatan gzip +5kB (mulai hari ini), bukan +20kB gzip.

Namun, dengan asumsi kita mendorong @material-ui/unstyled ke depan, dalam praktiknya, mungkin tidak ada bedanya karena orang dapat menggunakan paket ini.

@eps1lon Maaf, saya pikir masalah dengan properti statis akan lebih mudah bagi orang lain untuk mereproduksi karena tampaknya mempengaruhi semua komponen kami...ternyata ada banyak hal berbeda yang memicu masalah, tapi setidaknya di beberapa kasus sederhana berhasil.

Saya membuat demo yang dapat direproduksi di sini:
https://github.com/mrowne/CRA-error-template/tree/styled-components-tree-shaking
git clone --single-branch --branch styled-components-tree-shaking [email protected]:mbrowne/CRA-error-template.git

Perhatikan bagaimana hanya Component1 tree-shake yang benar.

Kabar baiknya adalah saya pikir semua masalah ini dapat dipecahkan, dan @mxstbr tampaknya sangat terlibat di sini. Saya akan segera mengerjakan PR yang akan mengatasi setidaknya masalah alat peraga statis (saya sudah memiliki POC yang berfungsi menggunakan plugin Babel terpisah yang saya tulis).

Saya membuka PR ke komponen-komponen bergaya plugin babel untuk mengatasi masalah guncangan pohon. Jika ada orang di sini yang ingin membantu mengujinya, saya membayangkan @mxstbr akan menyambutnya (dan tentu saja saya juga):
https://github.com/styled-components/babel-plugin-styled-components/pull/248

Hai semua, di mana tiket ini saat ini? Saya akan sangat senang untuk terlibat dan menulis beberapa komponen gaya untuk MUI jika memang itu tujuan proyek di v5

Saya kira kecuali kita ingin melakukan ini sekaligus (saya ragu kita menginginkannya). Kita harus mulai dengan membuat komponen bergaya membaca tema dari jss atau jss membaca tema dari komponen bergaya. Tujuannya adalah agar kita dapat memigrasikan gaya pada basis per komponen.

Ini mungkin harus terjadi di cabang lain. Meskipun kami tidak ingin mengubah semuanya di master sekaligus, kami mungkin harus merilisnya dengan satu perubahan (di v5). Kalau tidak, ini akan semakin membingungkan.

Penghapusan komentar telah diminta.

Hai guys, saya siap berkontribusi juga... cabang terpisah sepertinya hal yang masuk akal untuk kita lakukan... ayo lakukan ini...!

@caprica-Six Terima kasih atas energinya tetapi cabang baru tidak diperlukan. Kita harus dapat menyediakan versi komponen bergaya secara progresif (+ jss dan emosi) (tidak stabil selama v4), dan memajukan cerita tanpa gaya pada saat yang sama. Saya memiliki POC yang harus saya kirimkan. Komponen gaya (v5 beta) + props dinamis sedikit lebih lambat daripada yang kita miliki dengan JSS dan gaya statis, tetapi ini masih dapat diterima.

@oliviertasinari apakah ada tempat kita bisa terlibat dengannya? Saya agak menunggu pengelola untuk mengarahkan saya ke arah yang benar sebelum melompat ke apa pun

Mengapa Anda tidak lebih memilih emosi daripada komponen gaya? Sepertinya alasannya adalah "[emosi] digunakan oleh beberapa orang. Jika Anda melihat statistik unduhan, 80% berasal dari buku cerita?", tetapi ini salah. Ini lebih banyak digunakan daripada komponen gaya ( perbandingan ) dan saya tidak mengerti mengapa 80% unduhan berasal dari buku cerita. Ini jelas tumbuh jauh lebih cepat daripada buku cerita.

Saya mengajukan pertanyaan ini karena saya muak menggunakan komponen gaya (karena banyak masalah yang saya hadapi) dan mencari alternatif, dan saya menemukan Emosi. Saya mengujinya dan hanya menemukan kelebihan dibandingkan dengan komponen gaya.

Ini lebih ringan, lebih cepat, dan memiliki lebih banyak fungsi: penerusan properti, TypeScript out-of-the-box (dan didukung dengan sempurna dibandingkan dengan komponen-gaya), Next.js SSR out-of-the-box (tanpa harus menimpa _app. js dan file _document.js, yang membutuhkan waktu satu jam untuk saya tangani pertama kali)

Dan terlebih lagi, ini lebih banyak digunakan daripada komponen gaya dan memiliki momentum yang jelas.

@lcswillems Saya pikir kita juga harus mendukung emosi untuk orang-orang yang menyukainya. Tapi saya tidak berpikir bahwa itu harus menjadi default.

• "lebih ringan": Tidak akurat: https://bundlephobia.com/[email protected] (12,2 kB) vs https://bundlephobia.com/result?p=@emotion/ ditata + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (13,1 kB tanpa memperhitungkan ketergantungan bersama)
• "Next.js SSR out-of-the-box": Saya pikir ini adalah masalah yang signifikan, inlining

Terima kasih atas jawaban Anda dan mengoreksi saya.

• "lebih ringan": kamu benar
• "Next.js SSR out-of-the-box": Sekarang saya mengerti mengapa mereka dapat membuat SSR out-of-the-box dan mengapa cara mereka melakukannya tidak baik.
• "lebih banyak digunakan daripada komponen gaya": Saya tidak yakin apakah ini dapat diandalkan. Tetapi sumber saya mungkin juga tidak dapat diandalkan.
• "lebih cepat": Saya hanya melihat tolok ukur yang sudah ketinggalan zaman, jadi tidak, saya tidak memilikinya.

Masalah utama yang saya hadapi adalah penerusan/pemfilteran prop: https://github.com/styled-components/styled-components/issues/439 . Itu sangat sering terjadi pada saya dan sulit untuk melakukan penyaringan secara manual setiap saat.

Tetapi dengan komentar Anda, emosi tampaknya menjadi alternatif yang kurang baik.

"lebih ringan": Tidak akurat: https://bundlephobia.com/[email protected] (12,2 kB) vs https://bundlephobia.com/result?p=@emotion/ ditata + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (13,1 kB tanpa mengambil

Dalam hal Emotion, kemungkinan besar Anda tidak akan menggunakan paket @emotion/styled untuk mendukung css props + @jsx pragma. Anda juga mungkin tidak memerlukan paket emotion-theming , ThemeContext sudah disertakan ke dalam @emotion/core . Jadi 12.2KB vs 6.5KB.

sebaris

Hanya ingin tahu: Apa arti pembaruan ini bagi pengguna perpustakaan @material-ui/styles untuk komponen non-MUI? Di perusahaan saya, kami menggunakannya sebagai basis untuk pustaka komponen internal yang besar, dengan sengaja memilihnya di atas styled-components , dan kami sangat senang dengannya.

Hanya berpikir saya akan check-in sebelumnya jika ada jenis penghentian yang direncanakan untuk paket @material-ui/styles , sehingga saya dapat merencanakannya.

Bagaimanapun, terima kasih untuk semua hal hebat yang terus Anda berikan!

@nickjohnson-dev Migrasi ke react-jss harus mudah. Apakah itu akan berhasil untuk organisasi Anda?

@oliviertasinari Saya pikir kemungkinan itu akan terjadi. Selama kita dapat menjaga API publik dari komponen itu sendiri sebagian besar sama ( classes penggantian lokal berbasis prop, kemungkinan penggantian global dalam tema), saya rasa tidak masalah untuk mengubah detail implementasi.

Apakah Anda mengantisipasi adanya dokumentasi resmi untuk migrasi dari @material-ui/styles ke opsi gaya lainnya setelah MUI lebih dipisahkan? Sekilas saya tidak melihat ada fitur yang kurang dalam react-jss yang kami manfaatkan @material-ui/styles , tetapi saya tidak yakin apakah saya melewatkan sesuatu yang istimewa yang dilakukan oleh paket MUI di balik layar.

@nickjohnson-dev Kami akan melakukan yang terbaik.

Jika saya memahami dengan benar masalah berikut akan terjadi.
Kami memiliki ComponentA yang dapat digunakan kembali. Kami membuat ComponentB yang menggunakan ComponentA .

const ComponentA = ({className}) => (
  <div className={className}>
    <div className='inner' />
  </div>
);

const ComponentB = ({ className, classNameInner }) => (
  <div className={className}>
    <div className='inner'>
      <ComponentA className={classNameInner} />
    </div>
  </div>
)

const StyledComponentB = styled(ComponentB)`
     ???
`;

Perhatikan bagaimana ComponentA dan ComponentB memiliki elemen dengan className='inner' yang sama. Bagaimana kita menargetkan elemen .inner pada ComponentB saja?

Hai @olivietassinari , terima kasih telah berbagi semua pemikiran di balik gaya untuk versi Material UI berikutnya.

Dan terima kasih juga untuk Material UI. Saat ini saya sedang membangun sistem desain di atasnya.

Mengenai mengadopsi styled-components , tampaknya itu adalah keputusan yang dibuat, dan pekerjaan menuju tujuan itu sudah dimulai.

Namun, saya membagikan beberapa pengamatan yang dilakukan oleh @croraf dan @lcswillems

Sesuatu yang hebat dari gaya UI Material saat ini adalah properti classes .

Ini adalah ide sederhana yang sangat membantu dalam penyesuaian gaya dan pemeliharaan karena pengetikan classes adalah bagian dari antarmuka publik. Misalnya, jika saya perlu menyesuaikan sesuatu dan saya menggunakan pemilih seperti & .Component-root tidak ada yang menjamin bahwa Component akan mempertahankan kelas css itu di seluruh versi. Dengan memiliki <Component classes={{root: ....}} /> setidaknya saya bisa mendapatkan kesalahan pemeriksaan tipe (jika menggunakan TypeScript) tentang perubahan antarmuka.

Sebagai penulis komponen, saya dapat memutuskan untuk mendokumentasikan kelas yang bersifat publik (dan didukung) dan membiarkan yang lain tidak terdokumentasi.

Saya menggunakan style-components selama sekitar 2 tahun. Benar bahwa itu populer dan banyak berkembang. Tetapi, dalam contoh dokumentasi MUI, saya melihat masalah yang sama yang disebutkan @croad : menggunakan pemilih turunan & .inner sangat rapuh karena Anda dapat menyebarkan gaya ke sub-komponen (dan dari pengalaman saya sendiri, saya dapat mengatakan itu bukan kasus sudut ... itu terjadi pada saya beberapa kali). Dua solusi yang mungkin adalah:

• Gunakan &.inner dan kemudian gunakan ${props.className}.inner di mana-mana. Saya melakukannya berkali-kali, dan itu menyakitkan untuk ditulis.
• Gunakan > .inner tetapi kemudian itu tergantung pada struktur komponen. Tambahkan beberapa tambahan div di tengah dan itu rusak.

Benar bahwa JSS tidak populer. Saya belajar tentang itu karena MUI. Tetapi setelah bekerja begitu lama dengan styled-components , saya menemukan pendekatan gaya MUI menyegarkan dan lebih mudah untuk digunakan (setelah beberapa saat memiliki Styled HOC di mana-mana menambahkan banyak pekerjaan ekstra dan saya mulai membenci itu HOC...setidaknya itu pengalaman pribadi saya). Emosi kurang lebih cocok dengan pendekatan saat ini. Dan setelah membaca komentar Anda, dan beberapa masalah tentang kinerja JSS dalam kasus-kasus tertentu, saya mengevaluasi untuk menggunakan Emotion untuk sistem desain.

Namun, saya melihat Anda sangat yakin tentang styled-components sehingga saya akan senang melihat lebih banyak contoh tentang cara menyelesaikan penyesuaian gaya menggunakan classes props. Yang tersedia di dokumen MUI saat ini berbagi masalah yang saya sebutkan di atas.

Ada cara lain untuk menggunakan styled-components dengan prop kelas? Apa pendapat Anda tentang hal itu?

JSS cukup baik dan sangat berguna untuk digunakan. Apakah ada alasan kuat untuk pindah?

Secara pribadi saya pikir komponen gaya adalah semacam langkah mundur dan JSS adalah alasan utama bagi saya untuk mulai menggunakan perpustakaan ini untuk jujur.

@powerfulj Mengapa Anda lebih suka JSS daripada komponen Gaya? Saya harus memilih di antara keduanya dan komponen gaya tampak lebih baik bagi saya.

@lcswillems
Saya menyukainya karena saya pikir itu tidak memperkenalkan komponen baru, dan sebaliknya Anda hanya beroperasi pada properti. Jika Anda benar-benar membutuhkan komponen baru yang dapat digunakan kembali yang ditata, Anda dapat dengan mudah membuatnya dengan solusi JSS.

Juga lebih cepat untuk mengkonversi dari gaya sebaris ke gaya JSS, yang nyaman bagi saya karena saya biasanya menggunakan gaya sebaris selama implementasi dan kemudian mengubahnya menjadi JSS jika menjadi lebih besar dan digunakan kembali.

Sisi negatifnya adalah jika Anda memiliki beberapa CSS (seperti dari browser devtools) dan Anda perlu mengubahnya menjadi JSS, Anda harus meluangkan lebih banyak waktu untuk menyesuaikan sintaks. Dengan komponen gaya, ini berjalan lebih cepat.

Sekedar berbagi temuan saya mengenai masalah ini.
Saya mencoba memigrasikan beberapa demo ke komponen gaya seperti yang dipersyaratkan oleh #16947. Masalahnya adalah dengan tema default. makeStyles menerima opsi di mana defaultTheme dapat diteruskan. Ada makeStyles pembungkus yang akan memberikan defaultTheme . Kemudian useStyles hook akan memeriksa apakah ThemeProvider menyediakan tema, dan jika tidak, menyuntikkan defaultTheme .

Tampaknya tidak ada fungsi seperti itu di komponen gaya. Dengan tidak adanya ThemeProvider defaultTheme hanya dapat disuntikkan dengan metode .attrs . Kami dapat membuat sesuatu yang mirip dengan pembungkus makeStyles

import styledWithoutDefault from 'styled-components';
import defaultTheme from './defaultTheme';

const styled = Component => {
  return styledWithoutDefault(Component).attrs({ theme: defaultTheme });
};

export default styled;

Tetapi metode .attrs hanya akan menimpa tema yang disediakan oleh ThemeProvider jika ada. Dan saat ini saya tidak tahu bagaimana menyelesaikan masalah ini.

Masalah lain adalah bahwa makeStyles menggunakan jss-plugin-default-unit preset dan tampaknya komponen gaya tidak. Jadi komponen gaya tidak menambahkan px untuk mengembalikan nilai fungsi spacing() .
Solusi yang mungkin untuk masalah terakhir adalah menggunakan Styled-JSS dan bukan komponen bergaya.

Saya senang di sini ide / saran Anda.

@fyodore82 .attrs berfungsi sebagai fungsi (lihat https://www.styled-components.com/docs/api#attrs), jadi ini akan dilakukan:

```js
.attrs(({ theme = defaultTheme, ...props }) => ({ ...props, theme }))
````

@croraf

Saya menyukainya karena saya pikir itu tidak memperkenalkan komponen baru, dan sebaliknya Anda hanya beroperasi pada properti

Saya pikir Anda telah melewatkan hal yang sangat bagus dari Styled-components: css prop . Ini memungkinkan Anda untuk menambahkan CSS ke komponen tanpa harus membuat yang baru.

Juga lebih cepat untuk mengkonversi dari gaya sebaris ke gaya JSS, yang nyaman bagi saya karena saya biasanya menggunakan gaya sebaris selama implementasi dan kemudian mengubahnya menjadi JSS jika menjadi lebih besar dan digunakan kembali.

Dengan CSS prop, perhatikan bahwa komponen dengan CSS prop tidak memiliki atribut style , itu sudah dikonversi ke komponen gaya dan memiliki class . Jika CSS semakin besar dan digunakan kembali, Anda juga dapat membuat komponen baru.

Sisi negatifnya adalah jika Anda memiliki beberapa CSS (seperti dari browser devtools) dan Anda perlu mengubahnya menjadi JSS, Anda harus meluangkan lebih banyak waktu untuk menyesuaikan sintaks. Dengan komponen gaya, ini berjalan lebih cepat.

Saya setuju. Ini adalah alasan utama saya tidak menggunakannya. Sebagian besar CSS yang ditulis secara online ditulis dalam CSS, bukan dalam JSS. Jadi jika Anda ingin menggunakan beberapa kode dari StackOverflow, Anda harus mengubahnya terlebih dahulu ke JSS, yang sangat menyakitkan.

Argumen tambahan lain yang membuat saya menggunakan komponen Gaya:

• Lebih menyakitkan untuk menulis JSS: Anda harus menambahkan tanda kutip, Anda tidak memiliki penyorotan sintaks (atau saya tidak dapat menemukannya).
• Lebih sulit untuk dipahami oleh pendatang baru. Semua orang tahu CSS sehingga semua orang dapat dengan mudah membaca kode dengan komponen Gaya yang tidak demikian dengan JSS (sintaks JSS umumnya agak aneh dan khususnya untuk penyeleksi semu dan kueri media).
• Kode jauh lebih mudah dibaca. Untuk mengilustrasikan poin ini, saya menulis ulang contoh komponen Kartu ini dengan komponen-komponen Gaya untuk menunjukkan seberapa jelas hal itu dengan komponen-komponen tersebut.

versi JSS:

import React from 'react';
import { makeStyles, useTheme } from '@material-ui/core/styles';
import Card from '@material-ui/core/Card';
import CardContent from '@material-ui/core/CardContent';
import CardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import PlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

const useStyles = makeStyles(theme => ({
  card: {
    display: 'flex',
  },
  details: {
    display: 'flex',
    flexDirection: 'column',
  },
  content: {
    flex: '1 0 auto',
  },
  cover: {
    width: 151,
  },
  controls: {
    display: 'flex',
    alignItems: 'center',
    paddingLeft: theme.spacing(1),
    paddingBottom: theme.spacing(1),
  },
  playIcon: {
    height: 38,
    width: 38,
  },
}));

export default function MediaControlCard() {
  const classes = useStyles();
  const theme = useTheme();

  return (
    <Card className={classes.card}>
      <div className={classes.details}>
        <CardContent className={classes.content}>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <div className={classes.controls}>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon className={classes.playIcon} />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </div>
      </div>
      <CardMedia
        className={classes.cover}
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

Versi komponen gaya:

import React from 'react';
import styled from 'styled-components';
import { useTheme } from '@material-ui/core';
import MuiCard from '@material-ui/core/Card';
import MuiCardContent from '@material-ui/core/CardContent';
import MuiCardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import MuiPlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

export default function MediaControlCard() {
  const theme = useTheme();

  return (
    <Card>
      <Details>
        <CardContent>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <Controls>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </Controls>
      </Details>
      <CardMedia
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

const Controls = styled.div`
  display: flex;
  align-items: center;
  padding-left: ${props => props.theme.spacing(1)}px;
  padding-bottom: ${props => props.theme.spacing(1)}px;
`

const PlayArrowIcon = styled(MuiPlayArrowIcon)`
  height: 38px;
  width: 38px;
`

Akhirnya, saya tidak dapat menemukan keuntungan menggunakan JSS.

properti css sangat bagus, dan pada dasarnya memecahkan kelemahan yang saya sebutkan. (peniru bentuk komponen gaya :D )

Mengenai perbandingan dua contoh saya tidak merasa banyak dibaca dan menggandakan jumlah komponen.

@lcswillems

Tidak berdebat untuk satu solusi atau yang lain, hanya mengambil beberapa poin Anda:

jika Anda ingin menggunakan beberapa kode dari StackOverflow, Anda harus mengubahnya terlebih dahulu ke JSS, yang sangat menyakitkan

Ada ekstensi VSCode untuk mengonversi CSS ke CSS-in-JS, meskipun tidak selalu berfungsi dengan sempurna. Terlepas dari itu, saya tidak akan menyebutnya menyakitkan.

Anda tidak memiliki penyorotan sintaksis

Saya tidak begitu mengerti argumen ini. Itu hanya objek JS, jadi penyorotan sintaks editor apa pun berfungsi:

(tapi mungkin Anda sedang mencari sesuatu yang lebih spesifik?)

Mengenai perbandingan dua contoh saya tidak merasa lebih mudah dibaca. Meskipun kurangnya props className bisa dibilang lebih bersih, tidak jelas dari blok kode JSX utama apakah komponen merujuk ke komponen asli MUI, atau yang dibenahi tanpa harus merujuk silang komponen styled() . Dalam komponen yang lebih besar ini bisa jauh dihapus.

Doa styled() (bagi saya) kurang dapat dibaca daripada objek JSS (walaupun saya membayangkan Anda terbiasa dengannya).

@powerfulj Mengapa Anda lebih suka JSS daripada komponen Gaya? Saya harus memilih di antara keduanya dan komponen gaya tampak lebih baik bagi saya.

Karena saya sendiri adalah pengembang TypeScript dan saya lebih suka membangun semuanya di objek TypeScript. Terutama aku benci string.

Meskipun kami perlu mentransfer kode CSS ke kode JSS karena perbedaannya, saya masih lebih suka membaca kode JSS karena strukturnya terlihat seperti CSS tradisional (berorientasi kelas), saya akan menghabiskan lebih banyak waktu untuk membaca kode komponen gaya karena lebih lama dan bisa di sana-sini.

Saya pikir orang mengklaim perubahan ini hanya karena mereka memiliki pengalaman dalam komponen Gaya di masa lalu. Ini memberi saya perasaan seperti "mengapa kita tidak memilih perpustakaan yang kita kenal tetapi tanpa manfaat yang jelas?".

Dari sudut pandang saya, JSS hanya berguna, kita dapat mengatur objek dengan menggunakan semua cara Javascript seperti

{
...berbagiJSS1,
...berbagiJSS2,
apa pun
}

Kami juga memiliki tema dinamis mulus yang terintegrasi dengan tipe dan kami mendapatkan semua petunjuk tipe dari tipe className dan css.

Untuk pengembang baru terutama pengembang TypeScript akan sangat menyukai JSS.

FYI, dimungkinkan untuk melakukan beberapa penyarangan di komponen gaya jika Anda tidak selalu menginginkan komponen terpisah untuk semuanya. Ini umumnya tidak disarankan, karena menggunakan komponen terpisah dengan nama yang bermakna dianggap lebih bersih dan lebih mudah dibaca menurut filosofi komponen gaya, tetapi dokumen mengatakan tidak apa-apa jika "digunakan dengan hemat". Dan tentu saja, bagi siapa saja yang tidak menganut filosofi itu, mereka bebas untuk melakukan lebih banyak sarang. Sebagai contoh yang saya maksud dengan bersarang:

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

Lihat https://www.styled-components.com/docs/faqs#can -i-nest-rules untuk detail selengkapnya.

Diskusi tentang preferensi gaya pengkodean dapat berlanjut selamanya.

Setelah menggunakan styled-components untuk sementara waktu, saya lebih menyukai pendekatan JSS, karena:

• Ketika gaya menjadi lebih panjang, saya biasanya memindahkannya ke file terpisah.
  Saya telah melakukannya dengan styled-components juga, dan menurut saya useStyles / makeStyles lebih mudah untuk ditulis, dibaca, dan dipelihara. Misalnya. import useStyles from './MyComp.styles' vs import {XStyled, YStyled,...} from './MyComp.styles' ... mempertahankan variasi ...Styled dengan pengetikan mereka di TS itu menjengkelkan.
• Saya cenderung melakukan hal-hal secara progresif: pertama saya mulai dengan draft menggunakan div dan kelas, dan kemudian saya refactor mereka menjadi komponen. Saat menggunakan styled-components Saya melakukannya dengan menggunakan kelas dalam (seperti pada contoh dari @mbrowne), tetapi membutuhkan lebih banyak pekerjaan refactoring. Saya menemukan pendekatan useStyles jauh lebih nyaman untuk bekerja dengan alur kerja itu.
• Literal templat bagus untuk menempelkan kode CSS, tetapi buruk ketika Anda harus menggunakan variabel tema/prop. Masalah kode tempel mudah diselesaikan dengan plugin, tetapi pengeditan dengan variabel dan fungsi di dalam literal templat tidak terlalu banyak.

Tapi ini adalah preferensi pribadi saya, Anda mungkin berbeda.

Pertanyaan terbuka terbesar saya adalah tentang perubahan penggunaan classes .

Contoh penggunaan className dan kelas dalam memiliki masalah (lihat komentar saya sebelumnya). Prop css di styled-components bukanlah pilihan untuk memecahkan masalah tersebut. Tidak seperti fungsi css dalam Emotion, prop css bergantung pada pemasangan ke sebuah komponen (artinya Anda tidak dapat menggunakannya dalam gaya kode useStyle/makeStyles/classes ).

Keterikatan gaya pada komponen bukanlah keputusan desain yang kecil. Bagi saya, itu baik dan buruk dari JSS. Komponen gaya dan Emotion bergantung pada plugin Babel dan berinteraksi dengan React untuk menangani caching dan pembuatan nama kelas untuk SSR. Bagian yang baik dari JSS, adalah tidak memerlukan plugin Babel. Bagian buruknya adalah SSR di JSS membutuhkan lebih banyak pekerjaan, dan saya telah melihat bug yang dilaporkan di area itu.

Kembali ke MUI, saya mendapat kesan bahwa mengadopsi komponen gaya berarti menggunakan className dan kelas dalam sebagai satu-satunya cara untuk menyesuaikan gaya. Penataan gaya menjadi lebih konsisten di seluruh kerangka kerja: Anda dapat menggunakan styled atau css prop, selama komponen menggunakan className Anda mahir.

Tetapi bagi saya menghapus prop classes adalah langkah mundur. Prop itu membantu mendokumentasikan dan mengetik kustomisasi gaya cek. Mungkin dimungkinkan untuk menemukan jalan tengah, seperti menggunakan komponen gaya tetapi tetap mendukung classes (tanpa perlu peretasan kelas dalam). Saya tidak dapat menemukan apa pun di API komponen gaya yang membantu dalam kasus itu. Itu sebabnya mungkin baik untuk mengevaluasi apa saja masalah teknis JSS. Karena jika popularitas adalah masalah utama, Emosi juga menjadi populer (lihat https://2019.stateofcss.com/technologies/css-in-js/#tools-section-overview), dan mungkin cara yang mudah untuk tulis ulang makeStyles .

@dfernandez-asapp Anda membuat beberapa poin bagus hanya dengan membalas sebagian kecil dari fwiw ini @styled-components mendukung penggunaan objek yang mirip dengan jss alih-alih string https://www.styled-components.com/docs/advanced# gaya -objek

Meskipun komponen gaya yang cukup mengecewakan menghapus dukungan TypeScript kelas satu dan secara keseluruhan setuju dengan Anda bahwa itu tampak seperti langkah mundur dengan cara lain yang Anda jelaskan

FYI, dimungkinkan untuk melakukan beberapa penyarangan di komponen gaya jika Anda tidak selalu menginginkan komponen terpisah untuk semuanya. Ini umumnya tidak disarankan, karena menggunakan komponen terpisah dengan nama yang bermakna dianggap lebih bersih dan lebih mudah dibaca menurut filosofi komponen gaya, tetapi dokumen mengatakan tidak apa-apa jika "digunakan dengan hemat". Dan tentu saja, bagi siapa saja yang tidak menganut filosofi itu, mereka bebas untuk melakukan lebih banyak sarang. Sebagai contoh yang saya maksud dengan bersarang:

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

Lihat https://www.styled-components.com/docs/faqs#can -i-nest-rules untuk detail selengkapnya.

Setiap jenis dukungan untuk ini? Atau kita harus memasang tali di mana-mana?

Saya tidak mengerti mengapa ada begitu banyak hype untuk komponen bergaya. Rasanya seperti mundur selangkah untuk jujur. Properti CSS yang diketik dari JSS dengan TypeScript jauh lebih nyaman dan lebih mudah dirawat, ditambah ada pemeriksaan sintaks sebagai bagian dari JS - editor modern/yang dikonfigurasi akan memberi tahu Anda jika Anda pernah membuat kesalahan ketik dan bahkan membantu Anda dengan penyelesaian otomatis jika itu diinginkan.

edit: Sudah diketik, lihat balasan South-Paw di bawah ini.

@martinjlowm sepertinya ada pengetikan untuk saya?

Lihat: https://styled-components.com/docs/advanced#style -objects

Anda bilang Anda tidak mengerti hype... tapi saya juga tidak mengerti semua kebencian yang didapat. 🤷♂.

Emosi dan komponen gaya adalah peningkatan besar dibandingkan objek gaya CSS IMO

@martinjlowm sepertinya ada pengetikan untuk saya?

...

Lihat: https://styled-components.com/docs/advanced#style -objects

Anda bilang Anda tidak mengerti hype... tapi saya juga tidak mengerti semua kebencian yang didapat. 🤷♂.

Emosi dan komponen gaya adalah peningkatan besar dibandingkan objek gaya CSS IMO

Saya melihat! Saya tidak menyadari bahwa itu mendukung objek seperti itu. Kekhawatiran saya terkait dengan CSS dalam string templat - tetapi jika objek adalah opsi, maka saya tidak menentangnya!

Jelas, JSS juga tidak sempurna, saya tahu - lembar yang dihasilkan server yang dapat digunakan kembali akan menjadi fitur pembunuh - apakah komponen gaya mendukung itu entah bagaimana? Apakah ada yang tahu?

Saat ini, rasanya bodoh harus menghapus stylesheet yang dihasilkan server dan memaksa klien untuk merender ulang semua gaya :(

@martinjlowm sepertinya ada pengetikan untuk saya?
...
Lihat: https://styled-components.com/docs/advanced#style -objects
Anda bilang Anda tidak mengerti hype... tapi saya juga tidak mengerti semua kebencian yang didapat. 🤷♂.
Emosi dan komponen gaya adalah peningkatan besar dibandingkan objek gaya CSS IMO

Saya melihat! Saya tidak menyadari bahwa itu mendukung objek seperti itu. Kekhawatiran saya terkait dengan CSS dalam string templat - tetapi jika objek adalah opsi, maka saya tidak menentangnya!

Jelas, JSS juga tidak sempurna, saya tahu - lembar yang dihasilkan server yang dapat digunakan kembali akan menjadi fitur pembunuh - apakah komponen gaya mendukung itu entah bagaimana? Apakah ada yang tahu?

Saat ini, rasanya bodoh harus menghapus stylesheet yang dihasilkan server dan memaksa klien untuk merender ulang semua gaya :(

Saya juga ingin mengklarifikasi bahwa literal templat yang diberi tag juga dapat diketik. TypeScript akan menandainya dengan benar sebagai tidak valid dan layanan bahasa akan memberikan saran pelengkapan otomatis, dll.

@Orang kidal

Emosi dan komponen gaya adalah peningkatan besar dibandingkan objek gaya CSS IMO

Saya masih bingung mengapa ada pengembang Bereaksi yang menyukai ini. Jika Anda ingin memasukkan CSS Anda ke dalam string templat, mengapa Anda tidak menggunakan Angular saja dan memasukkan HTML Anda ke dalam string templat juga? Kekuatan React adalah bahwa elemen JSX sebenarnya hanyalah objek JS yang memiliki banyak kekuatan untuk Anda periksa dan ubah, dan hal yang sama berlaku untuk JSS.

Semua hal yang mendorong CSS dalam gerakan JS adalah kenyataan bahwa JS jauh lebih unggul daripada CSS untuk melakukan hal-hal dinamis, dan kekuatan objek JS bukanlah bagian kecil dari itu.

Fakta bahwa styled-components mendukung objek adalah semacam ikan haring merah:

• Ini mendukung mereka, tetapi untuk beberapa alasan mengatakan "Ini sangat berguna ketika Anda memiliki objek gaya yang ada dan ingin secara bertahap pindah ke komponen gaya." Mereka tampaknya tidak melihat nilai untuk dapat memanipulasi objek dan sepertinya objek gaya akan selalu diperlakukan sebagai warga negara kelas dua di API mereka.
• Dokumen tidak menjelaskan apakah itu mendukung pemilih CSS dunia nyata seperti ini dengan JSS:

{
  color: 'black',
  '&$error': {
    color: 'red'
  }
}

Bahkan Emosi menghormati nilai objek gaya dan memperlakukannya lebih sebagai warga negara kelas satu:

Gaya menulis dengan objek adalah pola kuat yang dibangun langsung ke dalam inti emosi.

@lcswillems Anda meremehkan seberapa besar kerumitan untuk membuat semua HOC kecil ini sepanjang waktu (dan fakta bahwa sebagian besar sistem impor otomatis tidak cukup pintar untuk mengetahui apakah Anda ingin mengimpor @material-ui/core/Card sebagai Card atau MuiCard (dan jika Anda masih menulis pernyataan impor dengan tangan, Anda membuang-buang waktu))

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

Hal semacam ini menyebabkan kelelahan keputusan yang mengerikan karena Anda terus-menerus harus memutuskan bagaimana memberi nama setiap pembungkus dan komponen yang dibungkus.

Inilah yang dibicarakan oleh @dfernandez-asapp ketika dia berkata:

(setelah beberapa saat memiliki HOC Bergaya di mana-mana menambahkan banyak pekerjaan ekstra dan saya mulai membenci HOC itu ... setidaknya itu adalah pengalaman pribadi saya)

HOC cukup banyak harus mati. Ini adalah pola usang. Misalnya, react-redux keluar dengan hook useSelector yang 100 kali lebih nyaman daripada connect HOC, Apollo pindah dari HOC ke hook, hal yang sama berlaku untuk useStyles hook di perpustakaan ini lebih nyaman daripada withStyles .

Kerumitan mengonversi CSS yang disalin-tempel ke JSS adalah masalah yang jauh lebih dapat dipecahkan, jika ada minat, saya bahkan akan membuat ekstensi VSCode untuk mengotomatiskannya atau situs web.

jika ada minat, saya bahkan akan membuat ekstensi VSCode untuk mengotomatiskannya

@jedwards1211 Ada paulmolluzzo.convert-css-in-js , tetapi jika Anda dapat meningkatkannya untuk JSS, saya yakin itu akan disambut.

Ya sepertinya saya pasti bisa memperbaikinya, itu hanya mengubah properti CSS, bukan aturan dan penyeleksi.

@ jedwards1211 Saya membaca apa yang Anda katakan, dan mengambil langkah mundur dari semua ini sejenak - itu hanya mengingatkan saya pada komentar dari orang-orang yang berdebat tentang penggunaan tab di atas spasi. Kenyataannya adalah tidak ada bedanya apa yang Anda gunakan selama itu menghasilkan produk yang bermanfaat pada akhirnya.

Tinggalkan opini/pendapat panas Anda di Twitter atau Reddit dan kita bisa mendiskusikannya di sana - tapi jangan terus menggagalkan masalah ini dengan perang api yang tidak berguna pada string template vs objek untuk CSS... Saya pikir kita semua bisa setuju bahwa kita lebih baik dari itu

Terima kasih telah menunjukkan bahwa tidak ada gunanya mengubah status quo di MUI? 😉.

Perhatian utama saya adalah jika bundel webpack saya membengkak dengan campuran kode komponen gaya dan kode JSS, karena ada terlalu banyak JSS yang ada di aplikasi kami untuk ditarik dan diganti dengan yang lain, dan/atau karena saya ingin tetap menggunakan JSS untuk gaya kami pula.

Agar adil, saya tidak peduli tentang tab vs spasi, tetapi jika saya harus menulis setengah lusin HOC untuk setiap komponen yang saya buat, saya tidak akan menikmati pekerjaan saya. Semua alat yang ada memiliki kemampuan untuk menghasilkan produk yang bermanfaat; jika ada sesuatu yang benar-benar nyaman digunakan dalam semua kasus, tidak akan ada perubahan konstan dalam ekosistem, dan kita tidak akan mengalami perdebatan ini. Jadi itu benar-benar membuat perbedaan ketika Anda memikirkannya.

@jedwards1211 bahkan jika Anda terpaksa menggunakan Komponen Bergaya, ada alternatif sintaks css prop yang diperkenalkan di v4 yang dapat Anda gunakan - setidaknya, dengan cara ini Anda tidak perlu khawatir memberikan awalan ke komponen yang ditata (MuiCard, StyledCard, dll.).

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

// CSS is separate from the markup 👍
const avatarStyle = css`
  width: 32px;
  height: 32px;
  border-radius: 50%
`;

// No wrappers, prefixes in the markup (such as <MuiAvatar>, <StyledAvatar> etc.) 👍
function SomeComponent(props) {
  return <div> ... <Avatar css={avatarStyle} /> ... </div>
}

@jedwards1211 contoh Anda juga dapat disederhanakan menjadi berikut jika Anda menggunakan komponen gaya

const Card = styled(MuiCard)`
  display: flex;

  ${MuiCardContent} {
    flex: 1 0 auto;
  }

  ${MuiCardMedia} {
    width: 151px;
  }
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

@koistya prop css agak keren, meskipun peringatan penting ini diimplementasikan dengan plugin Babel, jadi ini bukan untuk semua orang, terutama orang yang menggunakan tsc untuk mengkompilasi file tsx mereka. Saya juga berasumsi itu akan menyebabkan TypeScript atau setidaknya Flow mengeluh bahwa komponen tidak memiliki prop css .

Saya pikir saya hanya tidak senang dengan potensi gangguan yang akan terjadi pada aplikasi saya. @olivietassinari menyebutkan beberapa hari yang lalu bahwa dia berpikir untuk menjadikan styled-components sebagai default di MUI v5. Dan semoga itu opsional dan JSS masih bisa digunakan, tapi kita akan lihat apakah mereka bisa melakukannya, Anda tahu. Itu mengejutkan -- Apakah benar-benar ada referendum menyeluruh tentang preferensi seluruh basis pengguna? Saya akan mengharapkan Emosi jika ada karena itu jauh lebih populer sekarang.

Saya juga berasumsi itu akan menyebabkan TypeScript atau setidaknya Flow mengeluh bahwa komponen tidak memiliki prop css.

Dapat dikonfigurasi.

Apakah benar-benar ada referendum menyeluruh tentang preferensi seluruh basis pengguna?

Ini tidak mungkin. Kami hanya dapat berasumsi bahwa orang yang terlibat di GitHub adalah pengguna "kami". Masalah ini adalah yang paling banyak dipilih yang pernah kami miliki .

Saya akan mengharapkan Emosi jika ada karena itu jauh lebih populer sekarang.

Bagaimana Anda mengukur popularitas?

️ emosi secara signifikan lebih sedikit dipilih oleh pengembang daripada komponen gaya (/6 dari yang saya ingat). Jika Anda menganggap unduhan di npm, hapus buku cerita dan pilih jumlah unduhan (sangat besar).

@eps1lon inilah yang saya lihat: https://2019.stateofcss.com/technologies/css-in-js/

Saya salah, sayangnya yang saya ingat hanyalah tren yang tampaknya naik, meskipun ini bukan grafik popularitas dari waktu ke waktu (desain grafik yang sangat dipertanyakan):

Dapat dikonfigurasi

Apakah sebenarnya ada cara untuk membuat TypeScript menganggap semua elemen JSX mendukung prop css ? Saya tidak tahu cara mengonfigurasi Flow untuk melakukan itu.

EDIT : untungnya saya menemukan cara untuk TypeScript, tidak yakin apakah ada cara untuk Flow.

Masalah ini adalah yang paling banyak dipilih yang pernah kami miliki.

Saya melihat. Mendesah

FWIW, salah satu kontributor utama styled-components tampaknya memiliki sikap yang tidak ramah terhadap sistem tipe:

https://github.com/styled-components/styled-components/issues/3012#issuecomment -583878486

Saya akan merasa jauh lebih yakin tentang gagasan untuk bermigrasi ke komponen bergaya jika mereka tampaknya peduli dengan pengalaman pengembangan pengguna TS/Flow...

@jedwards1211 ada makro Babel untuk css jika itu membantu. Terutama yang berasal dari css/scss/less Saya tidak berpikir semua orang suka pindah ke cara "bergaya".

Apa tujuan meskipun? Bagaimana dengan kinerja? Misalnya beberapa sistem mendukung css atom. Berasal dari Tailwinds, ini membuat segalanya lebih bersih dan mungkin lebih cepat.

@hc-codersatlas Anda dapat menemukan beberapa tolok ukur di packages/material-ui-benchmark .

@koistya jika saya membacanya dengan benar, emosi terlihat jauh lebih cepat daripada yang lain.

@oliviertasinari apakah sebagian besar pengembang benar-benar "membuat" pilihan ini? Sesuai penyebutan Anda tentang pilih-reaksi dan buku cerita, sebagian besar pengembang kemungkinan akan menggunakan apa pun yang dibundel dengan komponen UI dan material-ui menjadi 1 besar. Kecuali apa yang dibundel buruk, tidak ada 1 yang akan meningkatkan ukuran bundel dan pengeluaran lebih banyak upaya dengan sistem yang berbeda di atas kerangka kerja UI yang sudah digunakan.

Sebagian besar kerangka kerja UI ini berasal dari korps besar, yaitu beberapa orang yang benar-benar membuat "pilihan" ini.

misalnya grommet menggunakan komponen gaya, yang digunakan/digunakan oleh banyak perusahaan pada 1 titik.

Dan pada catatan itu apa artinya unduhan npm? Penggunaan korporat kemungkinan besar berarti firewall dan caching npm internal, yang mencondongkan metrik ini.

Jika akan ada perubahan harap ubah ke 1 terbaik berdasarkan prestasi teknis dan bukan sesuatu seperti popularitas. Saya memperkirakan bahwa jika material-ui menggunakan pustaka apa pun, itu akan menjadi yang populer 1 karena mui itu sendiri adalah 1 dari kerangka kerja ui paling populer.

@South-Paw penyederhanaan yang Anda usulkan tidak akan berfungsi, Anda tidak dapat menggunakan ${MuiCardContent} dalam contoh Anda karena MuiCardContent bukan komponen gaya.

https://styled-components.com/docs/advanced#referring -to-other-components

Pada dasarnya tidak ada cara untuk menghindari semua pembungkus HoC individu. Meskipun setelah memikirkannya sebentar, saya menyadari bahwa pada dasarnya jumlah keputusan pengetikan/penamaan yang sama seperti yang harus dibuat dengan JSS.

@mbrookes @oliviertasinari bagaimana gaya bersyarat dan gaya komponen dalam ditangani?
Misalnya, apa yang setara dengan styled-components -berbasis berikut ini?

// conditional class name
<MenuItem classes={{selected: classes.selectedItem}}>...</MenuItem>

// inner component class name
<Dialog classes={{paper: classes.dialogPaper}}>...</Dialog>

Saya sudah tenang tentang gagasan beralih ke styled-components , tetapi saya ingin memastikan ada rencana yang solid untuk menangani kasus penggunaan semacam ini, karena saya menganggap API harus sangat berbeda atau bergantung pada nama kelas gaya BEM.

@jedwards1211 ah kesalahan saya. Saya mendapat kesan bahwa contohnya adalah jika mereka adalah komponen yang ditata - tetapi memang itu tidak akan berfungsi jika tidak 👍

@ jedwards1211 clsx adalah sesuatu yang pernah saya lihat dipasangkan dengan komponen gaya di masa lalu untuk kelas bersyarat - apakah itu yang Anda maksud?

Proyek yang saya lakukan saat ini menggunakan komponen gaya yang membungkus komponen MUI sesuai kebutuhan, jadi saya belum pernah menggunakan gaya bersyarat MUI apa pun.

@South-Paw itu (atau classnames ) bisa menjadi detail internal dari solusi, tetapi yang saya maksud adalah karena pembungkus styled-components hanya menyuntikkan satu className AFAICT, tidak akan ada 't benar-benar menjadi cara yang nyaman untuk melewatkan beberapa nama kelas yang ditimpa ke dalam sebuah komponen. Alih-alih, kita mungkin harus melakukan sesuatu seperti <Dialog Paper={StyledPaper}>...</Dialog> , dan saya bahkan tidak yakin apa untuk contoh kelas MenuItem yang dipilih.

@ jedwards1211 apakah Anda punya waktu untuk melakukan contoh cepat sehingga saya dapat lebih memahami apa kasus penggunaan yang Anda gambarkan dan di mana Anda merasa masalahnya? Saya ingin dapat mencoba bantuan dengan solusi tetapi saya belum mengerti untuk apa ini berlaku

Ya, saya kehabisan waktu malam ini, tetapi besok saya akan melakukannya.
Saya juga sedang mengerjakan jss-codemorphs , yang pada akhirnya berencana untuk membuat ekstensi VSCode untuk mengubah CSS yang ditempel menjadi JSS.

tidak pernah menjadi penggemar sintaks komponen gaya atau cara paket dipertahankan, bukan penggemar proposal ini. Salah satu hal yang paling saya sukai dari material ui adalah solusi gaya saat ini.

Sangat menarik untuk dicatat saya membaca Facebook mungkin open-source solusi CSS-in-JS juga. Itu bisa berharga untuk melihat itu juga ketika keluar.

Tentang topik yang sebenarnya di tangan. Saya tidak suka komponen gaya karena pengalaman TypeScript tidak bagus. Tipe-tipe tersebut seringkali lebih banyak merugikan daripada membantu. Waktu kompilasi yang lambat, antarmuka yang gila (mencoba memahami bagaimana komponen gaya bekerja melalui antarmuka adalah mimpi buruk karena semua keajaiban Pick yang bersarang). Selama komponen gaya memiliki jenis DX ini, akan terasa sebagai langkah mundur bagi material-ui untuk mengadopsi ini.

Sangat menarik untuk dicatat saya membaca Facebook mungkin open-source solusi CSS-in-JS juga.

@venikx Seberapa besar kemungkinan itu akan terjadi? Terakhir kali saya mendengar tentang sesuatu yang mungkin menyarankan itu di https://reactpodcast.simplecast.fm/75 , sepertinya itu adalah tujuan 5 tahun.

Wow benarkah? Saya tidak tahu mereka sudah memberikan "garis waktu". Untuk beberapa alasan saya berasumsi itu akan muncul bersamaan dengan Mode Bersamaan. Sayang sekali.

Meskipun demikian, poin saya tentang komponen gaya masih berlaku. Saya lebih suka menggunakan cara penanganan gaya material-ui murni vs menggunakan komponen gaya. Pengetikan dari komponen-gaya tampaknya ada untuk kompiler dan tidak begitu banyak untuk dokumentasi.

Hal lain yang mengganggu (tapi itu mungkin sekali lagi preferensi pribadi) adalah bagaimana Anda menangani penerapan gaya secara dinamis ke suatu komponen. Saya lebih suka menambahkan atau menghapus classNames daripada menyematkan logika itu ke dalam komponen gaya.

Material-ui api benar-benar bersih saat ini.

Saya tidak suka komponen gaya karena pengalaman TypeScript tidak bagus.

Saya telah menggunakan komponen gaya dan TypeScript bersama-sama di setidaknya 4 proyek besar sejauh ini dan tidak memiliki masalah dengan tipe - mereka bisa sedikit berbulu ketika melakukan sesuatu di perpustakaan komponen, tetapi itu akan berada di ujung MUI - tidak pada konsumen akhir.

Waktu kompilasi lambat

Saya belum pernah mengalami ini dalam proyek apa pun yang pernah saya kerjakan yang menggunakannya - apakah Anda memiliki contoh di suatu tempat tentang apa yang Anda maksud?

antarmuka gila (mencoba memahami bagaimana komponen gaya bekerja melalui antarmuka adalah mimpi buruk karena semua sihir Pick bersarang itu)

Anda juga dapat mempertimbangkan untuk berkontribusi pada proyek @types untuk itu jika Anda pikir Anda dapat meningkatkannya entah bagaimana - saya yakin semua orang akan menghargai pekerjaan apa pun di sana jika ini merupakan peningkatan dari apa yang ada sekarang!

Saya lebih suka menambahkan atau menghapus classNames daripada menyematkan logika itu ke dalam komponen gaya.

Tidak ada yang menghentikan Anda untuk menggunakan kelas dengan komponen gaya:

const Box = styled.div`
  height: 160px
  width: 160px;
  background-color: black;

  .red {
    background-color: red;
  }
`;

// simple usage
<Box className="red" />

// get more complex with conditionals and using something like clsx (https://www.npmjs.com/package/clsx)
const isRed = true;
<Box className={clsx({ red: isRed })} />

Perlu dicatat bahwa meskipun beberapa komentar mengklaim sebaliknya, ada 150 👍 dan 27 pada masalah induk dan hanya 18 dan 9 . Sepertinya ada minoritas vokal yang tidak menyukai diskusi ini dan mayoritas menganggap ini sebagai langkah positif

@ South-Paw masalah dengan pemungutan suara adalah bahwa satu-satunya pilihan adalah: JSS vs komponen gaya. Bagian vokal adalah tentang tidak menyukai komponen yang ditata dan bukan karena mereka menyukai JSS. Mungkin kalau vote

Pada akhirnya, semuanya lebih baik daripada JSS. Ini sudah tua. Ini lambat dan besar (ukuran bundel) dan harus dipindahkan. Jadi suara tidak mendukung kesimpulan Anda sama sekali.

Bisakah Anda semua pindah ke obrolan Spectrum atau sesuatu yang tidak mengisi masalah ini dengan kebisingan tentang orang-orang yang berkelahi satu sama lain untuk melihat siapa yang memenangkan argumen?

Saya mengikuti utas untuk diskusi tentang topik ini dari tim inti.

Saya pikir Anda meremehkan penilaian tim inti, dan secara pribadi saya merasa Anda harus berhenti berdebat tentang topik ini dan lebih mempercayai tim inti; pada akhirnya, terserah pada tim inti untuk memutuskan arah Material UI.

Jika Anda benar-benar merasa sangat berpendirian tentang hal itu, Material UI adalah luar biasa berlisensi MIT, garpu itu, dan melanjutkan visi yang Anda miliki, saya mendorong Anda untuk melakukannya, mungkin kita belajar di masa depan dari lingkungan yang beragam.

Tapi, tolong, saya mohon, biarkan tim inti melakukan tugasnya, percayalah kepada mereka, karena mereka benar-benar orang yang kompeten dengan keterampilan yang luar biasa.

Ini sesuatu yang indah untuk ditonton

Pada akhirnya, semuanya lebih baik daripada JSS. Ini sudah tua.

@hc-codersatlas old == dewasa -- dapatkah Anda menjelaskan mengapa itu menjadi masalah?

Ok sepertinya masalah panas tetapi dapatkah seseorang mengonfirmasi info sederhana ini: apakah saat ini mungkin untuk menggunakan sintaks seperti styled-components , dengan literal templat yang ditandai yang terlihat seperti CSS, dalam versi Mui saat ini (4 atau 5) ?
Saya tidak dapat menemukan jawaban ya atau tidak yang jelas untuk pertanyaan ini. Saya tidak terlalu peduli dengan teknologi yang mendasarinya, hanya tentang kenyamanan pengembang. Copy-paste CSS dari InVision pada dasarnya cukup berguna dalam beberapa kasus.

Masalah ini adalah tentang solusi penataan gaya yang digunakan di Material-UI, pertanyaan Anda tampaknya tentang bagaimana Anda menata aplikasi Anda/menyesuaikan gaya komponen, di mana Anda dapat menggunakan solusi apa pun:

https://material-ui.com/guides/interoperability/

JSS memiliki dukungan dasar untuk literal template sebagai plug-in.

Saya baru saja selesai mengimplementasikan konverter CSS ke JSS yang sangat komprehensif:

• https://codemodsquad.github.io/jss-codemorphs/
• Ekstensi VSCode: https://marketplace.visualstudio.com/items?itemName=vscodeshift.jss-codemorphs

Mudah-mudahan akan menghilangkan kerumitan menyalin dan menempelkan CSS ke dalam gaya JSS.

@jedwards1211 lihat ini
https://css2js.dotenv.dev/

@nainardev Saya perhatikan itu dan utilitas lain sangat terbatas, mereka mengonversi atribut CSS, tetapi tidak mengonversi penyeleksi, penyeleksi bersarang, bingkai kunci animasi, kueri media, dll. Karena itu saya membuat alat saya sangat komprehensif, ia dapat mengonversi mudah-mudahan setiap CSS lengkap yang Anda berikan.

Mungkin telah melewatkan jawaban ini di suatu tempat, tetapi tetap ingin mengangkatnya. Kami sedang dalam proses migrasi ke komponen Material UI serta mengevaluasi solusi penataan gaya kami ( less vs makeStyles vs styled-components ), sebagian besar penataan kami dilakukan melalui less file dan sebagian besar kode MUI baru menggunakan makeStyles , yang ingin saya klarifikasi adalah karena ini akan menjadi bagian dari v5, apa yang dapat kita lakukan untuk mengurangi utang teknis seputar penataan?

1. Akankah makeStyles ada di v5? Bagaimana cara kerjanya dengan styled-components dan tema? Misalnya, bagaimana tampilannya dengan styled-components :

const useStyles = makeStyles((theme) => ({
  paper: {
    padding: theme.spacing(2),
    textAlign: 'center',
    color: theme.palette.text.secondary,
  },
}));

1. (v4) Apakah ada cara yang lebih baik untuk mengambil objek theme dalam string template bergaya daripada ini, jadi saya bisa menggunakannya beberapa kali?

const StyledContainer = styled.div`
  color: ${({ theme }) => theme.palette.primary.main};
  padding: ${({ theme }) => theme.spacing(1)};
  background-color: ${({ theme }) => theme.palette.background.paper};
`;

1. Dengan asumsi makeStyles ada di v5, haruskah kita mengharapkan kinerja yang tercapai jika kita menggunakan penyedia tema styled-components dan penyedia tema UI Material untuk basis kode yang besar?

Senang menggunakan Material UI, terima kasih atas semua kerja kerasnya!

@egilsster

1. Ya, baik dari @material-ui/styles atau react-jss, akan dilihat.
2. Ya https://material-ui.com/guides/interoperability/#theme ,

const StyledContainer = styled.div`
  ${({ theme }) => `
  color: ${theme.palette.primary.main};
  padding: ${theme.spacing(1)};
  background-color: ${theme.palette.background.paper};
  `}
`;

1. Masalah utama adalah 1. overhead konfigurasi, biaya satu kali, 2. memuat dua runtime CSS-in-JS, yang memiliki ~15 kB gzip overhead, biaya yang serupa, untuk mengatakan, termasuk Sentry: https://bundlephobia.com /result?p=@sentry/browser.

Terima kasih atas balasan cepat, sangat dihargai.

1. Ya material-ui.com/guides/interoperability/#theme

Ini cukup keren. Beberapa pekerjaan di sekitar perkakas mungkin akan mengikuti ini, proyek yang saya migrasikan tidak menggunakan TS tetapi VSCode/server bahasa tampaknya tidak tahu apa theme dalam kasus ini dan saya kehilangan styled-components penyorotan sintaks juga.

Terima kasih kembali, akan terus mengikuti perkembangan ini.

@olivietassinari jika ada migrasi ke komponen gaya, apakah itu berarti kita tidak bisa lagi mengandalkan API CSS seperti <ListItem classes={{ selected: myCustomClassName}}> ?

@jedwards1211 classes API akan tetap ada.

Baik. Saya agak bingung bagaimana MUI akan menggunakan komponen gaya secara internal, karena komponen gaya hanya dapat menerapkan satu kelas ke elemen root.

const MyRoot = styled('div')`
  // some nice styles
`;

const MyAwesomeChild = styled('div')`
  // some nice styles
`;

export function AwesomeRoot(props) {
  return (
    <MyRoot className={props.classes?.root}>
      <MyAwesomeChild className={props.classes?.child}/>
      {props.children}
    </MyRoot>
  );
}

Apakah itu masuk akal @jedwards1211 ?

@yordis Saya tahu tampaknya sesederhana itu, tetapi bagaimana Anda memfaktorkan kembali penyeleksi senyawa seperti https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/Button/Button.js #L75 ?

Saya benar-benar tidak dapat memikirkan cara untuk mempertahankan perilaku yang ada ini dengan styled-components , sehingga dapat menyebabkan lebih banyak perubahan yang merusak daripada yang diharapkan orang.

  outlined: {
    '&$disabled': {
      border: `1px solid ${theme.palette.action.disabledBackground}`,
    },
  },

Kode yang ada dan penggantian kustom orang mungkin bergantung pada kekhususan CSS dalam beberapa kasus juga.

Mungkin ini? Saya tidak yakin untuk mengikuti karena ini terasa mendasar bagi saya, saya mungkin kehilangan beberapa konteks dan/atau info.

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

@yordis mungkin. Seperti yang saya katakan meskipun orang mungkin tidak memikirkan berapa banyak perubahan yang merusak yang akan terjadi pada pengguna, saya tidak berpikir contoh itu akan mencegah perubahan yang melanggar.

Maukah Anda berbagi contoh nyata, dan perubahan nyata yang berpotensi merusak?

Sulit untuk mengikuti Anda ketika Anda tidak berbagi kasus yang kuat. Berdasarkan pesan Anda, saya pikir Anda tidak sepenuhnya memahami topik ini, atau saya mungkin membuat penilaian yang salah. Tolong bantu saya untuk memahami, saya mungkin salah.

@oliviertasinari akankah penggantian tema masih berfungsi tanpa modifikasi di v5? Agar contoh penggantian berikut berfungsi, sepertinya MUI masih harus menerapkan nama kelas yang dihasilkan JSS selain nama kelas akar yang dihasilkan styled-components .

const theme = createMuiTheme({
  overrides: {
    MuiButton: {
      root: {
        '&$disabled': {
          color: myCustomColor,
        },
      },
    },
  },
});

@yordis setelah memikirkannya lebih lanjut, saya menyadari penyeleksi gabungan untuk gaya yang diteruskan melalui classes prop masih akan berfungsi, untungnya. Tidak yakin tentang gaya penggantian tema.

Saya merasa senang menggunakan kedua komponen gaya di atas MUI bersama dengan gaya MUI biasa menggunakan using style={object}.

Ambil halaman daftar hasil, yang berisi 50 kartu, masing-masing dengan carousel media, info, penangan klik, tombol, dll.

Menggunakan komponen bergaya menambahkan hampir setengah detik ke waktu render; dibandingkan dengan const useStyles = makeStyles atau style={object}.

Saya harus menerima hasil perencanaan peta jalan ini; tapi itu pasti akan mengacaukan rencana kami untuk adopsi UI jika itu tidak dapat ditimpa dengan sesuatu yang lain sepenuhnya top-down.

@Icehunter dapatkah Anda memposting hasil dan proyek sampel Anda secara online agar orang dapat melihatnya?

@Icehunter dapatkah Anda memposting hasil dan proyek sampel Anda secara online agar orang dapat melihatnya?

Proyek sampel akan sulit karena akan menampung kode kepemilikan. Saya akan segera memposting gambar yang dirender dan bagian hasil pengaturan waktu pada tab kinerja.

Ambil halaman daftar hasil, yang berisi 50 kartu, masing-masing dengan carousel media, info, penangan klik, tombol, dll.

@Icehunter apakah Anda mengirim alat peraga ke gaya itu? apakah itu 50 kartu atau 500 kartu jumlah kelas yang dihasilkan harus sama. sepertinya contoh spesifik Anda berisi kode kepemilikan yang tidak dapat dibagikan tetapi apakah mungkin bagi Anda untuk mereproduksi masalah ini dengan kode yang dapat Anda bagikan?

styled() / styled.div API menambahkan overhead ke rendering elemen _setiap_, jadi bahkan dengan caching nama kelas itu bisa lebih lambat. Dengan makeStyles Anda dapat melampirkan sekelompok gaya sekali dan kemudian hanya menerapkan nama kelas secara manual, yang seringkali jauh lebih cepat.

Saya mengumpulkan contoh CodeSandbox untuk menggambarkan bahwa solusi yang mengandalkan komponen bergaya styled bisa 3-4x lebih lambat daripada MUI makeStyles :

styled API bagus untuk kenyamanan, tapi saya menggemakan sentimen @Icehunter bahwa itu bisa menjadi masalah kinerja ketika banyak digunakan dalam daftar/tabel. Sangat menyenangkan memiliki makeStyles sebagai cadangan.

@schnerd Terima kasih telah menyusun contoh-contoh ini, ini menggambarkan kekhawatiran dengan sangat baik. Sama seperti catatan tambahan yang berpikir mengawali posting dengan, "Tidak sulit untuk melihat ..." dapat dianggap sebagai semacam merendahkan dan tidak benar-benar menambah serangkaian contoh yang sangat baik.

@tuxracer permintaan maaf – diperbarui.

@Icehunter Saya tidak mengerti apa yang Anda maksud dengan itu, Anda menggunakan gaya umum dengan SC atau JSS?

@Icehunter Saya tidak mengerti apa yang Anda maksud dengan itu, Anda menggunakan gaya umum dengan SC atau JSS?

Keduanya sebenarnya. Kami akhirnya menggunakan makeStyles tetapi entah itu atau menggunakan styled={object} memberi kami hasil kinerja yang sama.

Kami sedang dalam proses migrasi untuk mendapatkan kinerja yang lebih baik di seluruh pustaka komponen dan situs utama.

Stack bijaksana itu ditulis di nextjs.

Untuk memperjelas (edit):

Saya telah menggunakan SC sebagaimana dimaksud, membungkus komponen mui. Ternyata sangat lambat.

Kemudian saya menggunakan komponen mui menggunakan makeStyles dan/atau style={object} dari pengaturan file bersama, dan lokal (cascading simulasi). Jauh lebih cepat.

Saya tidak ingin memblokir ide ini sama sekali; tetapi jika itu default; maka harus ada cara untuk menimpa secara global top-down pilihan default dan dep menyuntikkan Anda sendiri.

Mungkin ini? Saya tidak yakin untuk mengikuti karena ini terasa mendasar bagi saya, saya mungkin kehilangan beberapa konteks dan/atau info.

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

Mungkin saya terlambat untuk game ini. Tapi saya pikir @jedwards1211 sedang mencari cara bagaimana ini dapat diekspresikan dengan SC: https://codesandbox.io/s/magical-snow-5bzd8

Saya sendiri memiliki ini di beberapa tempat. Jadi akan lebih baik jika ini mudah untuk bermigrasi ke v5 ketika hari itu tiba

Sebenarnya saya tidak yakin bagaimana sesuatu seperti ini akan bekerja menggunakan komponen gaya.

Misalnya, jika Material UI akan mendukung penggantian varian default Typography di masa mendatang, saya kira JSS lebih mudah daripada komponen gaya.

@heb-mm ada RFC terperinci di sini yang @olivietassinari menyebutkan utas ini pada 7 Maret.

Butuh waktu kurang dari satu menit untuk menggulir ke atas dan melihat penyebutannya.

Sunting: bagi mereka yang bertanya-tanya, heb-mm telah menghapus komentar mereka sekarang.

Saya mengumpulkan contoh CodeSandbox untuk menggambarkan bahwa solusi yang mengandalkan komponen gaya styled dapat 3-4x lebih lambat daripada MUI makeStyles :

@schnerd Saya telah memperbarui tolok ukur Anda untuk menyertakan inhouse Material-UI styled api yang seharusnya meniru styled-components . Saya terkejut melihat betapa sangat lambatnya dibandingkan dengan opsi lain. Lihat https://codesandbox.io/s/css-in-js-comparison-ljtjz?file=/src/App.js

Adakah yang tahu apakah @emotion/styled (yang pada dasarnya memiliki API yang sama dengan komponen gaya) akan sama lambatnya? Saya hanya ingin tahu apakah ada sesuatu tentang implementasinya yang mungkin lebih baik dioptimalkan.

Adakah yang tahu apakah @emotion/styled (yang pada dasarnya memiliki API yang sama dengan komponen gaya) akan sama lambatnya? Saya hanya ingin tahu apakah ada sesuatu tentang implementasinya yang mungkin lebih baik dioptimalkan.

https://codesandbox.io/s/css-in-js-comparison-sej1m

Tentang secepat komponen gaya. Masih tidak secepat makeStyles. Masalah yang saya lihat sebagian besar adalah pembuatan objek dan perbedaan caching/memoisasi objek.

Hmm, mungkin ini akan sedikit mengganggu rencana migrasi kita ke MUI. Kami saat ini beralih dari styled-components ke sistem penataan UI Material setelah mengalami banyak masalah dalam mengelola CSS, tema, dan kinerja kami. styled components pada awalnya baik-baik saja, kami membangun solusi tema kami sendiri di atasnya, tetapi ketika UI berkembang, begitu pula CSS. Kami menggunakan TypeScript, jadi fakta bahwa kami dapat dengan mudah memfaktorkan ulang objek JS alih-alih string CSS sebaris adalah nilai jual yang sangat besar. 😕.

Jadi saya cukup baru di Material UI dan juga baru saja melihat rilis alpha dari v5. @ldiego08 Anda berkata:

Kami saat ini beralih dari komponen gaya ke sistem penataan UI Material

Saya biasanya menggunakan komponen gaya saat bekerja dengan reaksi. Apa itu sistem penataan UI Material dan apa cara yang disarankan untuk menggunakan gaya dan CSS di UI Material ke depan? Saya membaca halaman ini dan tidak jelas bagi saya apakah Anda mendukung CSS-IN-JS atau tidak: https://material-ui.com/system/basics/. Saya biasanya lebih suka menulis CSS bukan dalam sintaks objek, dan saya menikmati manfaat menggunakan CSS-IN-JS, karena Anda bisa menggunakan "sintaks css normal", tetapi juga memiliki kekuatan JS.

Terima kasih atas bantuan apa pun untuk memulai!

Saya tidak tahu mengapa API komponen gaya saya begitu populer. Ini lebih lambat, Anda harus membungkus semuanya menjadi komponen daripada hanya menghasilkan nama kelas. Dan juga, ada apa dengan literal templat yang diberi tag? Kami tidak ingin menulis css dalam file css, karena jauh lebih baik untuk menulisnya dalam string javascript? :D Sintaks objek jauh lebih kuat dalam hal komposisi dan refactoring, dll. Bagi saya, fungsi css dan cx emosi biasa yang mengambil objek css dan mengembalikan nama kelas adalah API yang paling fleksibel dan kuat. Jadi cukup membuat nama kelas dengan emosi dan menggunakan API kelas sangat fleksibel dan kuat. Jadi saya tidak mengerti mengapa Anda memperdagangkan kinerja dan fleksibilitas untuk "API pengembang yang lebih nyaman" (bagi sebagian orang, bagi saya, ini adalah API yang mengerikan).

Saya tidak tahu mengapa API komponen gaya saya begitu populer. Ini lebih lambat, Anda harus membungkus semuanya menjadi komponen daripada hanya menghasilkan nama kelas. Dan juga, ada apa dengan literal templat yang diberi tag? Kami tidak ingin menulis css dalam file css, karena jauh lebih baik untuk menulisnya dalam string javascript? :D Sintaks objek jauh lebih kuat dalam hal komposisi dan refactoring, dll. Bagi saya, fungsi css dan cx emosi biasa yang mengambil objek css dan mengembalikan nama kelas adalah API yang paling fleksibel dan kuat. Jadi cukup membuat nama kelas dengan emosi dan menggunakan API kelas sangat fleksibel dan kuat. Jadi saya tidak mengerti mengapa Anda memperdagangkan kinerja dan fleksibilitas untuk "API pengembang yang lebih nyaman" (bagi sebagian orang, bagi saya, ini adalah API yang mengerikan).

Saya memiliki kekhawatiran yang sama :) mungkin ini sedikit memperjelas:
https://github.com/mui-org/material-ui/issues/6115#issuecomment -580449539

@martinjlowm Ya, kami berada di halaman yang sama :) Saya pikir cara paling cerdas untuk menggunakan tim UI materi adalah dengan menerapkan beberapa jenis solusi yang dapat dipasang dan tidak berpasangan dengan solusi css di js, membiarkan orang memilih apa yang akan digunakan dan simpan beberapa ukuran bundel seperti itu. Dan juga menjaga kelas dan membuat API MuiTheme, karena itulah bagian yang paling kuat darinya. Bagi saya, css di js adalah tentang gaya dinamis yang mudah berdasarkan status komponen, kepercayaan diri saat memfaktorkan ulang atau menghapus css atau seluruh komponen (di situlah pendekatan objek lebih unggul), kinerja (tidak mengunduh banyak gaya yang tidak digunakan dari sekelompok lembar gaya eksternal) , dll. Dan lagi, saya tidak mengerti mengapa orang suka menulis string dengan beberapa highlight editor. Maksud saya, Anda harus menggunakan ${} untuk mengakses props dari konteks. Untuk sesuatu yang lebih kompleks daripada mengatur elemen div latar belakang, pendekatan itu berantakan dan menurut saya tidak dapat dibaca. Saya tidak menyalahkannya, hanya mengatakan apa yang saya pikirkan dan mencoba membuktikan bahwa tidak semua pengembang menyukai komponen bergaya, dan bahkan jika mereka menyukainya, saya tidak melihat betapa bagusnya memperdagangkan kinerja dan fleksibilitas untuk itu. :)

@vdjurdjevic Memang, menggabungkan material-ui ke satu css dalam solusi js hampir merupakan resep yang dijamin untuk konflik ketika praktik css-in-js tak terhindarkan tumbuh ke arah yang berbeda.

Bagaimana dengan beberapa pola adaptor yang menerapkan gaya dengan penyedia css-in-js tertentu? Gaya itu sendiri harus didefinisikan dalam format yang konsisten dalam paket material-ui. Ini adalah penerapan gaya yang dilakukan secara berbeda oleh adaptor yang sesuai.

Sesuatu di sepanjang baris:

import {EmotionAdapter, StyledComponentAdapter, ThemeProvider} from "@material-ui/core/styles";
...
return 
    (<ThemeProvider theme={theme} adapter={EmotionAdapter}>
        ...
    </ThemeProvider>)

@vdjurdjevic Saya cukup setuju dengan pemikiran Anda tentang https://github.com/mui-org/material-ui/issues/6115#issuecomment -652762320. Anda mungkin menyukai ringkasan arah yang kami ambil yang baru-baru ini saya bagikan di https://github.com/mui-org/material-ui/issues/16947#issuecomment -653797178.

Saya tidak mengerti mengapa orang suka menulis string dengan beberapa sorotan editor

Beberapa alasan dari sudut pandang saya:

• Dekat dengan mengapa kita tidak menulis React.createElement('div', {}) .
• Orang-orang dengan pengalaman terbatas di web dev (mereka banyak) berjuang untuk mempelajari JavaScript API, rasanya lebih sederhana dengan sintaks CSS. Ambil contoh para desainer, tanyakan kepada orang-orang di tim Anda apa pendapat mereka tentang itu :).
• Tidak dapat menyalin dan menempel antara alat dev dan sumber (saya benci yang ini).

@olivietassinari Ok, ini adalah beberapa poin solid, saya setuju :) Tapi tetap saja, bagi saya (bukan desainer, bukan pemula, pengembang senior), komponen gaya dan literal templat yang diberi tag tidak akan pernah menjadi pilihan. Saya membaca ringkasan Anda untuk arah pengembangan lebih lanjut, dan saya senang mendengar bahwa mesin css akan menjadi opsional. Saya tidak keberatan komponen gaya sebagai default (jika itu yang disukai sebagian besar pengguna), selama saya bisa menggantinya. Dan sejujurnya, saya pikir saya akan tetap menggunakan JSS dengan v4 untuk proyek saya berikutnya, ia memiliki beberapa fitur yang bagus (seperti memperluas dan menulis plugin). Saya harus menulis plugin stylis agar emosi memiliki sesuatu yang serupa.

PS. Saya juga bukan penggemar JSX :) Ini cepat menjadi berantakan, Anda berakhir dengan kode panah dan untuk komponen yang harus membuat elemen dinamis, Anda tidak punya pilihan selain menggunakan createElement. Tidak mengatakan bahwa bekerja secara langsung dengan createElement lebih baik, hanya mengatakan bahwa JSX tidak ideal. Menurut saya, Flutter memiliki DX terbaik, semoga bisa menangani platform web dengan baik suatu hari nanti.

@olivietassinari Per pengujian kinerja berkelanjutan kami seperti yang tercantum di https://github.com/mui-org/material-ui/issues/6115#issuecomment -643398897 Saya hanya berharap tim material tidak hanya memilih komponen yang ditata karena populer. Ini lambat. Selalu begitu. Secara pribadi, menjadi seorang dev adalah hal yang Anda butuhkan untuk mempelajari hal-hal seperti notasi JS dari CSS.

Itu bagian dari pekerjaan.

Membuat hidup devs lebih mudah adalah bagian dari pekerjaan kami sebagai pengelola paket (untuk proyek saya sendiri tempat saya berbicara) tetapi ada batas antara membuatnya mudah dan membuatnya berkinerja.

Itu sebabnya saya hanya menggunakan makeStyles dan selalu menggunakannya sejak diperkenalkan.

Arsitek tim terakhir saya tidak mau mendengarkan dan terus maju dengan komponen bergaya dan sekarang situsnya lambat. Saya beralih ke makeStyles di cabang uji dan menghemat 50% (10 detik) pada TTI di perangkat seluler, tetapi seperti yang Anda katakan di komentar itu, notasi JS tidak diketahui oleh semua orang sehingga tidak diterima.

Bahan internal dapat memilih apa pun yang diinginkannya tetapi tolong buat itu berkinerja secara default.

[Pertanyaan Dipindahkan ke StackOverflow.]

@haysclark Silakan gunakan StackOverflow untuk pertanyaan dukungan daripada menempelkannya di RFC.

@haysclark Silakan gunakan StackOverflow untuk pertanyaan dukungan daripada menempelkannya di RFC.

@mbrookes Terima kasih atas perhatiannya!

Adakah yang tahu apakah @emotion/styled (yang pada dasarnya memiliki API yang sama dengan komponen gaya) akan sama lambatnya? Saya hanya ingin tahu apakah ada sesuatu tentang implementasinya yang mungkin lebih baik dioptimalkan.

https://codesandbox.io/s/css-in-js-comparison-sej1m

Tentang secepat komponen gaya. Masih tidak secepat makeStyles. Masalah yang saya lihat sebagian besar adalah pembuatan objek dan perbedaan caching/memoisasi objek.

Saya bertanya-tanya apa kinerja komponen Kotak akan dibandingkan dengan profil Anda, dan menambahkan Kotak Chakra-UI untuk ukuran yang baik, dan hasilnya ... mengejutkan :P
https://codesandbox.io/s/css-in-js-comparison-forked-mg3gx?file=/src/App.js

@Nvveen sudahkah Anda mencoba Chakra-UI v1? Sudah ditulis ulang dan mudah-mudahan harus lebih baik. Ada juga emosi v11, meskipun masih dalam versi beta.

@Nvveen sudahkah Anda mencoba Chakra-UI v1? Sudah ditulis ulang dan mudah-mudahan harus lebih baik. Ada juga emosi v11, meskipun masih dalam versi beta.

Baru saja mencobanya dengan RC terbaru, tetapi tidak ada perbedaan yang mencolok; masih sekitar 1,5x hingga 2x lebih lambat dari SC biasa. Pertanyaan terbesar bagi saya adalah mengapa Kotak MUI sangat lambat.

@Nvveen sudahkah Anda mencoba Chakra-UI v1? Sudah ditulis ulang dan mudah-mudahan harus lebih baik. Ada juga emosi v11, meskipun masih dalam versi beta.

Baru saja mencobanya dengan RC terbaru, tetapi tidak ada perbedaan yang mencolok; masih sekitar 1,5x hingga 2x lebih lambat dari SC biasa. Pertanyaan terbesar bagi saya adalah mengapa Kotak MUI sangat lambat.

Ini menggunakan Jss. SC setidaknya agak lebih baik.

Di mesin saya, urutan kasus uji yang dijalankan memengaruhi hasil. Membandingkan

1. Kotak pertama https://codesandbox.io/s/css-in-js-comparison-forked-tqlg1?file=/src/App.js
   

2. Kotak terakhir https://codesandbox.io/s/css-in-js-comparison-forked-js6th?file=/src/App.js
   

Pengumpulan sampah @olivietassinari dan jit dari v8 adalah penyebabnya. Lebih baik uji coba berjalan terisolasi/terpisah kok. Tes selanjutnya memiliki jit yang lebih baik, tetapi sesekali itu akan memicu pengumpulan sampah.

Sepertinya Emotion, SC, dan Chakra semuanya mendekati perf maksimum teoritis ketika setiap komponen kecil memiliki gayanya sendiri untuk dipasang, dengan gaya MUI yang belum sepenuhnya dioptimalkan. Sepertinya satu-satunya cara untuk mendapatkan kinerja yang lebih baik dari itu adalah dengan memiliki satu lembar gaya untuk seluruh pohon komponen seperti pada makeStyles/CSS murni. Saya kira tambahan 30 ms untuk emosi, SC dll. adalah overhead yang tidak dapat dihindari dari setiap komponen kecil yang harus memastikan gayanya dipasang.

@jedwards1211 jika ini tentang menjaga dx, Atlassian membuat lib yang mengkompilasinya ke css, yang disebut dikompilasi