Material-ui: Gunakan komponen gaya di semua demo

@oliviertassinari what is the exactly the tasks in hand? @oliviertasinari apa sebenarnya tugas yang ada?

Here is what I understand, Inilah yang saya pahami,

1. Run the docs website Jalankan situs web dokumen
2. Find all the example source code that uses material-ui/styles Temukan semua contoh kode sumber yang menggunakan material-ui/styles
3. Replace them with styled-components Ganti dengan styled-components

Is this correct? Apakah ini benar?

@yordis I think that the timing is going to be key in this transition. @yordis Saya pikir waktu akan menjadi kunci dalam transisi ini. I would imagine the following steps: Saya akan membayangkan langkah-langkah berikut:

1. We replace the usage of @material-ui/styles in the demos with the Box component, where possible. Kami mengganti penggunaan @material-ui/styles dalam demo dengan komponen Box, jika memungkinkan. Moving #16858 at the same time would help. Memindahkan #16858 pada saat yang sama akan membantu. This can be done in the near future. Ini bisa dilakukan dalam waktu dekat.
2. We solve #15561, we migrate more demos away from @material-ui/styles to use the system props. Kami memecahkan #15561, kami memigrasikan lebih banyak demo dari @material-ui/styles untuk menggunakan alat peraga sistem. The sooner we solve this, the better. Semakin cepat kita menyelesaikan ini, semakin baik.
3. We update the customization demos to use styled-components, leveraging the global Mui class names. Kami memperbarui demo penyesuaian untuk menggunakan komponen gaya, memanfaatkan nama kelas Mui global. We might need to work on some helpers to make accessing the theme values easier. Kita mungkin perlu bekerja pada beberapa pembantu untuk mempermudah mengakses nilai tema.
4. We solve #6115, we migrate the last usages of @material-ui/styles to styled-components. Kami memecahkan #6115, kami memigrasikan penggunaan terakhir @material-ui/styles ke komponen gaya. This is a task for v5, I think that we can start it Q1 2020 in the v5 alpha/beta versions. Ini adalah tugas untuk v5, saya pikir kita dapat memulainya pada Q1 2020 dalam versi alpha/beta v5.

@olivietassinari Saya ingin tahu, dan saya minta maaf jika ini diulang: mengapa tidak menyimpan @material-ui/styles sebagai pembungkus atau abstraksi untuk styled-components ?

@ConAntonakos it's an option. @ConAntonakos itu pilihan. It could help if we need to extend/normalize some of the features of styled-components. Ini bisa membantu jika kita perlu memperluas/menormalkan beberapa fitur komponen gaya.

@oliviertassinari apakah kita punya daftar yang tersisa?

@yordis We haven't done many efforts in this direction yet. @yordis Kami belum melakukan banyak upaya ke arah ini. However, there is a probability that it will require breaking changes, v5 is planned for around Q4 2020. I think that we should explore a partial deployment strategy for developers that want to leverage it sooner. Namun, ada kemungkinan bahwa itu akan memerlukan perubahan yang melanggar, v5 direncanakan untuk sekitar Q4 2020. Saya pikir kita harus mengeksplorasi strategi penerapan parsial untuk pengembang yang ingin memanfaatkannya lebih cepat. Now, this effort has to be balanced with the other priorities, like the support of new advanced components (free and paid) or the release of an unstyled version of the library to increase our audience reach (with different themes, eg iOS style). Sekarang, upaya ini harus diimbangi dengan prioritas lain, seperti dukungan komponen lanjutan baru (gratis dan berbayar) atau rilis versi perpustakaan yang tidak bergaya untuk meningkatkan jangkauan audiens kami (dengan tema berbeda, misalnya gaya iOS). The good news is that we will likely grow the team in the coming months, enabling us to move faster. Kabar baiknya adalah kami kemungkinan akan mengembangkan tim dalam beberapa bulan mendatang, memungkinkan kami untuk bergerak lebih cepat.

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles ). Saya membayangkan Anda sudah menggunakan komponen-gaya di atas Material-UI hari ini seperti yang dilakukan banyak pengembang lain (dan bukan @material-ui/styles ). What are the top pain points you hope to address with this migration? Apa masalah utama yang ingin Anda atasi dengan migrasi ini?

From a product perspective, our incentive is about: smaller bundle size, better performance, steaming support, fewer bugs, CSS template strings support, larger community, enables to use the system props in the core components, allow true dynamic themes and props support, better docs. Dari perspektif produk, insentif kami adalah tentang: ukuran bundel yang lebih kecil, kinerja yang lebih baik, dukungan steaming, lebih sedikit bug, dukungan string template CSS, komunitas yang lebih besar , memungkinkan untuk menggunakan alat peraga sistem dalam komponen inti, memungkinkan tema dinamis yang sebenarnya dan dukungan alat peraga, dokumen yang lebih baik.

However, there is a high probability that it will require breaking changes, Namun, ada kemungkinan besar bahwa itu akan membutuhkan perubahan yang melanggar,

Yeah, I tried to change some examples, but they require some integration with the theme provider, so we may need to inject material/style theme provider and styled-component theme provider I am assuming. Ya, saya mencoba mengubah beberapa contoh, tetapi mereka memerlukan beberapa integrasi dengan penyedia tema, jadi kami mungkin perlu menyuntikkan penyedia tema material/style dan penyedia tema styled-component yang saya asumsikan.

v5 is planned for around Q4 2020. v5 direncanakan untuk sekitar Q4 2020.

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? Itu cukup jauh, apakah lebih baik untuk menyematkan masalah yang berbeda untuk visibilitas pada apa yang menjadi prioritas saat ini?

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles). Saya membayangkan Anda sudah menggunakan komponen-gaya di atas Material-UI hari ini seperti yang dilakukan banyak pengembang lain (dan bukan @material-ui/styles).

Actually, I am quite happy with @material-ui/styles and I am not using styled-components when I use Material UI (I would remove withStyles since I don't want to rely on programmer discipline 😉 , but I understand legacy software may no have hooks still )🤷‍♂️ Sebenarnya, saya cukup senang dengan @material-ui/styles dan saya tidak menggunakan styled-components ketika saya menggunakan Material UI (saya akan menghapus withStyles karena saya tidak ingin bergantung pada disiplin programmer , tapi saya mengerti perangkat lunak lawas mungkin masih belum memiliki kait )🤷‍♂️

What are the top pain points you hope to address with this migration? Apa masalah utama yang ingin Anda atasi dengan migrasi ini?

I am trying to help with the migration, personally, no pain points. Saya mencoba membantu dengan migrasi, secara pribadi, tidak ada masalah. Unless you take into consideration that as an ecosystem, I have to maintain two ways to develop something, but meh, personally, it is okay for me. Kecuali jika Anda mempertimbangkan bahwa sebagai ekosistem, saya harus mempertahankan dua cara untuk mengembangkan sesuatu, tetapi meh, secara pribadi, tidak apa-apa bagi saya.

Maybe styled-components fixes some interoperability with NextJS and Gatsby since the last time I tried was hard to make Mui work with those tools because of the SSR and styles (I am not sure if still painful) and most libraries using styled-components work out of the box. Mungkin styled-components memperbaiki beberapa interoperabilitas dengan NextJS dan Gatsby karena terakhir kali saya mencoba sulit untuk membuat Mui bekerja dengan alat-alat itu karena SSR dan gaya (saya tidak yakin apakah masih menyakitkan) dan sebagian besar perpustakaan menggunakan styled-components bekerja di luar kotak.

Let me know how I could help, like I said, I was using the pinned issues to find the prioritization of the Org Beri tahu saya bagaimana saya bisa membantu, seperti yang saya katakan, saya menggunakan masalah yang disematkan untuk menemukan prioritas Organisasi

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? Itu cukup jauh, apakah lebih baik untuk menyematkan masalah yang berbeda untuk visibilitas pada apa yang menjadi prioritas saat ini?

It depends on the time horizon you are interested in. You can follow the issue with the label important , the roadmap page on the documentation and the monthly blog product updates. Itu tergantung pada cakrawala waktu yang Anda minati. Anda dapat mengikuti masalah dengan label important , halaman peta jalan pada dokumentasi dan pembaruan produk blog bulanan.

I don't fully understand this point. Saya tidak sepenuhnya memahami poin ini. Why not using styled-components when using Material-UI (today)? Mengapa tidak menggunakan komponen gaya saat menggunakan Material-UI (hari ini)? We had 1/3 of our users going down this path when we did our last survey, 6 months ago. Kami memiliki 1/3 pengguna kami menempuh jalur ini ketika kami melakukan survei terakhir kami, 6 bulan yang lalu.

I don't fully understand this point. Saya tidak sepenuhnya memahami poin ini. Why not using styled-components when using Material-UI (today)? Mengapa tidak menggunakan komponen gaya saat menggunakan Material-UI (hari ini)?

@material-ui/styles works like a champ so far, no reason to migrate everything 😄 so I am one of those out of 3 that don't use it together today. @material-ui/styles bekerja seperti jagoan sejauh ini, tidak ada alasan untuk memigrasikan semuanya jadi saya salah satu dari 3 yang tidak menggunakannya bersama hari ini.

Thank you for the info about prioritization. Terima kasih atas info tentang prioritas.

@yordis btw, my answer was made under the assumption you were following up on the main styled-components issue. @yordis btw, jawaban saya dibuat dengan asumsi Anda menindaklanjuti masalah komponen gaya utama. I haven't realized we were on the documentation one. Saya belum menyadari bahwa kami berada di bagian dokumentasi.

@oliviertassinari do you have any suggestions about the issue with theme context? @oliviertasinari apakah Anda punya saran tentang masalah dengan konteks tema?

I tried to use props.theme inside an styled-components but didn't work, I am not sure if you have a suggestion for it, but I think we will require to add styled-components theme provider as well. Saya mencoba menggunakan props.theme di dalam styled-components tetapi tidak berhasil, saya tidak yakin apakah Anda memiliki saran untuk itu, tetapi saya pikir kami perlu menambahkan styled-components penyedia tema juga.

Hey @oliviertassinari! Hai @olivietassinari! Are you looking for PR's that convert the existing customization demos to use styled-components as part of this issue? Apakah Anda mencari PR yang mengonversi demo penyesuaian yang ada untuk menggunakan komponen bergaya sebagai bagian dari masalah ini?

I dont think styled-components is a good styling solution. Saya tidak berpikir styled-components adalah solusi penataan yang baik. current solution looks much much more readable, appealing, accessible and cleaner than styled. solusi saat ini terlihat jauh lebih mudah dibaca, menarik, dapat diakses, dan lebih bersih daripada bergaya. i dont see any good reason to migrate. saya tidak melihat alasan bagus untuk bermigrasi.

I dont think styled-components is a good styling solution. Saya tidak berpikir styled-components adalah solusi penataan yang baik. current solution looks much much more readable, appealing, accessible and cleaner than styled. solusi saat ini terlihat jauh lebih mudah dibaca, menarik, dapat diakses, dan lebih bersih daripada bergaya. i dont see any good reason to migrate. saya tidak melihat alasan bagus untuk bermigrasi.

And get almost fully typed. Dan dapatkan hampir sepenuhnya diketik. Don't see any reason to migrate +1 Tidak melihat alasan apa pun untuk bermigrasi +1

The link you've posted, that should show growing interest to styled-components, recently started showing a downward trend: Tautan yang Anda poskan, yang seharusnya menunjukkan minat yang meningkat pada komponen bergaya, baru-baru ini mulai menunjukkan tren menurun:

I feel that narrowing down a styling solution to a single library is going to give us the exact same problem as we have today. Saya merasa bahwa mempersempit solusi penataan ke satu perpustakaan akan memberi kita masalah yang sama persis seperti yang kita miliki saat ini.

What about integration with zero-runtime libraries such as linaria ? Bagaimana dengan integrasi dengan library zero-runtime seperti linaria ? This was suggested as being looked at in May 2019 Update . Ini disarankan seperti yang dilihat pada Pembaruan Mei 2019 .

So far it only recovered to pre-v5-hype. Sejauh ini hanya pulih ke pra-v5-hype. Let's see how the updated data point for January till now looks. Mari kita lihat bagaimana tampilan titik data yang diperbarui untuk bulan Januari hingga sekarang.

@TheHolyWaffle Don't trust rank2traffic.com too much, data hasn't been very reliable nor up-to-date, its main advantage was the overall trend over 10 years (before it was made paid). @TheHolyWaffle Jangan terlalu percaya rank2traffic.com, data belum terlalu andal atau mutakhir, keuntungan utamanya adalah tren keseluruhan selama 10 tahun (sebelum dibuat berbayar). For a shorter time window, so 6 months, prefer https://www.similarweb.com/ as more reliable. Untuk jangka waktu yang lebih singkat, jadi 6 bulan, pilih https://www.similarweb.com/ karena lebih dapat diandalkan.
Also take into account that once people know the API, they come back much frequently to the documentation. Juga pertimbangkan bahwa begitu orang mengetahui API, mereka akan sering kembali ke dokumentasi.

I dont think styled-components is a good styling solution. Saya tidak berpikir styled-components adalah solusi penataan yang baik. current solution looks much much more readable, appealing, accessible and cleaner than styled. solusi saat ini terlihat jauh lebih mudah dibaca, menarik, dapat diakses, dan lebih bersih daripada bergaya. i dont see any good reason to migrate. saya tidak melihat alasan bagus untuk bermigrasi.

And get almost fully typed. Dan dapatkan hampir sepenuhnya diketik. Don't see any reason to migrate +1 Tidak melihat alasan apa pun untuk bermigrasi +1

+1 styles is the main reason we're migrating to Material UI and moving away from styled components. +1 styles adalah alasan utama kami bermigrasi ke UI Material dan beralih dari komponen bergaya. It's too much CSS and refactoring it has proven to be a huge burden for us. Terlalu banyak CSS dan refactoring telah terbukti menjadi beban besar bagi kami.

Hi! Hai! First of all, thank you for providing a great component library, best one I've used so far. Pertama-tama, terima kasih telah menyediakan pustaka komponen yang hebat, yang terbaik yang pernah saya gunakan sejauh ini. Our teams have written hundreds of thousands of lines of code using the components and methodology you created and once developers learn the basics of using classes , how to write the styles etc., it's a breeze to work with even on a massive enterprise scale type of codebase. Tim kami telah menulis ratusan ribu baris kode menggunakan komponen dan metodologi yang Anda buat dan setelah pengembang mempelajari dasar-dasar penggunaan classes , cara menulis gaya, dll., bekerja dengan sangat mudah bahkan di jenis basis kode skala perusahaan besar.

I'm not sure if that's the most common use of your library, but I suppose you are aware that many teams build their component libraries on top of Material UI, and so any components and decision you make also trickle down to those libraries. Saya tidak yakin apakah itu penggunaan paling umum dari perpustakaan Anda, tetapi saya kira Anda menyadari bahwa banyak tim membangun perpustakaan komponen mereka di atas Material UI, sehingga setiap komponen dan keputusan yang Anda buat juga mengalir ke perpustakaan tersebut. On our end we've been very happy with both performance and APIs so far. Di pihak kami, kami sangat senang dengan kinerja dan API sejauh ini.

I've been following recent development in the library and to be honest, I'm having trouble understanding some of the decisions and worried how that will affect our teams, and what's overall the benefit of this move would be, as opposed to for example forking MUI. Saya telah mengikuti perkembangan terbaru di perpustakaan dan sejujurnya, saya mengalami kesulitan memahami beberapa keputusan dan khawatir bagaimana hal itu akan mempengaruhi tim kami, dan apa manfaat keseluruhan dari langkah ini, sebagai lawan misalnya garpu MUI. Others have voiced their concern about move to styled components so I'll focus on the other one for me - the Box component. Orang lain telah menyuarakan keprihatinan mereka tentang pindah ke komponen gaya jadi saya akan fokus pada yang lain untuk saya - komponen Kotak.

I understand the utility of a Box component - to make it possible to use theme variables etc. in prop values, however the API and the consequences of using this component disqualify it from something I could recommend to our teams. Saya memahami kegunaan komponen Box - untuk memungkinkan penggunaan variabel tema dll. dalam nilai prop, namun API dan konsekuensi dari penggunaan komponen ini mendiskualifikasinya dari sesuatu yang dapat saya rekomendasikan kepada tim kami.

First , it has a cryptic API for no reason I can discern (unless saving a few bytes is that reason): Instead of writing <Box margin={3} /> , it would be <Box m={3} /> . Pertama , ia memiliki API samar tanpa alasan yang dapat saya pahami (kecuali menyimpan beberapa byte adalah alasan itu): Alih-alih menulis <Box margin={3} /> , itu akan menjadi <Box m={3} /> .

Abbreviations like that seem needless, make things potentially ambigious, and introdue a new learning curve to developers, a mapping of abbreviations to actual properties they now need to memorize: "Is applying color done using c or color ?", "Is background a b , or bg , or background , or was b a border ?" Singkatan seperti itu tampaknya tidak perlu, membuat hal-hal berpotensi ambigu, dan memperkenalkan kurva pembelajaran baru kepada pengembang, pemetaan singkatan ke properti aktual yang sekarang perlu mereka ingat: "Apakah menerapkan color selesai menggunakan c atau color ?", "Apakah background b , atau bg , atau background , atau b border ?" "Is background-size abbreviated as bs ?" "Apakah background-size disingkat bs ?"

Second , components abstract most commonly recurring UI patterns, and create APIs that provide means of customizing those patterns to the extent that the design system permits. Kedua , komponen mengabstraksi pola UI yang paling sering berulang, dan membuat API yang menyediakan cara untuk menyesuaikan pola tersebut sejauh yang diizinkan oleh sistem desain. This manifests in creating props like gutterBottom on Typography , or dense on ListItem - as opposed to accepting just about any padding or margin. Ini bermanifestasi dalam membuat alat peraga seperti gutterBottom pada Typography , atau dense pada ListItem - sebagai lawan untuk menerima hampir semua padding atau margin. I feel like introducing Box to large extent undermines this effort and introduces a tool that will make a mess out of any attempt to follow a design system unless we define some very nitpicky ways that Box component can be used for and spend effort in code reviews to make sure the all the values in used Box props aren't beyond the accepted list. Saya merasa seperti memperkenalkan Box untuk sebagian besar merusak upaya ini dan memperkenalkan alat yang akan mengacaukan upaya apa pun untuk mengikuti sistem desain kecuali jika kita mendefinisikan beberapa cara yang sangat rumit yang dapat digunakan dan dihabiskan komponen Box upaya dalam tinjauan kode untuk memastikan semua nilai dalam alat peraga Kotak yang digunakan tidak melebihi daftar yang diterima. And at that point, the way to "automate" this would be to create a component that restricts the options, and we're backt to square one. Dan pada saat itu, cara untuk "mengotomatiskan" ini adalah dengan membuat komponen yang membatasi opsi, dan kita kembali ke awal. To give an example, why would using Box mb={2} to achieve margin under Typography be okay, but Box mb={6} not? Sebagai contoh, mengapa menggunakan Box mb={2} untuk mencapai margin di bawah Tipografi boleh saja, tetapi Box mb={6} tidak? This concern doesn't exist when we can rely on props to limit the options. Kekhawatiran ini tidak ada ketika kita dapat mengandalkan alat peraga untuk membatasi pilihan.

Third concern, or rather a question I have. Kekhawatiran ketiga , atau lebih tepatnya pertanyaan yang saya miliki. Since the Box component is potentially a quick way to build certain functionality, it would be also used by libraries built on top of MUI. Karena komponen Box berpotensi sebagai cara cepat untuk membangun fungsionalitas tertentu, komponen ini juga akan digunakan oleh perpustakaan yang dibangun di atas MUI. How would one override the styles of Box components used within another component? Bagaimana cara mengganti gaya komponen Box yang digunakan dalam komponen lain? As an example. Sebagai contoh. If we built ListItem using Box under the hood, would we need to introduce BoxProps={{ padding: 2 }} , or accept also dense prop based on which we write logic to apply a padding prop to a particular Box, or still something else? Jika kita membangun ListItem menggunakan Box di bawah tenda, apakah kita perlu memperkenalkan BoxProps={{ padding: 2 }} , atau menerima juga dense prop berdasarkan logika yang kita tulis untuk menerapkan prop padding ke Kotak tertentu, atau masih sesuatu yang lain?

I'm not sure if that's the most common use of your library, but I suppose you are aware that many teams build their component libraries on top of Material UI , and so any components and decision you make also trickle down to those libraries. Saya tidak yakin apakah itu penggunaan paling umum dari perpustakaan Anda, tetapi saya kira Anda menyadari bahwa banyak tim membangun perpustakaan komponen mereka di atas Material UI , sehingga setiap komponen dan keputusan yang Anda buat juga mengalir ke perpustakaan tersebut. On our end we've been very happy with both performance and APIs so far. Di pihak kami, kami sangat senang dengan kinerja dan API sejauh ini.

@maciej-gurban This use case is an important one for us. @maciej-gurban Kasus penggunaan ini penting bagi kami. Our incentives are aligned to significantly improve it. Insentif kami diselaraskan untuk meningkatkannya secara signifikan. This is one of our objectives with v5. Ini adalah salah satu tujuan kami dengan v5.

For instance, we are investigating the feasibility to provide a design tool that could be put in the hands of designers (paid) and would output ready to use customized Material-UI components (MIT), corresponding documentation, Sketch & Figma kit. Misalnya, kami sedang menyelidiki kelayakan untuk menyediakan alat desain yang dapat diserahkan ke tangan desainer (berbayar) dan akan menghasilkan komponen Material-UI (MIT) yang siap pakai, dokumentasi yang sesuai, kit Sketch & Figma. Basically, all we have been going it for Material Design but scaling it 🚀. Pada dasarnya, semua yang kami lakukan untuk Desain Material tetapi menskalakannya .
The end goal here would be to free the time of a couple of front-end developers in each company. Tujuan akhirnya di sini adalah untuk membebaskan waktu beberapa pengembang front-end di setiap perusahaan. Why have front-end developers build a custom design system when it can be done by your own designers + Material-UI at a fraction of the cost? Mengapa pengembang front-end membangun sistem desain khusus ketika itu dapat dilakukan oleh desainer Anda sendiri + Material-UI dengan biaya yang lebih murah? + reduce risk and have your front-end developers spend time where they make the most differences: working on the product. + kurangi risiko dan minta pengembang front-end Anda menghabiskan waktu di mana mereka membuat perbedaan terbesar: mengerjakan produk.

I'm having trouble understanding some of the decisions and worried how that will affect our teams Saya mengalami kesulitan memahami beberapa keputusan dan khawatir bagaimana hal itu akan memengaruhi tim kami

If you could list them, it would be awesome. Jika Anda bisa membuat daftar mereka, itu akan luar biasa.

Others have voiced their concern about move to styled components Yang lain telah menyuarakan keprihatinan mereka tentang pindah ke komponen bergaya

What's your concern with such a shift? Apa kekhawatiran Anda dengan pergeseran seperti itu? Our objective on the styling side has a couple of layer: Tujuan kami di sisi penataan memiliki beberapa lapisan:

1. Unstyled component, expose the same existing components but without any styles. Komponen tanpa gaya, ekspos komponen yang sudah ada tetapi tanpa gaya apa pun. Keep the same classes API (first seen in jQuery-UI), provide default hardcoded values for each of the classes (global class names). Pertahankan classes API yang sama (pertama kali terlihat di jQuery-UI), berikan nilai hardcode default untuk setiap kelas (nama kelas global). The objective behind this shift answer to a couple of incentives. Tujuan di balik perubahan ini menjawab beberapa insentif. First, it's to dismiss a fear our users have, same to CRA eject mode, you won't use it but it feels safe to be present. Pertama, untuk menghilangkan ketakutan yang dimiliki pengguna kami, sama dengan mode eject CRA, Anda tidak akan menggunakannya tetapi merasa aman untuk hadir. Second, it's required to be able to build the paid design tool. Kedua, diperlukan untuk dapat membangun alat desain berbayar. Third, it's required for the next layer Ketiga, itu diperlukan untuk lapisan berikutnya
2. Multiple style engines. Beberapa gaya mesin. The community is fragmented between different styling approaches. Komunitas terfragmentasi antara pendekatan styling yang berbeda. By order of popularity: styled-components, plain CSS, CSS modules, emotion, JSS, utility first classes. Berdasarkan urutan popularitas: komponen gaya, CSS biasa, modul CSS, emosi, JSS, kelas utilitas pertama. It still feels like we didn't find the holy grail for styling. Rasanya masih belum menemukan cawan suci untuk penataan. And until we do, better not bet too much on any styling solution. Dan sampai kita melakukannya, sebaiknya jangan terlalu banyak bertaruh pada solusi penataan gaya apa pun. So, have styled-components has the default, but allow developers to switch engine, stay on JSS if they are happy too. Jadi, memiliki komponen gaya memiliki default, tetapi izinkan pengembang untuk beralih mesin, tetap di JSS jika mereka juga senang.
3. Baseline theme. Tema dasar. Something less opinionated than the current default Material Desing Theme, but using the same theme's specification. Sesuatu yang kurang berpendirian daripada Tema Material Desing default saat ini, tetapi menggunakan spesifikasi tema yang sama.
4. A couple of different themes on top of the baseline. Beberapa tema berbeda di atas baseline. One for marketing pages, One for the Chinese market (close to the Gmail equivalent of China). Satu untuk halaman pemasaran, Satu untuk pasar China (mendekati Gmail yang setara dengan China).

I'll focus on the other one for me - the Box component. Saya akan fokus pada yang lain untuk saya - komponen Kotak.

Yeah, I can hear you! Ya, aku bisa mendengarmu! I have been working with @gregberge in the past. Saya telah bekerja dengan @gregberge di masa lalu. At some point, we have considered hiding all the className props on @doctolib 's design system. Pada titik tertentu, kami telah mempertimbangkan untuk menyembunyikan semua properti className pada sistem desain @doctolib . The interesting thought is that you can gain features (properties) in exchange of more constraints. Pemikiran yang menarik adalah Anda bisa mendapatkan fitur (properti) dengan imbalan lebih banyak kendala.

I wouldn't worry too much about this one. Saya tidak akan terlalu khawatir tentang yang satu ini. This can be resolved with a global option to limit the access to the "system"'s features or an eslint rule. Ini dapat diselesaikan dengan opsi global untuk membatasi akses ke fitur "sistem" atau aturan eslint.

The abbreviation on the Box component is confusing. Singkatan pada komponen Box membingungkan. Code is being read more than being written, so it's important to keep clear what the code is meaning. Kode lebih banyak dibaca daripada ditulis, jadi penting untuk memperjelas apa arti kode tersebut. Last day I found "Box py={2}" in our codebase and I'm totally confused. Hari terakhir saya menemukan "Box py={2}" di basis kode kami dan saya benar-benar bingung. After a search I figured out that means "paddingY". Setelah pencarian saya menemukan itu berarti "paddingY". Those abbreviation should not be encouraged especially non-css properties (I can guess pt means padding-top but not for py) Singkatan itu tidak boleh didorong terutama properti non-css (saya bisa menebak pt berarti padding-top tetapi tidak untuk py)

@oliviertassinari Thanks for your patience @olivietassinari Terima kasih atas kesabaran Anda

I'm having trouble understanding some of the decisions and worried how that will affect our teams Saya mengalami kesulitan memahami beberapa keputusan dan khawatir bagaimana hal itu akan memengaruhi tim kami

If you could list them, it would be awesome. Jika Anda bisa membuat daftar mereka, itu akan luar biasa.

I wouldn't want this to turn into a litany of things I disagree with, because ultimately you're the guys who maintain this library and our view of what makes sense will be shaped by our own needs which might and likely don't always align, and that's fine. Saya tidak ingin ini berubah menjadi serangkaian hal yang tidak saya setujui, karena pada akhirnya Andalah yang memelihara perpustakaan ini dan pandangan kami tentang apa yang masuk akal akan dibentuk oleh kebutuhan kami sendiri yang mungkin dan mungkin tidak selalu menyelaraskan, dan itu bagus. I'm not against introducing the means of using other styling solutions - in fact I think it's great as it will bring more users who were holding off because of their dislike for JSS, but there's also us - the already existing users of your library who are sold on your solution, and if possible, would like to avoid massive refactor. Saya tidak menentang memperkenalkan cara menggunakan solusi penataan gaya lain - sebenarnya saya pikir itu bagus karena akan membawa lebih banyak pengguna yang menunda karena ketidaksukaan mereka terhadap JSS, tetapi ada juga kami - pengguna perpustakaan Anda yang sudah ada yang dijual pada solusi Anda, dan jika mungkin, ingin menghindari refactor besar-besaran.

Even if you decide that "we still provide support for JSS", refactoring all demos and your components to styled components will force the teams using JSS to migrate to styled components. Bahkan jika Anda memutuskan bahwa "kami masih memberikan dukungan untuk JSS", memfaktorkan ulang semua demo dan komponen Anda ke komponen bergaya akan memaksa tim yang menggunakan JSS untuk bermigrasi ke komponen bergaya. "Why are we still using X, when MUI team moved to Y?" "Kenapa masih pakai X, padahal tim MUI pindah ke Y?" - will be one of the many questions in light of which it would be really hard not to agree with needing to make that migration sooner or later. - akan menjadi salah satu dari banyak pertanyaan yang akan sangat sulit untuk tidak setuju dengan kebutuhan untuk melakukan migrasi itu cepat atau lambat.

I can definitely empathize with wanting to reach a wider audience by using a styling solution that's more popular. Saya pasti dapat berempati dengan keinginan untuk menjangkau khalayak yang lebih luas dengan menggunakan solusi gaya yang lebih populer. However, I think it's worth considering that "popular" is not always "best" and that a move to a different tech needs onsideration not only of advantages and disadvantages of both solution, but the context in which we're making the decision. Namun, saya pikir perlu dipertimbangkan bahwa "populer" tidak selalu "terbaik" dan bahwa perpindahan ke teknologi yang berbeda membutuhkan pertimbangan tidak hanya keuntungan dan kerugian dari kedua solusi, tetapi konteks di mana kita membuat keputusan.

Starting fresh, looking merely at advantages of X over Y makes sense, but working on an already existing system we also need to consider the cost of switching over and domino effects this bring on downstream teams. Memulai dari awal, hanya melihat keunggulan X dibandingkan Y masuk akal, tetapi bekerja pada sistem yang sudah ada, kita juga perlu mempertimbangkan biaya peralihan dan efek domino yang ditimbulkan pada tim hilir. For this switch over to make sense the advantanges of the other solution need to outweight the cost of migrating over. Agar peralihan ini masuk akal, keuntungan dari solusi lain perlu melebihi biaya migrasi. It seems that for your team, that cost benefit analysis rules in favor of styled components, but from what I can tell looking at reactions at posts talking about styled components in your repo, your user base is far from the same conclusion. Tampaknya untuk tim Anda, analisis manfaat biaya itu mendukung komponen bergaya, tetapi dari apa yang saya tahu melihat reaksi di posting yang berbicara tentang komponen bergaya di repo Anda, basis pengguna Anda jauh dari kesimpulan yang sama.

Like you said, your aim is to open up MUI to more styling solutions. Seperti yang Anda katakan, tujuan Anda adalah membuka MUI ke lebih banyak solusi gaya. To provide good support for those solutions, there would need to be good documentation, examples and smooth integration layer - otherwise developers would find it hard to translate what they see in demos into what their styling solution of choice needs. Untuk memberikan dukungan yang baik bagi solusi tersebut, perlu ada dokumentasi yang baik, contoh, dan lapisan integrasi yang mulus - jika tidak, pengembang akan kesulitan menerjemahkan apa yang mereka lihat dalam demo menjadi apa yang dibutuhkan oleh solusi gaya pilihan mereka. I'm just not sure if you really need to migrate to styled components to achieve the goals. Saya hanya tidak yakin apakah Anda benar-benar perlu bermigrasi ke komponen gaya untuk mencapai tujuan. Seems like your solution is also perfectly capable, if not more so than others, to build the design tool you're after since you already use actual JS object for all the styles. Sepertinya solusi Anda juga sangat mampu, jika tidak lebih dari yang lain, untuk membangun alat desain yang Anda cari karena Anda sudah menggunakan objek JS aktual untuk semua gaya.

One question I have, does this mean that the core of Mui would still use jss, and this allows for a better way to use styled components on top of that? Satu pertanyaan yang saya miliki, apakah ini berarti bahwa inti dari Mui masih akan menggunakan jss, dan ini memungkinkan cara yang lebih baik untuk menggunakan komponen gaya di atas itu? Or would there be a way to say the core is also styled? Atau akankah ada cara untuk mengatakan bahwa intinya juga ditata? I just think it would add a lot of bloat if you have two css in js solutions. Saya hanya berpikir itu akan menambah banyak kembung jika Anda memiliki dua css dalam solusi js.

How would theming work if using styled-components? Bagaimana cara kerja tema jika menggunakan komponen gaya? I used to use helpers in the CSS portion, and it was really messy. Saya dulu menggunakan pembantu di bagian CSS, dan itu sangat berantakan. For me, the approach of applying theme props in a JS object is a lot cleaner than in a templated string. Bagi saya, pendekatan penerapan alat peraga tema di objek JS jauh lebih bersih daripada di string templat.

For me (scientific backend programmer by origin), MUI styles bring beautiful, calming, predictable, parameterisable logic to the mental, crazy, bonkers-rules why-the-hell tearing-hair-out world of CSS. Bagi saya (programmer backend ilmiah berdasarkan asal), gaya MUI menghadirkan logika yang indah, menenangkan, dapat diprediksi, dan dapat diparameterisasi ke dunia CSS yang mental, gila, dan gila.

The styles library (and its tight integration with the theme) is the main reason I mandate use of MUI over any other components library in the two organisations I oversee tech for - it takes all the css agony away! Pustaka gaya (dan integrasinya yang erat dengan tema) adalah alasan utama saya mengamanatkan penggunaan MUI di atas pustaka komponen lain di dua organisasi yang saya awasi teknologinya - ini menghilangkan semua penderitaan css! At first, all the developers I work with are like "what the hell's going on? Where's the css? Just give me css!!" Pada awalnya, semua pengembang yang bekerja dengan saya seperti "apa yang terjadi? Di mana css? Beri saya css!!" and then they're like "Ohhhh. riiight. Got it. Magic." dan kemudian mereka seperti "Ohhhh. riiight. Mengerti. Ajaib."

In the longer term I think the current approach is going to become ever more powerful as the world moves to low/no code solutions (eg like sketch or figma, but outputting an actual routed app and set of components rather than a set of wireframes) - having styles expressed as an object unlocks the ability to introspect that - and create more new features in such an environment (like provision of a schema enabling direct use of MUI components within a CMS, or generation of 'theme from this' and hundreds I haven't thought of yet). Dalam jangka panjang saya pikir pendekatan saat ini akan menjadi semakin kuat ketika dunia bergerak ke solusi kode rendah/tanpa (misalnya seperti sketsa atau figma, tetapi menghasilkan aplikasi yang dirutekan dan serangkaian komponen daripada satu set gambar rangka) - memiliki gaya yang diekspresikan sebagai objek membuka kunci kemampuan untuk mengintrospeksi itu - dan membuat lebih banyak fitur baru di lingkungan seperti itu (seperti penyediaan skema yang memungkinkan penggunaan langsung komponen MUI dalam CMS, atau pembuatan 'tema dari ini' dan ratusan I belum terpikir).

Moving back to the more raw-css kind of approach of styled-components doesn't preclude that - but it does make a lot of things (particularly parameterisation on the theme) a lot jankier and frustrating to achieve, and still requires much more in-depth knowledge of CSS's technicalities making it less accessible to new programmers and creative types alike. Pindah kembali ke pendekatan yang lebih mentah-css dari styled-components tidak menghalangi itu - tetapi itu membuat banyak hal (terutama parameterisasi pada tema) jauh lebih jankier dan frustasi untuk dicapai, dan masih membutuhkan pengetahuan yang jauh lebih mendalam tentang teknis CSS sehingga kurang dapat diakses oleh programmer baru dan tipe kreatif.

On the evolution of the state-of-the-art, I think styled-components has become really popular because it's a great step in the right direction from where the world was (which is why it became popular). Tentang evolusi seni, saya pikir styled-components telah menjadi sangat populer karena ini adalah langkah besar ke arah yang benar dari tempat dunia berada (itulah sebabnya ia menjadi populer). But the existing MUI styles system is the next step on from that; Tetapi sistem gaya MUI yang ada adalah langkah selanjutnya dari itu; not an incorrect side-step. bukan langkah sampingan yang salah. Once everyone's migrated to styled-components then the question will be "wait: why on earth are we doing this with these weird raw strings in our components...?" Setelah semua orang bermigrasi ke komponen gaya, maka pertanyaannya adalah "tunggu: mengapa kita melakukan ini dengan string mentah yang aneh di komponen kita...?"

Maybe I'm totally wrong, but for my $0.02, I'm begging you to stay the course for at least another major version :) Mungkin saya benar-benar salah, tetapi untuk $0,02 saya, saya mohon Anda untuk tetap mengikuti kursus setidaknya untuk versi utama lainnya :)

@thclark your main concern seems to be with the CSS template string syntax vs the JavaScript style object API. @thclark perhatian utama Anda tampaknya dengan sintaks string template CSS vs API objek gaya JavaScript. Is this accurate? Apakah ini akurat? It also seems to be the concern with most of the other comments of the thread. Tampaknya juga menjadi perhatian dengan sebagian besar komentar lain dari utas.

Styled-components and emotions support both APIs. Komponen gaya dan emosi mendukung kedua API. This wasn't the main purpose of the issue. Ini bukan tujuan utama dari masalah ini. The objective of this issue was to anticipate the migration to a different styling solution. Tujuan dari masalah ini adalah untuk mengantisipasi migrasi ke solusi gaya yang berbeda. However, we never move forward with "use styled-components in all the demos even if we didn't migrate the core engine". Namun, kami tidak pernah melanjutkan dengan "menggunakan komponen gaya di semua demo meskipun kami tidak memigrasikan mesin inti". We have opted for keeping both synchronized. Kami telah memilih untuk tetap menyinkronkan keduanya.
At this point, keeping the issue open doesn't add much value outside triggering discussions like this one :). Pada titik ini, menjaga masalah tetap terbuka tidak menambah banyak nilai di luar memicu diskusi seperti ini :). We have to migrate the demos anyway for #22342. Kami harus memigrasikan demo untuk #22342.

I personally prefer the JavaScript API over the CSS string one because: Saya pribadi lebih suka JavaScript API daripada string CSS karena:

• It doesn't ask for another linter/formater. Itu tidak meminta linter/formater lain.
• I'm used to it. Aku sudah terbiasa.
• It plays nicely with TypeScript. Ini bermain dengan baik dengan TypeScript.

However, it's unclear what the community, at large, will enjoy using most. Namun, tidak jelas apa yang paling disukai komunitas pada umumnya. CSS template has its advantages too. Template CSS juga memiliki kelebihan. It's easier to copy & paste code between the browser and the code. Lebih mudah untuk menyalin & menempelkan kode antara browser dan kode. A lot more people (overall: designers, developers, etc.) are familiar with the approach. Lebih banyak orang (secara keseluruhan: desainer, pengembang, dll.) akrab dengan pendekatan ini.

To be noted that I think that we should use the style utilities as much as possible in the demos with v5. Perlu dicatat bahwa saya pikir kita harus menggunakan utilitas gaya sebanyak mungkin dalam demo dengan v5.

@mnajdova any thoughts on the matter? @mnajdova ada pemikiran tentang masalah ini? Maybe it's worth asking the community on a poll. Mungkin ada baiknya meminta komunitas dalam polling.

@oliviertassinari succinctly put, as usual. @oliviertassinari singkatnya, seperti biasa. Yes, my main concern is retaining the Javascript API. Ya, perhatian utama saya adalah mempertahankan Javascript API. Honestly, I wasn't aware that styled-components retained that, as all of the examples I came across seem to be css templated. Sejujurnya, saya tidak menyadari bahwa komponen gaya mempertahankan itu, karena semua contoh yang saya temukan tampaknya menggunakan templat css.

That perhaps moots most of my points above. Itu mungkin memperdebatkan sebagian besar poin saya di atas. Nevertheless, glad you didn't move across - and thanks for your and the team's continued efforts here. Namun demikian, senang Anda tidak pindah - dan terima kasih atas upaya Anda dan tim yang terus berlanjut di sini. I've built things I never could have without MUI existing. Saya telah membangun hal-hal yang tidak akan pernah bisa saya miliki tanpa adanya MUI.

This issue is being resolved in v5. Masalah ini sedang diselesaikan di v5. We have migrated the documentation of the slider to the new approach: https://next.material-ui.com/components/slider-styled/. Kami telah memigrasikan dokumentasi penggeser ke pendekatan baru: https://next.material-ui.com/components/slider-styled/. We use the sx prop anytime simple CSS are necessary then use the styled API for more heavy customizations. Kami menggunakan sx prop kapan saja CSS sederhana diperlukan kemudian gunakan styled API untuk penyesuaian yang lebih berat. I believe the previous concern raised have been handled, if not, please comment :). Saya yakin masalah sebelumnya yang diangkat telah ditangani, jika tidak, silakan beri komentar :).