Material-ui: Use styled-components em todas as demonstrações

@oliviertassinari what is the exactly the tasks in hand? @oliviertassinari quais são exatamente as tarefas em mãos?

Here is what I understand, Aqui está o que eu entendo,

1. Run the docs website Execute o site de documentos
2. Find all the example source code that uses material-ui/styles Encontre todo o código-fonte de exemplo que usa material-ui/styles
3. Replace them with styled-components Substitua-os por styled-components

Is this correct? Isso está correto?

@yordis I think that the timing is going to be key in this transition. @yordis , acho que o momento será fundamental nessa transição. I would imagine the following steps: Imagino os seguintes passos:

1. We replace the usage of @material-ui/styles in the demos with the Box component, where possible. Substituímos o uso de @material-ui/styles nas demos pelo componente Box, sempre que possível. Moving #16858 at the same time would help. Mover #16858 ao mesmo tempo ajudaria. This can be done in the near future. Isso pode ser feito em um futuro próximo.
2. We solve #15561, we migrate more demos away from @material-ui/styles to use the system props. Resolvemos #15561, migramos mais demos de @material-ui/styles para usar as props do sistema. The sooner we solve this, the better. Quanto antes resolvermos isso, melhor.
3. We update the customization demos to use styled-components, leveraging the global Mui class names. Atualizamos as demonstrações de personalização para usar componentes com estilo, aproveitando os nomes de classe Mui globais. We might need to work on some helpers to make accessing the theme values easier. Talvez precisemos trabalhar em alguns auxiliares para facilitar o acesso aos valores do tema.
4. We solve #6115, we migrate the last usages of @material-ui/styles to styled-components. Resolvemos o #6115, migramos os últimos usos de @material-ui/styles para styled-components. This is a task for v5, I think that we can start it Q1 2020 in the v5 alpha/beta versions. Esta é uma tarefa para a v5, acho que podemos iniciá-la no primeiro trimestre de 2020 nas versões alfa/beta v5.

@oliviertassinari Estou curioso e peço desculpas se isso foi repetido: por que não manter @material-ui/styles como wrapper ou abstração para styled-components ?

@ConAntonakos it's an option. @ConAntonakos é uma opção. It could help if we need to extend/normalize some of the features of styled-components. Pode ajudar se precisarmos estender/normalizar alguns dos recursos dos componentes com estilo.

@oliviertassinari temos uma lista do que resta?

@yordis We haven't done many efforts in this direction yet. @yordis Ainda não fizemos muitos esforços nesse sentido. 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. No entanto, há uma probabilidade de que isso exigirá mudanças importantes, a v5 está planejada para o quarto trimestre de 2020. Acho que devemos explorar uma estratégia de implantação parcial para desenvolvedores que desejam aproveitá-la mais cedo. 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). Agora, esse esforço deve ser equilibrado com outras prioridades, como o suporte a novos componentes avançados (gratuitos e pagos) ou o lançamento de uma versão sem estilo da biblioteca para aumentar nosso alcance de público (com diferentes temas, por exemplo, estilo iOS). The good news is that we will likely grow the team in the coming months, enabling us to move faster. A boa notícia é que provavelmente aumentaremos a equipe nos próximos meses, o que nos permitirá avançar mais rapidamente.

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles ). Imagino que você já esteja usando styled-components em cima do Material-UI hoje como muitos outros desenvolvedores fazem (e não @material-ui/styles ). What are the top pain points you hope to address with this migration? Quais são os principais pontos problemáticos que você espera resolver com essa migração?

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. Do ponto de vista do produto, nosso incentivo é sobre: ​​tamanho de pacote menor, melhor desempenho, suporte a vapor, menos bugs, suporte a strings de modelo CSS, comunidade maior , permite usar os adereços do sistema nos componentes principais, permite verdadeiros temas dinâmicos e suporte a adereços, melhores documentos.

However, there is a high probability that it will require breaking changes, No entanto, há uma alta probabilidade de que isso exigirá mudanças radicais,

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. Sim, eu tentei mudar alguns exemplos, mas eles exigem alguma integração com o provedor de temas, então podemos precisar injetar material/style provedor de temas e styled-component provedor de temas que estou assumindo.

v5 is planned for around Q4 2020. v5 está planejado para cerca do quarto trimestre de 2020.

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? Isso é o suficiente, seria melhor fixar diferentes questões para visibilidade sobre o que é uma prioridade no momento?

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles). Imagino que você já esteja usando styled-components em cima do Material-UI hoje como muitos outros desenvolvedores fazem (e não @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 )🤷‍♂️ Na verdade, estou muito feliz com @material-ui/styles e não estou usando styled-components quando uso Material UI (eu removeria withStyles já que não quero depender da disciplina do programador 😉 , mas eu entendo que o software legado pode não ter ganchos ainda)🤷‍♂️

What are the top pain points you hope to address with this migration? Quais são os principais pontos problemáticos que você espera resolver com essa migração?

I am trying to help with the migration, personally, no pain points. Estou tentando ajudar com a migração, pessoalmente, sem pontos problemáticos. 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. A menos que você leve em consideração que como um ecossistema, eu tenho que manter duas formas de desenvolver algo, mas meh, pessoalmente, está tudo bem para mim.

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. Talvez styled-components corrija alguma interoperabilidade com NextJS e Gatsby desde a última vez que tentei fazer o Mui funcionar com essas ferramentas por causa do SSR e estilos (não tenho certeza se ainda é doloroso) e a maioria das bibliotecas usando styled-components trabalha fora da caixa.

Let me know how I could help, like I said, I was using the pinned issues to find the prioritization of the Org Deixe-me saber como eu poderia ajudar, como eu disse, eu estava usando os problemas fixados para encontrar a priorização da organização

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? Isso é o suficiente, seria melhor fixar diferentes questões para visibilidade sobre o que é uma prioridade no momento?

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. Depende do horizonte de tempo em que você está interessado. Você pode acompanhar a edição com o rótulo important , a página do roteiro na documentação e as atualizações mensais do produto do blog.

I don't fully understand this point. Não entendo totalmente este ponto. Why not using styled-components when using Material-UI (today)? Por que não usar componentes com estilo ao usar o Material-UI (hoje)? We had 1/3 of our users going down this path when we did our last survey, 6 months ago. Tínhamos 1/3 de nossos usuários seguindo esse caminho quando fizemos nossa última pesquisa, 6 meses atrás.

I don't fully understand this point. Não entendo totalmente este ponto. Why not using styled-components when using Material-UI (today)? Por que não usar componentes com estilo ao usar o Material-UI (hoje)?

@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 funciona como um campeão até agora, não há motivo para migrar tudo 😄 então eu sou um dos 3 que não usam juntos hoje.

Thank you for the info about prioritization. Obrigado pelas informações sobre priorização.

@yordis btw, my answer was made under the assumption you were following up on the main styled-components issue. @yordis btw, minha resposta foi feita sob a suposição de que você estava acompanhando o principal problema de componentes de estilo. I haven't realized we were on the documentation one. Eu não percebi que estávamos na documentação.

@oliviertassinari do you have any suggestions about the issue with theme context? @oliviertassinari você tem alguma sugestão sobre a questão com o contexto do 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. Eu tentei usar props.theme dentro de um styled-components mas não funcionou, não tenho certeza se você tem uma sugestão para isso, mas acho que precisaremos adicionar styled-components provedor de temas também.

Hey @oliviertassinari! Oi @oliviertassinari! Are you looking for PR's that convert the existing customization demos to use styled-components as part of this issue? Você está procurando PRs que convertam as demonstrações de personalização existentes para usar componentes com estilo como parte deste problema?

I dont think styled-components is a good styling solution. Eu não acho que styled-components seja uma boa solução de estilo. current solution looks much much more readable, appealing, accessible and cleaner than styled. A solução atual parece muito mais legível, atraente, acessível e limpa do que com estilo. i dont see any good reason to migrate. não vejo nenhuma boa razão para migrar.

I dont think styled-components is a good styling solution. Eu não acho que styled-components seja uma boa solução de estilo. current solution looks much much more readable, appealing, accessible and cleaner than styled. A solução atual parece muito mais legível, atraente, acessível e limpa do que com estilo. i dont see any good reason to migrate. não vejo nenhuma boa razão para migrar.

And get almost fully typed. E ficar quase totalmente digitado. Don't see any reason to migrate +1 Não vejo motivo para migrar +1

The link you've posted, that should show growing interest to styled-components, recently started showing a downward trend: O link que você postou, que deve mostrar um interesse crescente por styled-components, recentemente começou a mostrar uma tendência de queda:

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. Sinto que restringir uma solução de estilo a uma única biblioteca nos dará exatamente o mesmo problema que temos hoje.

What about integration with zero-runtime libraries such as linaria ? E quanto à integração com bibliotecas de tempo de execução zero, como linaria ? This was suggested as being looked at in May 2019 Update . Isso foi sugerido como sendo analisado na atualização de maio de 2019 .

So far it only recovered to pre-v5-hype. Até agora, só recuperou para o hype pré-v5. Let's see how the updated data point for January till now looks. Vamos ver como os dados atualizados de janeiro até agora se parecem.

@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 Não confie muito no rank2traffic.com, os dados não são muito confiáveis ​​nem atualizados, sua principal vantagem foi a tendência geral de mais de 10 anos (antes de ser pago). For a shorter time window, so 6 months, prefer https://www.similarweb.com/ as more reliable. Para uma janela de tempo mais curta, então 6 meses, prefira https://www.similarweb.com/ como mais confiável.
Also take into account that once people know the API, they come back much frequently to the documentation. Também leve em consideração que, uma vez que as pessoas conheçam a API, elas voltam com muita frequência à documentação.

I dont think styled-components is a good styling solution. Eu não acho que styled-components seja uma boa solução de estilo. current solution looks much much more readable, appealing, accessible and cleaner than styled. A solução atual parece muito mais legível, atraente, acessível e limpa do que com estilo. i dont see any good reason to migrate. não vejo nenhuma boa razão para migrar.

And get almost fully typed. E ficar quase totalmente digitado. Don't see any reason to migrate +1 Não vejo motivo para migrar +1

+1 styles is the main reason we're migrating to Material UI and moving away from styled components. +1 styles é a principal razão pela qual estamos migrando para o Material UI e nos afastando dos componentes estilizados. It's too much CSS and refactoring it has proven to be a huge burden for us. É muito CSS e refatorá-lo provou ser um fardo enorme para nós.

Hi! Oi! First of all, thank you for providing a great component library, best one I've used so far. Em primeiro lugar, obrigado por fornecer uma ótima biblioteca de componentes, a melhor que usei até agora. 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. Nossas equipes escreveram centenas de milhares de linhas de código usando os componentes e a metodologia que você criou e, uma vez que os desenvolvedores aprendem o básico sobre o uso de classes , como escrever os estilos etc., é muito fácil trabalhar mesmo em um tipo de base de código em escala corporativa massiva.

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. Não tenho certeza se esse é o uso mais comum de sua biblioteca, mas suponho que você esteja ciente de que muitas equipes constroem suas bibliotecas de componentes em cima da interface do usuário do material e, portanto, todos os componentes e decisões que você toma também chegam a essas bibliotecas. On our end we've been very happy with both performance and APIs so far. Do nosso lado, estamos muito felizes com o desempenho e as APIs até agora.

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. Tenho acompanhado o desenvolvimento recente na biblioteca e, para ser honesto, estou tendo problemas para entender algumas das decisões e preocupado como isso afetará nossas equipes, e qual seria o benefício geral dessa mudança, ao contrário de, por exemplo, bifurcação MUI. Others have voiced their concern about move to styled components so I'll focus on the other one for me - the Box component. Outros expressaram sua preocupação com a mudança para componentes estilizados, então vou focar no outro para mim - o componente Box.

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. Eu entendo a utilidade de um componente Box - para possibilitar o uso de variáveis ​​de tema etc. em valores prop, porém a API e as consequências do uso desse componente o desqualificam de algo que eu poderia recomendar às nossas equipes.

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} /> . Primeiro , ele tem uma API enigmática sem motivo que eu possa discernir (a menos que salvar alguns bytes seja esse motivo): Em vez de escrever <Box margin={3} /> , seria <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 ?" Abreviações como essa parecem desnecessárias, tornam as coisas potencialmente ambíguas e introduzem uma nova curva de aprendizado para os desenvolvedores, um mapeamento de abreviações para propriedades reais que eles agora precisam memorizar: "A aplicação color é feita usando c or color ?", " background é b , ou bg , ou background , ou era b border ?" "Is background-size abbreviated as bs ?" " background-size é abreviado como 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. Em segundo lugar , os componentes abstraem os padrões de UI recorrentes mais comuns e criam APIs que fornecem meios de personalizar esses padrões na medida em que o sistema de design permite. This manifests in creating props like gutterBottom on Typography , or dense on ListItem - as opposed to accepting just about any padding or margin. Isso se manifesta na criação de adereços como gutterBottom em Typography ou dense em ListItem - em vez de aceitar praticamente qualquer preenchimento ou margem. 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. Eu sinto que a introdução Box em grande parte mina esse esforço e introduz uma ferramenta que fará uma bagunça em qualquer tentativa de seguir um sistema de design, a menos que definamos algumas maneiras muito delicadas que o componente Box pode ser usado e gasto esforço em revisões de código para garantir que todos os valores nas props Box usadas não estejam além da lista aceita. 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. E nesse ponto, a maneira de "automatizar" isso seria criar um componente que restrinja as opções, e voltamos à estaca zero. To give an example, why would using Box mb={2} to achieve margin under Typography be okay, but Box mb={6} not? Para dar um exemplo, por que usar Box mb={2} para obter margem em tipografia seria bom, mas Box mb={6} não? This concern doesn't exist when we can rely on props to limit the options. Essa preocupação não existe quando podemos contar com adereços para limitar as opções.

Third concern, or rather a question I have. Terceira preocupação, ou melhor, uma pergunta que tenho. 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. Como o componente Box é potencialmente uma maneira rápida de construir certas funcionalidades, ele também seria usado por bibliotecas construídas sobre o MUI. How would one override the styles of Box components used within another component? Como alguém substituiria os estilos dos componentes Box usados ​​em outro componente? As an example. Como um exemplo. 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? Se construíssemos ListItem usando Box sob o capô, precisaríamos introduzir BoxProps={{ padding: 2 }} , ou aceitar também dense prop com base na qual escrevemos lógica para aplicar uma prop padding a um Caixa particular, ou ainda outra coisa?

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. Não tenho certeza se esse é o uso mais comum de sua biblioteca, mas suponho que você esteja ciente de que muitas equipes constroem suas bibliotecas de componentes em cima do Material UI e, portanto, todos os componentes e decisões que você toma também chegam a essas bibliotecas. On our end we've been very happy with both performance and APIs so far. Do nosso lado, estamos muito felizes com o desempenho e as APIs até agora.

@maciej-gurban This use case is an important one for us. @maciej-gurban Este caso de uso é importante para nós. Our incentives are aligned to significantly improve it. Nossos incentivos estão alinhados para melhorá-lo significativamente. This is one of our objectives with v5. Este é um dos nossos objetivos com a 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. Por exemplo, estamos investigando a viabilidade de fornecer uma ferramenta de design que poderia ser colocada nas mãos de designers (pago) e produziria componentes personalizados de Material-UI (MIT) prontos para usar, documentação correspondente, kit Sketch & Figma. Basically, all we have been going it for Material Design but scaling it 🚀. Basicamente, tudo o que temos feito para o Material Design, mas escalando 🚀.
The end goal here would be to free the time of a couple of front-end developers in each company. O objetivo final aqui seria liberar o tempo de alguns desenvolvedores front-end em cada empresa. 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? Por que os desenvolvedores front-end criam um sistema de design personalizado quando isso pode ser feito por seus próprios designers + Material-UI por uma fração do custo? + reduce risk and have your front-end developers spend time where they make the most differences: working on the product. + reduza o risco e faça com que seus desenvolvedores front-end passem tempo onde fazem mais diferença: trabalhando no produto.

I'm having trouble understanding some of the decisions and worried how that will affect our teams Estou tendo problemas para entender algumas das decisões e preocupado como isso afetará nossas equipes

If you could list them, it would be awesome. Se você pudesse listá-los, seria incrível.

Others have voiced their concern about move to styled components Outros expressaram sua preocupação com a mudança para componentes estilizados

What's your concern with such a shift? Qual é a sua preocupação com essa mudança? Our objective on the styling side has a couple of layer: Nosso objetivo no lado do estilo tem algumas camadas:

1. Unstyled component, expose the same existing components but without any styles. Componente sem estilo, exponha os mesmos componentes existentes, mas sem nenhum estilo. Keep the same classes API (first seen in jQuery-UI), provide default hardcoded values for each of the classes (global class names). Mantenha a mesma API classes (visto pela primeira vez em jQuery-UI), forneça valores codificados padrão para cada uma das classes (nomes de classes globais). The objective behind this shift answer to a couple of incentives. O objetivo por trás dessa mudança responde a alguns incentivos. 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. Primeiro, é para descartar o medo que nossos usuários têm, mesmo no modo de ejeção do CRA, você não o usará, mas parece seguro estar presente. Second, it's required to be able to build the paid design tool. Em segundo lugar, é necessário poder construir a ferramenta de design paga. Third, it's required for the next layer Terceiro, é necessário para a próxima camada
2. Multiple style engines. Motores de vários estilos. The community is fragmented between different styling approaches. A comunidade está fragmentada entre diferentes abordagens de estilo. By order of popularity: styled-components, plain CSS, CSS modules, emotion, JSS, utility first classes. Por ordem de popularidade: styled-components, CSS simples, módulos CSS, emoção, JSS, primeira classe de utilitários. It still feels like we didn't find the holy grail for styling. Ainda parece que não encontramos o Santo Graal para o estilo. And until we do, better not bet too much on any styling solution. E até que o façamos, é melhor não apostar muito em nenhuma solução de estilo. So, have styled-components has the default, but allow developers to switch engine, stay on JSS if they are happy too. Portanto, ter styled-components tem o padrão, mas permite que os desenvolvedores troquem de mecanismo, permaneçam no JSS se estiverem felizes também.
3. Baseline theme. Tema básico. Something less opinionated than the current default Material Desing Theme, but using the same theme's specification. Algo menos opinativo do que o atual tema padrão de design de materiais, mas usando a especificação do mesmo tema.
4. A couple of different themes on top of the baseline. Alguns temas diferentes em cima da linha de base. One for marketing pages, One for the Chinese market (close to the Gmail equivalent of China). Um para páginas de marketing, um para o mercado chinês (próximo ao equivalente do Gmail na China).

I'll focus on the other one for me - the Box component. Vou focar no outro para mim - o componente Box.

Yeah, I can hear you! Sim, eu posso ouvir você! I have been working with @gregberge in the past. Eu tenho trabalhado com @gregberge no passado. At some point, we have considered hiding all the className props on @doctolib 's design system. Em algum momento, consideramos ocultar todos os adereços className no sistema de design do @doctolib . The interesting thought is that you can gain features (properties) in exchange of more constraints. O pensamento interessante é que você pode ganhar recursos (propriedades) em troca de mais restrições.

I wouldn't worry too much about this one. Eu não me preocuparia muito com este. This can be resolved with a global option to limit the access to the "system"'s features or an eslint rule. Isso pode ser resolvido com uma opção global para limitar o acesso aos recursos do "sistema" ou uma regra eslint.

The abbreviation on the Box component is confusing. A abreviação do componente Box é confusa. Code is being read more than being written, so it's important to keep clear what the code is meaning. O código está sendo mais lido do que escrito, por isso é importante manter claro o que o código significa. Last day I found "Box py={2}" in our codebase and I'm totally confused. No último dia encontrei "Box py={2}" em nossa base de código e estou totalmente confuso. After a search I figured out that means "paddingY". Depois de uma pesquisa, descobri que significa "paddingY". Those abbreviation should not be encouraged especially non-css properties (I can guess pt means padding-top but not for py) Essas abreviações não devem ser encorajadas especialmente propriedades não-css (posso adivinhar que pt significa padding-top, mas não para py)

@oliviertassinari Thanks for your patience @oliviertassinari Obrigado pela paciência

I'm having trouble understanding some of the decisions and worried how that will affect our teams Estou tendo problemas para entender algumas das decisões e preocupado como isso afetará nossas equipes

If you could list them, it would be awesome. Se você pudesse listá-los, seria incrível.

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. Eu não gostaria que isso se transformasse em uma ladainha de coisas com as quais eu discordo, porque, em última análise, vocês são os caras que mantêm esta biblioteca e nossa visão do que faz sentido será moldada por nossas próprias necessidades que podem e provavelmente nem sempre alinhar, e tudo bem. 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. Não sou contra a introdução de meios de usar outras soluções de estilo - na verdade, acho ótimo, pois trará mais usuários que estavam adiando por não gostarem do JSS, mas também temos nós - os usuários já existentes de sua biblioteca que são vendidos em sua solução e, se possível, gostaria de evitar refatoração massiva.

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. Mesmo se você decidir que "ainda fornecemos suporte para JSS", refatorar todas as demonstrações e seus componentes para componentes com estilo forçará as equipes que usam JSS a migrar para componentes com estilo. "Why are we still using X, when MUI team moved to Y?" "Por que ainda estamos usando X, quando a equipe MUI mudou para 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. - será uma das muitas questões à luz das quais seria realmente difícil não concordar com a necessidade de fazer essa migração mais cedo ou mais tarde.

I can definitely empathize with wanting to reach a wider audience by using a styling solution that's more popular. Definitivamente, posso simpatizar com o desejo de alcançar um público mais amplo usando uma solução de estilo mais popular. 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. No entanto, acho que vale a pena considerar que "popular" nem sempre é "melhor" e que uma mudança para uma tecnologia diferente precisa considerar não apenas as vantagens e desvantagens de ambas as soluções, mas o contexto em que estamos tomando a decisão.

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. Começar do zero, olhar apenas para as vantagens de X sobre Y faz sentido, mas trabalhando em um sistema já existente, também precisamos considerar o custo da mudança e os efeitos dominó que isso traz para as equipes downstream. For this switch over to make sense the advantanges of the other solution need to outweight the cost of migrating over. Para que essa mudança faça sentido, as vantagens da outra solução precisam superar o custo da migração. 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. Parece que para sua equipe, essa análise de custo-benefício governa a favor de componentes com estilo, mas pelo que posso dizer observando as reações em postagens falando sobre componentes com estilo em seu repositório, sua base de usuários está longe de ser a mesma conclusão.

Like you said, your aim is to open up MUI to more styling solutions. Como você disse, seu objetivo é abrir o MUI para mais soluções de estilo. 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. Para fornecer um bom suporte para essas soluções, seria necessário haver uma boa documentação, exemplos e uma camada de integração suave - caso contrário, os desenvolvedores achariam difícil traduzir o que veem nas demonstrações para o que sua solução de estilo de escolha precisa. I'm just not sure if you really need to migrate to styled components to achieve the goals. Só não tenho certeza se você realmente precisa migrar para componentes estilizados para atingir as metas. 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. Parece que sua solução também é perfeitamente capaz, se não mais do que outras, de construir a ferramenta de design que você procura, já que você já usa o objeto JS real para todos os estilos.

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? Uma pergunta que tenho, isso significa que o núcleo do Mui ainda usaria jss, e isso permite uma maneira melhor de usar componentes estilizados em cima disso? Or would there be a way to say the core is also styled? Ou haveria uma maneira de dizer que o núcleo também é estilizado? I just think it would add a lot of bloat if you have two css in js solutions. Eu só acho que adicionaria muito inchaço se você tivesse duas soluções css em js.

How would theming work if using styled-components? Como o tema funcionaria se usando componentes com estilo? I used to use helpers in the CSS portion, and it was really messy. Eu costumava usar auxiliares na parte CSS, e era muito confuso. For me, the approach of applying theme props in a JS object is a lot cleaner than in a templated string. Para mim, a abordagem de aplicar adereços de tema em um objeto JS é muito mais limpa do que em uma string modelada.

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. Para mim (programador de back-end científico por origem), os estilos MUI trazem uma lógica bonita, calmante, previsível e parametrizável para o mundo mental, louco e maluco do CSS.

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! A biblioteca de estilos (e sua forte integração com o tema) é a principal razão pela qual eu ordeno o uso do MUI sobre qualquer outra biblioteca de componentes nas duas organizações para as quais supervisiono a tecnologia - isso tira toda a agonia do 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!!" No começo, todos os desenvolvedores com quem trabalho ficam tipo "o que diabos está acontecendo? Onde está o css? Apenas me dê css!!" and then they're like "Ohhhh. riiight. Got it. Magic." e então eles ficam tipo "Ohhhh. certo. Entendi. Mágica".

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). A longo prazo, acho que a abordagem atual se tornará cada vez mais poderosa à medida que o mundo se move para soluções de baixo/nenhum código (por exemplo, como sketch ou figma, mas produzindo um aplicativo roteado real e um conjunto de componentes em vez de um conjunto de wireframes) - ter estilos expressos como um objeto desbloqueia a capacidade de introspecção - e criar mais novos recursos em tal ambiente (como o fornecimento de um esquema permitindo o uso direto de componentes MUI dentro de um CMS, ou geração de 'tema deste' e centenas de ainda não pensei).

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. Voltar para o tipo de abordagem mais raw-css de styled-components não impede isso - mas torna muitas coisas (particularmente a parametrização do tema) muito mais complicadas e frustrantes de alcançar, e ainda requer conhecimento muito mais aprofundado das tecnicalidades do CSS, tornando-o menos acessível para novos programadores e tipos criativos.

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). Sobre a evolução do estado da arte, acho que styled-components se tornou muito popular porque é um grande passo na direção certa de onde o mundo estava (e é por isso que se tornou popular). But the existing MUI styles system is the next step on from that; Mas o sistema de estilos MUI existente é o próximo passo a partir disso; not an incorrect side-step. não um passo lateral incorreto. 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...?" Uma vez que todos tenham migrado para styled-components, a pergunta será "espere: por que diabos estamos fazendo isso com essas estranhas strings brutas em nossos componentes ...?"

Maybe I'm totally wrong, but for my $0.02, I'm begging you to stay the course for at least another major version :) Talvez eu esteja totalmente errado, mas pelos meus $ 0,02, estou implorando para que você mantenha o curso por pelo menos outra versão principal :)

@thclark your main concern seems to be with the CSS template string syntax vs the JavaScript style object API. @thclark sua principal preocupação parece ser com a sintaxe de string de modelo CSS versus a API de objeto de estilo JavaScript. Is this accurate? Isso é preciso? It also seems to be the concern with most of the other comments of the thread. Também parece ser a preocupação com a maioria dos outros comentários do tópico.

Styled-components and emotions support both APIs. Componentes estilizados e emoções suportam ambas as APIs. This wasn't the main purpose of the issue. Este não era o objetivo principal da questão. The objective of this issue was to anticipate the migration to a different styling solution. O objetivo desta edição foi antecipar a migração para uma solução de estilo diferente. However, we never move forward with "use styled-components in all the demos even if we didn't migrate the core engine". No entanto, nunca avançamos com "usar componentes com estilo em todas as demos, mesmo que não tenhamos migrado o mecanismo principal". We have opted for keeping both synchronized. Optamos por manter ambos sincronizados.
At this point, keeping the issue open doesn't add much value outside triggering discussions like this one :). Neste ponto, manter a questão aberta não agrega muito valor fora de desencadear discussões como esta :). We have to migrate the demos anyway for #22342. Nós temos que migrar as demos de qualquer maneira para #22342.

I personally prefer the JavaScript API over the CSS string one because: Eu pessoalmente prefiro a API JavaScript sobre a string CSS porque:

• It doesn't ask for another linter/formater. Ele não pede outro linter/formador.
• I'm used to it. Estou acostumado com isso.
• It plays nicely with TypeScript. Ele funciona bem com o TypeScript.

However, it's unclear what the community, at large, will enjoy using most. No entanto, não está claro o que a comunidade, em geral, mais gostará de usar. CSS template has its advantages too. O modelo CSS também tem suas vantagens. It's easier to copy & paste code between the browser and the code. É mais fácil copiar e colar o código entre o navegador e o código. A lot more people (overall: designers, developers, etc.) are familiar with the approach. Muito mais pessoas (em geral: designers, desenvolvedores, etc.) estão familiarizadas com a abordagem.

To be noted that I think that we should use the style utilities as much as possible in the demos with v5. Note-se que acho que devemos usar os utilitários de estilo o máximo possível nas demos com a v5.

@mnajdova any thoughts on the matter? @mnajdova alguma opinião sobre o assunto? Maybe it's worth asking the community on a poll. Talvez valha a pena perguntar à comunidade em uma enquete.

@oliviertassinari succinctly put, as usual. @oliviertassinari colocado sucintamente, como de costume. Yes, my main concern is retaining the Javascript API. Sim, minha principal preocupação é manter a API Javascript. Honestly, I wasn't aware that styled-components retained that, as all of the examples I came across seem to be css templated. Honestamente, eu não sabia que os styled-components mantinham isso, já que todos os exemplos que encontrei parecem ser templates CSS.

That perhaps moots most of my points above. Isso talvez discutam a maioria dos meus pontos acima. Nevertheless, glad you didn't move across - and thanks for your and the team's continued efforts here. No entanto, feliz por você não ter se mudado - e obrigado por seus esforços contínuos e da equipe aqui. I've built things I never could have without MUI existing. Construí coisas que nunca poderia ter sem a existência do MUI.

This issue is being resolved in v5. Este problema está sendo resolvido na v5. We have migrated the documentation of the slider to the new approach: https://next.material-ui.com/components/slider-styled/. Migramos a documentação do slider para a nova abordagem: 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. Usamos a prop sx sempre que CSS simples é necessário, então usamos a API styled para personalizações mais pesadas. I believe the previous concern raised have been handled, if not, please comment :). Acredito que a preocupação anterior levantada foi tratada, se não, por favor comente :).