Material-ui: [RFC] Migrar para componentes com estilo

@kybarg Obrigado por abrir esse problema! O CSS-in-JSS é um campo em movimento, as escolhas que fizemos no passado podem não ser mais válidas à medida que os problemas e as soluções mudam.

Por que não estilizar componentes no passado?

Comparamos as diferentes soluções de estilo disponíveis antes de selecionar o JSS.

Não elegemos componentes com estilo pelos seguintes motivos:

• Custo da abstração. css-in-js-perf-tests é um bom recurso, os styled-components usam glamour internamente.
  
  
  
  • 126 kb descompactado em 22 kb para JSS
  
  
  • O tempo para a primeira pintura é mais lento. Compare o tempo para pintar pela primeira vez nas demonstrações equivalentes de https://github.com/MicheleBertoli/css-in-js , o desempenho do JSS é 40% melhor.
  
  
• Expor o className e o poder do seletor profundo de CSS permitem uma implementação de alto desempenho. Por exemplo, com o <Grid /> : #6010.
• Nenhuma simultaneidade de renderização do lado do servidor possível. Está contando com um singleton para coletar os estilos enquanto o JSS instancia uma nova instância para coletar estilos a cada solicitação. A vaporização é realmente limitada.

Na verdade, styled-components nem existiam quando @nathanmarks começou a trabalhar para se afastar do estilo inline.

A tabela de comparação

Suporta CSS global

Com https://github.com/cssinjs/jss-global você pode escrever coisas como

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

Fácil de substituir

Como isso não é fácil? No lado do Material-UI, temos uma tabela de pedidos de injeção predefinida. Na terra do usuário, eles podem usar afrodisíacos que implementam uma ótima API de substituição de afrodite.

Sem componentes do wrapper

Não temos nenhum componente wrapper no lado do Material-UI. Poderíamos estar usando withStyles , mas não usamos por motivos de desempenho. Expomos esse Componente de ordem superior aos usuários para abstrair a implementação do contexto.

Tema

Usamos jss-theme-reator internamente. JSS está expondo uma API de baixo nível que torna isso possível.

Suporte ReactNative

Esse é um bom ponto, a API react-with-styles é bastante interessante. Isso é algo que poderíamos estar melhorando!

O futuro

No futuro, acho que o caminho mais promissor é ter uma API que permita alternar a implementação do estilo. Isso nos traria dois benefícios:

• Material-UI é menos acoplado a qualquer solução de estilo
• Os usuários que usam styled-components / aphrodite/... do seu lado podem economizar a sobrecarga de JSS usada internamente.

react-toolbox está seguindo esse caminho . Minha única preocupação seria com a sobrecarga que está adicionando. Quero dizer, vale a pena?

Estou adicionando @kof e @mxstbr ao loop.

@kybarg Na verdade, não tenho certeza de entender completamente o que você está sugerindo.
Não estamos usando react-jss como sua pergunta sugere.

Quando você diz nós, você está falando sobre usuários ou Material-UI?

Meus pontos são:

• styled-components é uma biblioteca de nível muito superior ao núcleo JSS, você pode com certeza usá-la em sua camada de aplicação.
• A tabela de comparação acima é sobre react-jss, não JSS core e é uma opinião subjetiva de Max. É parcialmente falso e parcialmente apenas um olhar de alguma perspectiva específica que não vemos da mesa.
• Estamos trabalhando na renderização de regras dinâmicas para um estilo dinâmico mais eficiente, jss-theme-reactor já faz o trabalho agora, é apenas uma questão de otimização, o que provavelmente não é muito relevante para MUI.
• O que o MUI usa internamente deve estar totalmente fora da preocupação do usuário final. Tudo o que um usuário precisa fazer deve ser possível mesmo sem saber o que o MUI está usando internamente ou pelo menos sua sintaxe cssinjs mais ou menos regular para temas.
• Precisamos obter casos de uso que o MUI não suporta no momento e resolvê-los. Fico sempre feliz em ajudar no processo de integração e disponível no gitter.
• O que é suporte nativo de reação, afinal? Não é apenas um subconjunto da plataforma web? Nesse caso, deve funcionar, caso contrário, deixe-me saber o que o JSS precisa fazer para suportar o react-native, aqui está o problema .

Essa tabela é realmente muito subjetiva e baseada em minha própria experiência. FWIW, styled-components funciona com qualquer biblioteca de componentes de terceiros:

import { Button } from 'material-ui'

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

Isso funciona desde que os componentes anexem a prop className internamente a algum nó DOM:

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

O que é suporte nativo de reação, afinal? Não é apenas um subconjunto da plataforma web?

Não, não é tão fácil 😉 Adicionar suporte ao JSS não deve ser difícil, pois tudo que você precisa fazer é passar o objeto de estilo para StyleSheet.create() . Isso requer um pouco mais de esforço do lado styled-components para fazer as strings CSS funcionarem.

Estou conversando com @javivelasco há um tempo e adoro onde ele está indo com react-toolbox . Sua implementação é incrível, e eu adoraria ver todas as bibliotecas de componentes de terceiros adotá-la. Fazendo um ping nele para que ele possa entrar em contato com suas ideias aqui!

Nenhuma simultaneidade de renderização do lado do servidor possível. Está contando com um singleton para coletar os estilos enquanto o JSS instancia uma nova instância para coletar estilos a cada solicitação. A vaporização é realmente limitada.

Totalmente não relacionado, se importa de comentar nesta edição com suas ideias para uma API que permitiria que esse fosse o caso? Nós não decidimos o que vamos fazer, então sua opinião seria muito apreciada.

Oi, eu perguntei sobre isso no gitter. Apenas para obter a opinião dos outros, vou postar aqui também:

Eu sei que o material-ui _next_ está fortemente investido em uma solução jss personalizada.
Alguém descobriu alguma vantagem séria de usar jss sobre componentes com estilo?

Embora o jss seja bom, pois permite vários padrões, como decoradores (injectstyles) e plugins, acho que a abordagem direta de componentes com estilo é muito mais limpa, pois não há necessidade de decoradores, configuração personalizada e plugins porque não precisa.

Em styled-comp cada componente já está estilizado, então não há necessidade de passar estilos. e você passa adereços que podem ser avaliados para produzir um estilo diferente
sem configuração (createJss)
sem plugins (prefixo)
sem JSON DSL

Alguém tem que bloquear este tópico.

@rainice jss não tem decoradores, um HOC é um detalhe de implementação do react-jss e não é usado aqui.

Por que isso deve ser bloqueado? É uma discussão sensata IMO

Porque o conteúdo baseado no usuário final aqui (não os mantenedores da lib) é altamente superficial e isso é compreensível porque eles não leram uma única linha de código por trás do que eles usam.

Como a escolha da solução de estilo foi amplamente discutida , o raciocínio por trás da decisão documentado e o trabalho de desenvolvimento para o próximo grande lançamento está em andamento , esse não é um problema útil, então vou encerrá-lo.

Espero que as pessoas sejam maduras o suficiente para não continuar postando em um tópico fechado, mas podemos bloqueá-lo se for necessário.

Eu gostaria que pudéssemos ter avançado nesse segmento com uma solução de estilo menos acoplada!
No entanto, acho que nossa prioridade, por enquanto, deve ser terminar a migração/melhoria geral dos componentes.

@mxstbr obrigado por componentes com estilo

Isso funciona desde que os componentes anexem a propriedade className internamente a algum nó DOM

isso pode valer a pena destacar em algum lugar em seu guia de uso quando mui:next for lançado. Esse comentário acabou de me salvar.

Estilos flexíveis para IE10 não funcionam com jss, mas funcionam com componentes estilizados como um encanto

@yhaiovyi Material-UI não suporta IE10.

Prefixador de fornecedor evtl. Será corrigido em breve para jss, não significa que corrigirá todos os problemas se o mui nunca tiver sido testado no IE10

De qualquer forma, não encontrei nenhum outro problema, então o css flex com o IE10 até agora

Parece que temos 3 maneiras (poderia ser mais fácil, mas nem tudo são flores) para substituir os estilos de interface do usuário com componentes estilizados. Aqui está minha essência .

Você também pode obter uma API de componentes com estilo, como com algumas linhas de código: https://material-ui-next.com/customization/css-in-js/#styled -components-api-15-lines-

Você também pode usar styled-jss , exemplo: https://codesandbox.io/s/32mvjyjyxq

a única desvantagem do JSS em geral é a falta de autocompletar nos editores de código, como dito aqui também , mas os benefícios estão lá, analisar css para js como em styled-components é um pouco uma sobrecarga

edit: acabei de notar o problema referenciado logo acima, interessante

O que é irritante é o contexto de Mui e withStyles HOC não parecem funcionar bem com o núcleo react-jss e styled-jss ThemeProvider https://codesandbox.io/s/32mvjyjyxq (tentei colocar um Typography mas isso não funciona, edite: nvm, ainda brincando com isso)

Eu me pergunto se mais tarde (pós v1 eu acho) não valeria a pena simplificar src/styles/withStyles e MuiThemeProvider + JSSProvider double layer, e ter algo um pouco mais simples como react-jss e styled-jss têm

Totalmente para isso!

Em 13 de março de 2018 13:55, "Cyril Auburtin" [email protected] escreveu:

O que é irritante é o contexto de Mui e com Styles HOC não parecem jogar
bem com o núcleo react-jss e styled-jss ThemeProvider
https://codesandbox.io/s/32mvjyjyxq

Eu me pergunto se mais tarde (pós v1 eu acho) não valeria a pena simplificar
src/styles/withStyles e MuiThemeProvider + JSSProvider dupla camada

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mui-org/material-ui/issues/6115#issuecomment-372655385 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AADOWAbwLOnRoypx9ANCZnKyalZyD0M9ks5td8HNgaJpZM4L-GwD
.

analisar css para js como em componentes com estilo é um pouco uma sobrecarga

Assim como analisar objetos para CSS é :wink: Analisar strings tem a mesma velocidade, honestamente não importa. https://github.com/A-gambit/CSS-IN-JS-Benchmarks/blob/master/RESULT.md

Solução | Usar CSS | Use Estilos Inline | Tempo de montagem (ms) | Tempo de renderização (ms)
:--- | :--- | :--- | :--- | :---
...
componentes estilizados | + | - | 182 | 146,84
célula de desacoplamento de componentes com estilo | + | - | 213,53 | 152,39
...
react-jss | + | - | 198,97 | 297,74

@mxstbr um analisador css completo escrito em js em tempo de execução definitivamente tem um preço. Esse benchmark não está medindo seu custo.

um analisador css completo escrito em js em tempo de execução definitivamente tem um preço.

Claro, mas não mais do que um analisador CSS completo que lida com objetos em vez de strings. Além disso, analisadores CSS que operam em strings CSS reais foram otimizados e explorados por um longo tempo, muito menos com aqueles que manipulam objetos. :corar:

Eu ficaria curioso sobre o benchmarking de CSS bootstraps como um objeto com seu analisador vs CSS bootstraps com stylis, nosso analisador, mas tenho certeza de que a diferença será insignificante na melhor das hipóteses.

Eu ficaria curioso sobre o benchmarking de CSS bootstraps como um objeto com seu analisador vs CSS bootstraps com stylis, nosso analisador, mas tenho certeza de que a diferença será insignificante na melhor das hipóteses.

Sim, isso seria um benchmark apropriado, testei um pouco, trabalhar com objetos é muito mais rápido, tipo 10-20x mais rápido.

Mas, novamente, depende de quais plugins jss você incluiria, temos muitos plugins de açúcar sintático.

Também tbm. não importa se todos nós mudarmos para a ISTF.

Eu testei um pouco, trabalhar com objetos é muito mais rápido, tipo 10-20x mais rápido.

Claro, mas 10ms (é quanto tempo os stylis levam para analisar toda a folha de estilo bootstrap) versus 1ms de analisar todo o CSS de um aplicativo não importa no grande esquema das coisas, sabe? Não vai fazer ou quebrar o aplicativo de ninguém.

De qualquer forma, vamos parar de incomodar as pessoas nesta questão com mais notificações do que o necessário.

Por falar nisso. este benchmark parece ser mais preciso: http://necolas.github.io/react-native-web/benchmarks/ Não tenho certeza, embora não esteja contando com um cache após a primeira análise.

@mxstbr Embora esse problema esteja bloqueado, um pouco de competição saudável é bom para todos. Volte a qualquer momento - você pode nos encontrar no bate-papo do gitter se um problema não for o local apropriado para discussão.

Esta questão tem mais de um ano. Pessoal, parem de comentar isso. Podemos mover a discussão para uma nova. Muita coisa mudou desde que a discussão começou.

Mas vamos tentar evitar problemas de bloqueio. Precisamos continuar coletando o máximo de feedback possível para tomar melhores decisões.

Eu acho que bloquear o problema como uma ferramenta para comunicar claramente isso é bom, ninguém se ofendeu com isso nem a liberdade de expressão foi tomada. Neste caso é muito bom.

Estou reabrindo para coletar mais feedback, estou curioso para saber se isso é algo em que as pessoas ainda estão interessadas:

Temos uma pesquisa de desenvolvedor em execução e usaremos os resultados para atualizar nosso ROADMAP.
Temos os seguintes requisitos com a solução de estilos:

1. Tamanho do pacote . Queremos que as pessoas possam usar um único componente sem ter que pagar 20 KB compactados por ele. Por classificação:
   
   
   
   1. emoção é o melhor candidato nessa direção: 10kB gzipped . No entanto, é usado por poucas pessoas. Se você olhar para as estatísticas de download, 80% vem do livro de histórias ?
   
   
   2. styled-components pesam cerca de 16 KB compactados em gzip . Sua vantagem vem do número de pessoas que o utiliza. Talvez 20% dos usuários do React?
   
   
   3. JSS com um peso de wrapper de reação de cerca de 15 KB compactado. Se você observar as estatísticas de download, muito do uso vem do Material-UI.
   
   
2. Desempenho . Queremos que as pessoas não possam customizar nossos componentes. Eles devem ser o mais rápido possível. O benchmark que eu poderia fazer rende o seguinte ranking:
   
   
   
   1. emoção
   
   
   2. jss
   
   
   3. componentes estilizados
   
   
3. API de personalização . Personalizar uma variante deve ser fácil, personalizar um elemento aninhado deve ser fácil, adicionar uma nova variante deve ser fácil. No momento, temos uma API classes , uma API theme.overrides e a capacidade de ter nomes de classe determinísticos globais.
4. Interoperabilidade . Usar !important não é uma solução.
5. Suporte RTL

Mencionei apenas styled-components, emoção e JSS, mas são alternativas diferentes: linaria, SASS, etc.

Acredito que vale a pena adicionar os dois problemas a seguir, pois eles podem ajudar a afetar a decisão de quando você teria tempo para trabalhar na biblioteca CSS-in-JS usada pelo Material-UI:

• https://github.com/mui-org/material-ui/issues/15660
• https://github.com/cssinjs/jss/issues/1102
  Em resumo, esses dois problemas cobrem a inconsistência do JSS que afeta a experiência do desenvolvedor.

@o-alexandrov O JSS está seguindo a mesma estratégia dos componentes com estilo? Eu não entendo o seu ponto. Você poderia esclarecer? Qual é a diferença? Como é melhor ou vale a pena?

@oliviertassinari
Na mensagem anterior, não digo nada sobre styled-components , exceto que aceito a ideia de avaliar o uso de styled-components ou qualquer outra biblioteca CSS-in-JS que tenha o equilíbrio perfeito de:

• experiência do desenvolvedor (familiaridade e flexibilidade, contribuições adicionais, uso real por desenvolvedores, etc.)
• atuação

Os links para as duas questões acima apenas discutem o atual aspecto negativo de trabalhar com JSS.
Esqueci onde vi o seguinte, mas lembro que você destacou que, para poder tomar decisões, devemos primeiro adicionar todos os tipos de benchmarks para que as decisões possam ser avaliadas com mais facilidade.

Pessoalmente, gosto de:

• styled-components sobre jss para uma adoção muito mais ampla da comunidade.
  Acredito que a adoção pela comunidade é o aspecto chave que o Material UI deve considerar.

@o-alexandrov Ok, neste caso, estou marcando seu primeiro comentário como off-topic. Na v5, queremos isolar os componentes principais da solução de estilo. Eu gostaria que pudéssemos fornecer versões naked, JSS, emoção, linaria e styled-components (como o padrão) dos componentes. Essa é a visão. Agora a implementação vai ser um desafio!

Tamanho do pacote

styled-components provou estar melhorando 12.3kB em @5.0.0-beta.8

API de personalização

Se eles introduzirem https://github.com/styled-components/styled-components/pull/2625 no pacote ou no pacote externo, acredito na paridade da API com o Mui, pois falta API de componentes não estilizados que às vezes podemos precisar , especialmente em sistemas legados, mas não acho que você precisaria dessa API no próprio Mui com tanta frequência.

Fora disso,

Não tenho certeza de quais informações você gostaria de coletar, pois, pela minha experiência pessoal, styled-components oferece os recursos de que precisamos.

Interoperabilidade.

O que é isso para você neste contexto? Você pode substituir as coisas em styled-components como qualquer outro framework até onde eu saiba.

Suporte RTL

Isso não é baseado em como codificamos os componentes? O que exatamente styled-components ou qualquer biblioteca CSS-in-JS tem a oferecer para isso?

Meus pensamentos

Velocidade

Costumava ser mais lento em comparação com outras soluções, mas o suporte e o incrível esforço dos colaboradores chegaram ao ponto em que está se tornando ainda mais rápido que o JSS.

Tamanho

v5 está se tornando ainda mais enxuto, como eu disse 12.3kB de 16.2kB que representam seu esforço neste tópico.

Familiaridade

As pessoas estão familiarizadas com a API, pois é a mais popular, na verdade, a maioria das pessoas chama styled-components referindo-se à API em vez do pacote real quando usamos styled(...) ... API, na maioria das vezes.

Reagir nativo

Isso pesa tanto para Mui é a web, mas as pessoas continuarão adotando styled-components por causa disso.

Equipe principal

Forte equipe Core, até hoje 81 edições e 14 PRs abertos, esses são bons números para o número de pessoas que usam o pacote.

Além disso, pessoas como @mxstbr realmente usam o pacote em spectrum então ele tem experiência no mundo real usando o pacote, isso é incrível, isso significa que ele realmente sabe como é usar o pacote.

Pegou

Bem, não poderia ser melhor https://www.styled-components.com/docs/tooling

Para autores de IU

A partir de hoje, a adoção de styled-components para componentes do Design System tem aumentado muito; Atlassian, GitHub, Orbit e muitos outros.

Isso é bom para Mui, pois você não estará sozinho, então provavelmente as pessoas já lidam com situações em potencial que você pode encontrar e descobriram como lidar com isso.

TL;DR

Eu apoio styled-components .

Eu gosto de JSS porque a sintaxe de objeto para CSS se tornou mais fácil para mim, às vezes sou preguiçoso e até passo esses estilos como estilo inline style={{styles.dialogTitle}} , é fácil refatorar depois

E pode ser usado de diferentes maneiras, com um wrapper de elemento como styled-components https://material-ui.com/styles/basics/#styled -components-api

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

Eu realmente gosto de componentes com estilo, mas descobri recentemente que ele apresenta uma série de problemas que dificultam o trabalho consistente de trepidação de árvores. Eu sei que a equipe do material-ui fez muito trabalho para que o tree-shaking funcionasse totalmente para esta biblioteca e, obviamente, qualquer regressão nisso deve ser evitada.

Felizmente, a maioria de seus problemas de trepidação de árvores são resolvidos usando babel-plugin-styled-components e definindo pure: true (consulte https://www.styled-components.com/docs/tooling#dead-code-elimination ). Mas ainda há alguns problemas remanescentes. Por exemplo:
https://github.com/styled-components/babel-plugin-styled-components/issues/245

Outra é que usar uma função auxiliar externa dentro de seus estilos pode quebrar a vibração da árvore (a menos que você configure terser/uglify para ignorar essa função específica), por exemplo:

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

Acho que deve ser possível corrigir todos esses problemas para que o tree-shake funcione corretamente, mas certamente pode ser complicado e não funciona apenas de maneira ideal fora da caixa, como as coisas estão atualmente. Na verdade, ainda acho que mudar para componentes com estilo pode ser uma boa ideia, mas apenas se esses problemas puderem ser resolvidos.

@mbrowne , não consegui reproduzir nenhum problema com componentes estilizados e de trepidação de árvores. O problema não inclui um exemplo reproduzível, então tentei replicá-lo com

// 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 */

com um padrão create-react-app . MyComponent não aparecerá no pacote de produção.

Isso é algo com o qual apenas rollup tem problemas? Gostaria de um exemplo reproduzível para entender o problema.

@eps1lon Acho que o problema aparece ao definir a propriedade estática no componente estilizado, você pode tentar isso?

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

Wrapper.displayName = "FancyName";

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

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

@mxstbr Sim, embora em ambos os casos o styled-components seja empacotado. Embora definir o displayName em MyComponent não inclua MyComponent no pacote, ele ainda inclui styled-components . Ele basicamente remove qualquer coisa feita em MyComponent e é por isso que eu originalmente pensei que fosse um shake de árvore adequado (apenas procurei por FancyName .

Mas ainda inclui styled-components . Mesmo se você considerar que uma ligação styled tem efeitos colaterais, eu consideraria

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";
}

como efeito colateral livre ao importar { OtherComponent } mas styled-components ainda aparecerão no pacote (isso é mesmo sem a macro). Então, ou isso é algum bug ou estou perdendo algo grande. Até

// 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();

incluirá styled-components (https://github.com/eps1lon/styled-components-shake).

Pode ser um bug em react-scripts, webpack ou styled-components. De qualquer forma, depurar esses problemas é incrivelmente difícil sem uma reprodução.

Faz sentido, obrigado por investigar isso.

Para este caso de uso, acho que não importa se styled-components está incluído no pacote (já que todos os componentes devem usá-lo), mas sim se os componentes que você não usa estão incluídos - o que não importa parece que é o caso, então isso é bom, certo?

@mxstbr Pode ser uma preocupação importante, temos alguns componentes sem estilo e genéricos (Modal, Popper, TextareaAutosize, useMediaQueries etc.), digamos que alguém use

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

com SASS. Esperaríamos um aumento de +5kB gzipado (a partir de hoje), não +20kB gzipado.

No entanto, assumindo que empurramos @material-ui/unstyled para a frente, na prática, pode não fazer nenhuma diferença, pois as pessoas podem usar este pacote.

@eps1lon Desculpe, pensei que o problema com propriedades estáticas seria mais fácil para outros reproduzirem, pois parecia afetar todos os nossos componentes... acontece que há muitas coisas diferentes que desencadeiam o problema, mas pelo menos em alguns casos simples funciona.

Eu criei uma demonstração reproduzível aqui:
https://github.com/mbrowne/CRA-error-template/tree/styled-components-tree-shaking
git clone --single-branch --branch styled-components-tree-shaking [email protected]:mbrowne/CRA-error-template.git

Observe como apenas a árvore do Component1 treme corretamente.

A boa notícia é que acho que esses problemas são todos solucionáveis, e @mxstbr parece muito engajado aqui. Estarei trabalhando em um PR em breve que abordará pelo menos o problema dos adereços estáticos (já tenho um POC funcionando usando um plug-in Babel separado que escrevi).

Eu abri um PR em componentes com estilo de plug-in babel para resolver os problemas de trepidação de árvores. Se alguém aqui quiser ajudar a testá-lo, imagino que @mxstbr seria bem-vindo (e eu também, é claro):
https://github.com/styled-components/babel-plugin-styled-components/pull/248

Olá a todos, onde está este bilhete atualmente? Eu ficaria mais do que feliz em me envolver e escrever alguns componentes estilizados para MUI se essa for realmente a direção que o projeto está seguindo na v5

Acho que a menos que queiramos fazer isso de uma só vez (duvido que queiramos isso). Devemos começar fazendo com que os componentes com estilo leiam o tema do jss ou o jss leia o tema dos componentes com estilo. O objetivo deve ser que possamos migrar estilos por componente.

Isso provavelmente deve acontecer em outro branch. Embora não queiramos alterar tudo no master de uma só vez, provavelmente deveríamos lançá-lo com uma alteração (na v5). Caso contrário, isso fica ainda mais confuso.

A exclusão do comentário foi solicitada.

Ei pessoal, estou pronto para contribuir também... um branch separado parece ser uma coisa sensata para nós fazermos... vamos fazer isso...!

@caprica-Six Obrigado pela energia, mas uma nova filial não é necessária. Devemos ser capazes de fornecer uma versão de componentes com estilo progressivamente (+ jss e emoção) (instável durante a v4) e avançar a história sem estilo ao mesmo tempo. Tenho um POC que preciso enviar. Componentes estilizados (v5 beta) + adereços dinâmicos são um pouco mais lentos do que temos com JSS e estilos estáticos, mas isso ainda deve ser aceitável.

@oliviertassinari existe algum lugar em que possamos nos envolver com isso? Eu estava meio que esperando um mantenedor me apontar na direção certa antes de pular em qualquer coisa

Por que você não prefere a emoção aos componentes de estilo? Parece que a razão é que "[emoção] é usado por poucas pessoas. Se você olhar para as estatísticas de download, 80% vem do livro de histórias?", mas isso está errado. É mais usado do que styled-components ( comparação ) e não vejo por que 80% dos downloads vêm do livro de histórias. Está claramente crescendo muito mais rápido do que o livro de histórias.

Faço essa pergunta porque estava cansado de usar componentes com estilo (por causa de vários problemas que estava encontrando) e procurei uma alternativa e descobri o Emotion. Eu testei e só encontrei vantagens em relação aos componentes com estilo.

É mais leve, mais rápido e tem mais funcionalidades: encaminhamento de propriedade, TypeScript pronto para uso (e perfeitamente compatível em comparação com componentes com estilo), Next.js SSR pronto para uso (sem ter que substituir o arquivo _app. js e _document.js, o que me levou uma hora para lidar com a primeira vez)

Além disso, é mais usado do que os componentes de estilo e tem claramente um impulso.

@lcswillems Acho que também devemos apoiar a emoção para as pessoas que a preferem. Mas não acho que deveria ser o padrão.

• "lighter": Não preciso: https://bundlephobia.com/[email protected] (12,2 kB) vs https://bundlephobia.com/result?p=@emotion/ styled + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (13,1 kB sem levar em conta as dependências compartilhadas)
• "Next.js SSR pronto para uso": acho que é um problema significativo, inlining

Obrigado pela sua resposta e me corrigindo.

• "lighter": você está certo
• "Next.js SSR out-of-the-box": agora eu entendo porque eles podem fazer SSR out-of-the-box e porque sua maneira de fazê-lo não é a boa.
• "mais usado que componentes com estilo": não tenho certeza se isso é confiável. Mas minha fonte pode não ser confiável também.
• "mais rápido": só vi benchmarks desatualizados, então não, não tenho um.

O principal problema que enfrento é o encaminhamento/filtragem de prop: https://github.com/styled-components/styled-components/issues/439 . Isso acontece com muita frequência comigo e é uma dor fazer a filtragem manualmente todas as vezes.

Mas com suas observações, a emoção parece não ser uma boa alternativa.

"lighter": Não preciso: https://bundlephobia.com/[email protected] (12,2 kB) vs https://bundlephobia.com/result?p=@emotion/ styled + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (13,1 kB sem levar

No caso de Emotion, provavelmente você não usará o pacote @emotion/styled em favor de css adereços + @jsx pragma. Além disso, você pode não precisar do pacote emotion-theming , o ThemeContext já está incluído no @emotion/core . Portanto, são 12,2 KB contra 6,5 ​​KB.

embutir

Apenas curioso: o que essas atualizações significam para os usuários da biblioteca @material-ui/styles para componentes não-MUI? Na minha empresa, estamos usando-o como base para uma grande biblioteca de componentes internos, escolhendo-o deliberadamente em vez de styled-components , e estamos muito felizes com isso.

Apenas pensei em verificar com antecedência se há algum tipo de descontinuação planejada para o pacote @material-ui/styles , para que eu possa planejar adequadamente.

De qualquer forma, obrigado por todas as ótimas coisas que vocês continuam fornecendo!

@nickjohnson-dev A migração para react-jss deve ser direta. Isso funcionaria para sua organização?

@oliviertassinari Acho provável que sim. Contanto que possamos manter a API pública dos próprios componentes praticamente a mesma ( classes substituições locais baseadas em prop, substituições globais possíveis no tema), não acho que seja um problema alterar os detalhes da implementação.

Você prevê que haja alguma documentação oficial para migrar de @material-ui/styles para as outras opções de estilo depois que o MUI for mais desacoplado? À primeira vista, não vejo nenhum recurso faltando em react-jss que estamos aproveitando em @material-ui/styles , mas não tenho certeza se estou perdendo algo especial que o pacote MUI está fazendo Por trás das cenas.

@nickjohnson-dev Faremos o nosso melhor.

Se eu entendi corretamente o seguinte problema irá ocorrer.
Temos o reutilizável ComponentA . Fazemos o ComponentB que usa 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)`
     ???
`;

Observe como ComponentA e ComponentB têm o elemento com o mesmo className='inner' . Como vamos segmentar o elemento $# .inner 7$#$ apenas em ComponentB ?

Olá @oliviertassinari , obrigado por compartilhar todo o pensamento por trás do estilo da próxima versão do Material UI.

E obrigado também pelo Material UI. Agora estou construindo um sistema de design em cima dele.

Em relação à adoção de styled-components , parece que é uma decisão tomada, e o trabalho para esse objetivo já começou.

No entanto, compartilho algumas das observações feitas por @croraf e @lcswillems

Algo ótimo do estilo atual da interface do usuário do Material é a propriedade classes .

É uma ideia simples que ajuda muito na customização e manutenção do estilo porque a digitação de classes faz parte da interface pública. Por exemplo, se eu precisar personalizar algo e usar um seletor como & .Component-root nada garante que Component vai manter essa classe css entre as versões. Por ter <Component classes={{root: ....}} /> pelo menos eu posso obter um erro de verificação de tipo (se estiver usando TypeScript) sobre a alteração da interface.

Como autor de componentes, posso decidir documentar classes que são públicas (e suportadas) e deixar outras não documentadas.

Usei style-components por cerca de 2 anos. É verdade que é popular e evoluiu muito. Mas, nos exemplos de documentação do MUI, vejo o mesmo problema que @croad menciona: usar um seletor descendente & .inner é muito frágil porque você pode propagar os estilos para subcomponentes (e pela minha própria experiência posso dizer isso não é um caso de canto... aconteceu comigo algumas vezes). Duas soluções possíveis são:

• Use &.inner e depois use ${props.className}.inner em todos os lugares. Eu fiz isso muitas vezes, e é doloroso escrever.
• Use > .inner , mas isso depende da estrutura do componente. Adicione um pouco mais div no meio e ele quebra.

É verdade que JSS não é popular. Eu aprendi sobre isso por causa do MUI. Mas depois de trabalhar por tanto tempo com styled-components , achei a abordagem dos estilos MUI refrescante e mais fácil de trabalhar (depois de um tempo ter o Styled HOC em todos os lugares adiciona muito trabalho extra e comecei a odiar aqueles HOCs... pelo menos essa é minha experiência pessoal). A emoção combina mais ou menos com a abordagem atual. E depois de ler seus comentários e alguns dos problemas sobre o desempenho do JSS em certos casos, estou avaliando o uso do Emotion para o sistema de design.

No entanto, vejo você tão convencido sobre styled-components que adoraria ver mais exemplos de como resolver a personalização de estilo usando adereços classes . Os disponíveis nos documentos MUI atuais compartilham os problemas que mencionei acima.

Existem outras maneiras de usar styled-components com a prop classes? Quais são seus pensamentos sobre isso?

JSS é bom o suficiente e é muito prático de usar. Existe algum motivo forte para se mudar?

Pessoalmente, acho que o styled-component é uma espécie de retrocesso e o JSS foi o principal motivo para eu começar a usar essa biblioteca para ser honesto.

@powerfulj Por que você prefere JSS sobre componentes com estilo? Eu tive que escolher entre os dois e styled-components pareciam melhores para mim.

@lcswillems
Eu gosto porque acho que não introduz um novo componente e, em vez disso, você apenas opera em propriedades. Se você realmente precisar de um novo componente reutilizável com estilo, poderá criá-lo facilmente com a solução JSS.

Também é mais rápido converter de estilo inline para estilo JSS, o que é conveniente para mim, pois costumo usar estilos inline durante a implementação e depois convertê-lo em JSS se ficar maior e reutilizado.

O lado negativo é que, se você tiver algum CSS (como de devtools do navegador) e precisar convertê-lo para JSS, terá que gastar mais algum tempo para ajustar a sintaxe. Com o styled-component, isso é mais rápido.

Apenas para compartilhar minha descoberta sobre esse problema.
Tentei migrar algumas demonstrações para componentes com estilo conforme exigido pelo #16947. O problema é com o tema padrão. makeStyles aceita opções onde defaultTheme pode ser passado. Há makeStyles wrapper que fornecerá defaultTheme . Então useStyles hook verificará se ThemeProvider fornece o tema e, caso contrário, injetará defaultTheme .

Parece que não existe essa funcionalidade em componentes com estilo. Na ausência de ThemeProvider defaultTheme só pode ser injetado com o método .attrs . Podemos criar algo semelhante a makeStyles wrapper

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

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

export default styled;

Mas o método .attrs apenas substituirá o tema fornecido por ThemeProvider se houver. E eu estou atualmente não sei como resolver este problema.

Outro problema é que makeStyles usa a predefinição jss-plugin-default-unit e parece que os styled-components não são. Portanto, os componentes com estilo não adicionam px retornar o valor da função spacing() .
A solução possível para o último problema é usar Styled-JSS e não styled-components.

Fico feliz em aqui suas idéias/sugestões.

@fyodore82 .attrs funciona como uma função (consulte https://www.styled-components.com/docs/api#attrs), então isso fará:

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

@croraf

Eu gosto porque acho que não introduz um novo componente e, em vez disso, você apenas opera em propriedades

Acho que você perdeu uma coisa muito legal dos componentes de estilo: o prop css . Ele permite que você adicione CSS a um componente sem ter que criar um novo.

Também é mais rápido converter de estilo inline para estilo JSS, o que é conveniente para mim, pois costumo usar estilos inline durante a implementação e depois convertê-lo em JSS se ficar maior e reutilizado.

Com o prop CSS, observe que um componente com prop CSS não tem um atributo style , ele já está convertido em um componente com estilo e, portanto, tem um class . Se o CSS ficar maior e reutilizado, você também pode criar um novo componente.

O lado negativo é que, se você tiver algum CSS (como de devtools do navegador) e precisar convertê-lo para JSS, terá que gastar mais algum tempo para ajustar a sintaxe. Com o styled-component, isso é mais rápido.

Eu concordo. Esta é a principal razão pela qual eu não usei. A maior parte do CSS escrito online é escrito em CSS, não em JSS. Portanto, se você quiser usar algum código do StackOverflow, precisará convertê-lo primeiro para JSS, o que é muito doloroso.

Outros argumentos adicionais que me fizeram usar Styled-components:

• É mais doloroso escrever JSS: você tem que adicionar aspas, você não tem realce de sintaxe (ou eu não consegui encontrar um).
• É mais difícil de entender para os recém-chegados. Todo mundo conhece CSS para que todos possam ler facilmente o código com componentes de estilo, o que não é o caso do JSS (a sintaxe do JSS geralmente é um pouco estranha e, em particular, para pseudoseletores e consultas de mídia).
• O código é muito menos legível. Para ilustrar este ponto, reescrevi este exemplo de componente Card com componentes Styled para mostrar o quanto mais claro pode ser com eles.

Versão 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>
  );
}

Versão de componentes estilizados:

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;
`

Por fim, não consegui encontrar nenhuma vantagem em usar JSS.

css é muito bom e basicamente resolve as desvantagens que mencionei. (copycats formam styled-components :D )

Em relação à comparação dos dois exemplos não acho muito legível e dobra o número de componentes.

@lcswillems

Não argumentando por uma solução ou outra, apenas pegando alguns dos seus pontos:

se você quiser usar algum código do StackOverflow, você precisa convertê-lo primeiro para JSS, o que é muito doloroso

Existe uma extensão VSCode para converter CSS em CSS-in-JS, embora nem sempre funcione perfeitamente. Independentemente disso, eu não chamaria isso de doloroso.

você não tem realce de sintaxe

Não entendo muito bem esse argumento. É apenas um objeto JS, então o realce de sintaxe de qualquer editor funciona:

(mas talvez você esteja procurando algo mais específico?)

Em relação à comparação dos dois exemplos, não acho muito mais legível. Embora a falta de props className seja indiscutivelmente mais limpa, não é óbvio no bloco de código JSX principal se os componentes se referem a componentes nativos de MUI ou reestilizados sem ter que fazer referência cruzada aos componentes styled() . Em um componente maior, estes poderiam ser removidos.

As invocações styled() são (para mim) menos legíveis do que o objeto JSS (embora eu imagine que você se acostuma com elas).

@powerfulj Por que você prefere JSS sobre componentes com estilo? Eu tive que escolher entre os dois e styled-components pareciam melhores para mim.

Porque eu sou um desenvolvedor Typescript e prefiro construir tudo no objeto Typescript. Especialmente eu odeio as cordas.

Embora precisemos transferir o código CSS para o código JSS devido à diferença, ainda prefiro ler o código JSS porque a estrutura se parece com o CSS tradicional (orientado a classes), gastaria mais tempo lendo o código do componente estilizado porque é mais longo e pode estar aqui e ali.

Acho que as pessoas reivindicaram essa mudança apenas porque têm experiência no componente Styled no passado. Isso me dá a sensação de "por que não escolhemos uma biblioteca com a qual estamos familiarizados, mas sem nenhum benefício óbvio?".

Do meu ponto de vista é como JSS é apenas útil, podemos organizar o objeto usando todas as formas de Javascript como

{
...sharedJSS1,
...sharedJSS2,
qualquer que seja
}

Também temos temas dinâmicos integrados com tipos e temos todas as dicas de tipo dos tipos className e css.

Para novos desenvolvedores, especialmente os desenvolvedores do Typescript simplesmente adorariam o JSS.

Para sua informação, é possível fazer alguns aninhamentos em componentes com estilo se você nem sempre quiser um componente separado para tudo. Geralmente é desencorajado, já que o uso de componentes separados com nomes significativos é considerado mais limpo e mais legível de acordo com a filosofia de componentes com estilo, mas os documentos dizem que é bom se "usado com moderação". E, claro, para quem não compartilha dessa filosofia, eles são livres para fazer mais ninhos. Como exemplo do que quero dizer com aninhamento:

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

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

Consulte https://www.styled-components.com/docs/faqs#can -i-nest-rules para obter mais detalhes.

As discussões sobre preferências de estilo de codificação podem continuar para sempre.

Depois de usar styled-components por um tempo, gosto mais da abordagem JSS, porque:

• Quando os estilos ficam mais longos, costumo movê-los para um arquivo separado.
  Eu fiz isso com styled-components também, e acho o useStyles / makeStyles mais fácil de escrever, ler e manter. Por exemplo. import useStyles from './MyComp.styles' vs import {XStyled, YStyled,...} from './MyComp.styles' ... manter essas variações ...Styled com suas tipagens em TS é chato.
• Costumo fazer as coisas de maneira progressiva: primeiro começo com um rascunho usando divs e classes e depois refatoro-os em componentes. Ao usar styled-components eu faço isso usando classes internas (como no exemplo de @mbrowne), mas requer mais trabalho de refatoração. Achei a abordagem useStyles muito mais confortável para trabalhar com esse fluxo de trabalho.
• Os literais de modelo são bons para colar código CSS, mas péssimos quando você precisa usar variáveis ​​de tema/propriedade. O problema de colar o código é fácil de resolver com um plug-in, mas editar com variáveis ​​e funções dentro do literal do modelo nem tanto.

Mas essas são minhas preferências pessoais, as suas podem ser diferentes.

Minha maior pergunta em aberto é sobre a mudança é o uso classes .

Os exemplos de uso de className e classes internas têm problemas (veja meu comentário anterior). A prop css em styled-components não é uma opção para resolver esses problemas. Ao contrário da função css no Emotion, o prop css depende de ser anexado a um componente (o que significa que você não pode usá-lo em um estilo de código useStyle/makeStyles/classes ).

A anexação de estilos a um componente não é uma decisão de projeto menor. Para mim, é o bom e o ruim do JSS. Componentes estilizados e Emotion contam com plugins Babel e interagem com React para lidar com cache e geração de nome de classe para SSR. A parte boa do JSS é que ele não precisa de nenhum plugin Babel. A parte ruim é que o SSR no JSS requer mais trabalho, e já vi bugs relatados nessa área.

De volta ao MUI, tenho a impressão de que adotar componentes de estilo significa usar className e classes internas como a única maneira de personalizar estilos. O estilo se torna mais consistente entre os frameworks: você pode usar styled ou css prop, desde que o componente use o className que você é bom.

Mas, para mim, remover o suporte classes é um passo atrás. Essa prop ajuda a documentar e digitar personalizações de estilo de verificação. Talvez seja possível encontrar um meio-termo, como usar styled-components, mas mantendo o suporte para classes (sem a necessidade do hack da classe interna). Não consegui encontrar nada na API de componentes com estilo que ajude nesse caso. Por isso pode ser bom avaliar quais são os problemas técnicos do JSS. Porque se a popularidade é o principal problema, o Emotion também está se tornando popular (consulte https://2019.stateofcss.com/technologies/css-in-js/#tools-section-overview), e pode ser fácil como uma maneira de reescreva makeStyles .

@dfernandez-asapp você fez alguns pontos excelentes apenas respondendo a uma pequena parte deste fwiw @styled-components suporta o uso de um objeto semelhante a jss em vez de uma string https://www.styled-components.com/docs/advanced# estilo -objetos

Embora seja bastante decepcionante, os componentes de estilo removeram o suporte a scripts datilografados de primeira classe e, em geral, concordo com você que parece um passo atrás nas outras maneiras que você descreveu

Para sua informação, é possível fazer alguns aninhamentos em componentes com estilo se você nem sempre quiser um componente separado para tudo. Geralmente é desencorajado, já que o uso de componentes separados com nomes significativos é considerado mais limpo e mais legível de acordo com a filosofia de componentes com estilo, mas os documentos dizem que é bom se "usado com moderação". E, claro, para quem não compartilha dessa filosofia, eles são livres para fazer mais ninhos. Como exemplo do que quero dizer com aninhamento:

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

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

Consulte https://www.styled-components.com/docs/faqs#can -i-nest-rules para obter mais detalhes.

Algum tipo de suporte para isso? Ou temos que colocar barbante em todos os lugares?

Não entendo por que há tanto hype para componentes com estilo. Parece um passo atrás para ser honesto. As propriedades CSS digitadas do JSS com TypeScript são muito mais convenientes e fáceis de manter, além de haver verificação de sintaxe como parte do JS - qualquer editor moderno/configurado informará se você cometer um erro de digitação e até mesmo o ajudará com a conclusão automática, se desejar.

edit: Está digitado, veja a resposta de South-Paw abaixo.

@martinjlowm parece que tem digitações para mim?

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

Você diz que não entende o hype... mas também não recebo todo o ódio que recebe. 🤷‍♂

Emotion e styled-components são grandes melhorias em relação aos objetos de estilo CSS IMO

@martinjlowm parece que tem digitações para mim?

...

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

Você diz que não entende o hype... mas também não recebo todo o ódio que recebe. 🤷‍♂

Emotion e styled-components são grandes melhorias em relação aos objetos de estilo CSS IMO

Eu vejo! Eu não sabia que suportava objetos assim. Minha preocupação estava relacionada ao CSS em strings de modelo - mas se os objetos são uma opção, não tenho nada contra isso!

Obviamente, o JSS também não é perfeito, eu sei - folhas reutilizáveis ​​geradas pelo servidor seriam um recurso matador - os componentes com estilo suportam isso de alguma forma? Alguém sabe?

No momento, parece estúpido ter que excluir as folhas de estilo geradas pelo servidor e forçar o cliente a renderizar novamente todos os estilos :(

@martinjlowm parece que tem digitações para mim?
...
Veja: https://styled-components.com/docs/advanced#style -objects
Você diz que não entende o hype... mas também não recebo todo o ódio que recebe. 🤷‍♂
Emotion e styled-components são grandes melhorias em relação aos objetos de estilo CSS IMO

Eu vejo! Eu não sabia que suportava objetos assim. Minha preocupação estava relacionada ao CSS em strings de modelo - mas se os objetos são uma opção, não tenho nada contra isso!

Obviamente, o JSS também não é perfeito, eu sei - folhas reutilizáveis ​​geradas pelo servidor seriam um recurso matador - os componentes com estilo suportam isso de alguma forma? Alguém sabe?

No momento, parece estúpido ter que excluir as folhas de estilo geradas pelo servidor e forçar o cliente a renderizar novamente todos os estilos :(

Também gostaria de esclarecer que literais de modelo marcados também podem ser digitados. O TypeScript os marcará corretamente como inválidos e o serviço de idioma fornecerá as sugestões de preenchimento automático, etc.

@Canhoto

Emotion e styled-components são grandes melhorias em relação aos objetos de estilo CSS IMO

Ainda estou confuso por que qualquer desenvolvedor React se interessaria por isso. Se você quiser colocar seu CSS em strings de modelo, por que você não usa Angular e coloca seu HTML em strings de modelo também? A força do React é que os elementos JSX são realmente apenas objetos JS que você tem muito poder para examinar e transformar, e o mesmo vale para JSS.

A coisa toda que impulsiona o movimento CSS no JS é o fato de que o JS é muito superior ao CSS para fazer coisas dinâmicas, e o poder dos objetos JS não é uma pequena parte disso.

O fato de styled-components suportar objetos é uma espécie de pista falsa:

• Ele os suporta, mas por algum motivo diz "Isso é particularmente útil quando você tem objetos de estilo existentes e deseja mover gradualmente para componentes com estilo". Eles aparentemente não vêem o valor em poder manipular objetos e parece que objetos de estilo sempre serão tratados como um cidadão de segunda classe em sua API.
• Os documentos não deixam claro se ele suporta seletores CSS do mundo real como este com JSS:

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

Até a Emotion respeita o valor dos objetos de estilo e os trata mais como um cidadão de primeira classe:

Escrever estilos com objetos é um padrão poderoso construído diretamente no núcleo da emoção.

@lcswillems você está subestimando o quão grande é o incômodo de criar todos esses pequenos HOCs o tempo todo (e o fato de que a maioria dos sistemas de importação automática não é inteligente o suficiente para saber se você deseja importar @material-ui/core/Card como Card ou MuiCard (e se você ainda estiver escrevendo declarações de importação à mão, estará desperdiçando muito seu tempo))

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;
`

Esse tipo de coisa causa uma terrível fadiga de decisão, pois você está constantemente tendo que decidir como nomear cada wrapper e componente encapsulado.

É disso que @dfernandez-asapp está falando quando diz:

(depois de um tempo, ter o Styled HOC em todos os lugares adiciona muito trabalho extra e comecei a odiar esses HOCs ... pelo menos essa é minha experiência pessoal)

HOCs praticamente precisam morrer. É um padrão obsoleto. Por exemplo, react-redux saiu com o gancho useSelector que é 100 vezes mais conveniente que o connect HOC, Apollo mudou de HOCs para ganchos, o mesmo vale para o useStyles gancho nesta biblioteca sendo mais conveniente do que withStyles .

O incômodo de converter CSS copiado e colado em JSS é um problema muito mais solucionável, se houver interesse, até farei uma extensão do VSCode para automatizá-lo ou um site.

se houver interesse até faço uma extensão do VSCode para automatizá-lo

@jedwards1211 Há paulmolluzzo.convert-css-in-js , mas se você puder melhorá-lo para JSS, tenho certeza de que seria bem-vindo.

Sim, parece que posso definitivamente melhorar isso, apenas converte propriedades CSS, não regras e seletores.

@jedwards1211 Eu li o que você disse, e dando um passo atrás de tudo isso por um momento - isso me lembra comentários de pessoas que discutem sobre o uso de guias sobre espaços. A realidade é que realmente não faz diferença o que você usa, desde que produza um produto útil no final.

Deixe suas opiniões / opiniões quentes no Twitter ou Reddit e podemos discuti-las por lá - mas não vamos continuar a inviabilizar esse problema com guerras inúteis em strings de modelo vs objetos para CSS ... Acho que todos podemos concordar que somos melhores que isso 😄

Obrigado por apontar que não vale a pena mudar o status quo no MUI? 😉

Minha principal preocupação é se meus pacotes de webpack ficam inchados com uma mistura de código de componentes estilizados e código JSS, porque há muito JSS existente em nosso aplicativo para arrancar e substituir por outra coisa e/ou porque eu gostaria de ficar com JSS para nossos estilos de qualquer maneira.

Para ser justo, porém, não me importo com tabulações versus espaços, mas se eu tivesse que escrever meia dúzia de HOCs para cada componente que faço, não estaria gostando do meu trabalho. Todas as ferramentas existentes têm a capacidade de produzir um produto útil; se algo fosse realmente perfeitamente conveniente para usar em todos os casos, não haveria mudança constante no ecossistema, e não estaríamos tendo esses debates. Então, realmente faz a diferença quando você pensa sobre isso.

@jedwards1211 mesmo que você seja forçado a usar componentes com estilo, há uma sintaxe alternativa css prop introduzida em v4 que você pode empregar - pelo menos, dessa forma, você não precisará se preocupar dando prefixos para componentes estilizados (MuiCard, StyledCard etc.).

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 seu exemplo também pode ser simplificado para o seguinte se você estivesse usando componentes estilizados

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

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

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

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

@koistya o prop css é bem legal, embora uma ressalva importante é que ele é implementado com um plugin Babel, então não é para todos, especialmente pessoas que usam tsc para compilar seus arquivos tsx. Também suponho que isso faria com que o TypeScript ou pelo menos o Flow reclamasse que o componente não possui css prop.

Acho que estou principalmente insatisfeito com a possível interrupção que isso causaria no meu aplicativo. @oliviertassinari mencionou outro dia que está pensando em tornar styled-components o padrão no MUI v5. E espero que seja opcional e o JSS ainda possa ser usado, mas veremos se eles podem fazer isso, você sabe. Foi um choque - realmente houve um referendo completo sobre as preferências de toda a base de usuários? Eu teria esperado Emotion se alguma coisa porque é muito mais popular agora.

Também suponho que isso faria com que o TypeScript ou pelo menos o Flow reclamasse que o componente não possui prop css.

Pode ser configurado.

Houve realmente um referendo completo sobre as preferências de toda a base de usuários?

Isto é impossível. Só podemos realmente supor que as pessoas envolvidas no GitHub são "nossos" usuários. Esta edição é a mais votada que já tivemos .

Eu teria esperado Emotion se alguma coisa porque é muito mais popular agora.

Como você mediu a popularidade?

⚠️ emoção é significativamente menos escolhida pelos desenvolvedores do que componentes de estilo (/6 pelo que me lembro). Se você considerar os downloads no npm, remova o livro de histórias e selecione as contagens de download (é enorme).

@eps1lon aqui está o que eu estava olhando: https://2019.stateofcss.com/technologies/css-in-js/

Eu estava errado, infelizmente, tudo o que me lembrava era da aparente tendência ascendente, mesmo que este não seja um gráfico de popularidade ao longo do tempo (design de gráfico muito questionável):

Pode ser configurado

Existe realmente uma maneira de fazer o TypeScript assumir que todos os elementos JSX suportam um prop css ? Não conheço uma maneira de configurar o Flow para fazer isso.

EDIT : felizmente encontrei um caminho para o TypeScript, não tenho certeza se existe um caminho para o Flow.

Esta edição é a mais votada que já tivemos.

Entendo. Suspirar

FWIW, um dos principais contribuintes para styled-components parece ter uma atitude hostil em relação aos sistemas de tipos:

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

Eu me sentiria muito mais tranquilo com a ideia de migrar para componentes com estilo se eles parecessem se importar com a experiência de desenvolvimento dos usuários do TS/Flow...

@jedwards1211 há uma macro Babel para css se isso ajudar. Especialmente vindo de css/scss/less, não acho que todo mundo goste de mudar para o caminho "estilizado".

Mas quais são os objetivos? E quanto ao desempenho? Por exemplo, alguns sistemas suportam CSS atômico. Vindo do Tailwinds, torna as coisas muito mais limpas e talvez mais rápidas.

@hc-codersatlas você pode encontrar alguns benchmarks em packages/material-ui-benchmark .

@koistya , se eu li corretamente, a emoção parece muito mais rápida que o resto.

@oliviertassinari a maioria dos desenvolvedores realmente "faz" essa escolha? De acordo com sua menção ao react-select e storybook, a maioria dos desenvolvedores provavelmente usará o que estiver empacotado com os componentes da interface do usuário e o material-ui sendo um grande 1. A menos que o pacote seja terrível, nenhum 1 aumentará o tamanho do pacote e gastará mais esforço com um sistema diferente em cima do que a estrutura de interface do usuário já está usando.

A maioria desses frameworks de interface do usuário são de grandes corporações, ou seja, algumas pessoas estão realmente fazendo essa "escolha".

por exemplo, o grommet usa componentes de estilo, que muitas empresas estão usando em 1 ponto.

E nessa nota o que significa downloads npm? O uso corporativo provavelmente significa firewalls e cache npm interno, o que distorce essas métricas.

Se houver uma mudança, mude para o melhor 1 com base no mérito técnico e não em algo como popularidade. Eu prevejo que, se o material-ui usar qualquer biblioteca, ela será a popular 1, já que mui é em si uma das estruturas de interface do usuário mais populares.

@South-Paw sua simplificação proposta não funcionaria, você não pode usar ${MuiCardContent} em seu exemplo porque MuiCardContent não é um componente de estilo.

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

Essencialmente, não há como evitar todos os wrappers HoC individuais. Embora depois de pensar sobre isso por um tempo, percebi que é basicamente a mesma quantidade de decisões de digitação/nomeação que se deve fazer com o JSS.

@mbrookes @oliviertassinari como os estilos condicionais e os estilos de componentes internos seriam tratados?
Por exemplo, o que seria um equivalente baseado em styled-components do seguinte?

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

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

Acalmei-me com a ideia de mudar para styled-components , mas quero ter certeza de que há um plano sólido para lidar com esses tipos de casos de uso, porque suponho que a API teria que ser muito diferente ou depender em nomes de classe de estilo BEM.

@jedwards1211 ah meu erro. Fiquei com a impressão de que o exemplo era se eles fossem componentes estilizados - mas na verdade isso não funcionará se não forem 👍

@ jedwards1211 clsx é algo que eu vi emparelhado com componentes estilizados no passado para classes condicionais - é isso que você quer dizer?

Os projetos que estou fazendo no momento usam componentes com estilo que envolvem componentes MUI conforme necessário, portanto, não usei nenhum estilo condicional de MUIs.

@South-Paw que (ou classnames ) poderia ser um detalhe interno da solução, mas o que quero dizer é que styled-components wrappers injetam apenas um único className AFAICT, haveria não é realmente uma maneira conveniente de passar vários nomes de classe de substituição em um componente. Em vez disso, podemos ter que fazer algo como <Dialog Paper={StyledPaper}>...</Dialog> , e eu nem tenho certeza do que para o exemplo de classe MenuItem selecionado.

@jedwards1211 você teria tempo para fazer um exemplo rápido para que eu possa entender melhor qual é o caso de uso que você está descrevendo e onde você acha que está o problema? Eu gostaria de poder tentar ajudar com uma solução, mas ainda não entendo a que isso se aplica 😄

Sim, estou sem tempo esta noite, mas amanhã eu vou.
Também tenho trabalho em andamento em jss-codemorphs , planejando finalmente fazer uma extensão VSCode para converter CSS colado em JSS.

nunca fui fã da sintaxe dos componentes com estilo ou da forma como o pacote é mantido, não sou fã dessa proposta. Uma das coisas que mais gosto no material ui é a solução de estilo atual.

É interessante notar que eu li que o Facebook também pode estar abrindo o código de uma solução CSS-in-JS. Pode ser valioso dar uma olhada nisso também quando for lançado.

Sobre o tema real em questão. Não gosto de componentes com estilo devido à experiência do Typescript não ser ótima. Os tipos costumam fazer mais mal do que ajudar. Tempos de compilação lentos, interfaces insanas (tentar entender como os componentes de estilo funcionam através da interface é um pesadelo devido a todas aquelas mágicas Pick aninhadas). Desde que styled-components tenha esse tipo de DX, seria um retrocesso para o material-ui adotar isso.

É interessante notar que eu li que o Facebook também pode estar abrindo o código de uma solução CSS-in-JS.

@venikx Qual a probabilidade de isso acontecer? A última vez que ouvi falar de algo que poderia sugerir isso foi em https://reactpodcast.simplecast.fm/75 , parecia ser um objetivo de 5 anos.

Uau! Sério? Eu não sabia que eles já deram uma “linha do tempo”. Por alguma razão, eu assumi que viria ao mesmo tempo com o Modo Concorrente. Que pena.

Dito isto, meu ponto sobre componentes de estilo ainda permanece. Eu prefiro usar a maneira de lidar com estilos do material-ui puro em vez de usar componentes com estilo. As tipagens de styled-components parecem estar lá para o compilador e não tanto para documentação.

Outra coisa irritante (mas provavelmente é novamente uma preferência pessoal) é como você lida com a aplicação dinâmica de estilos a um componente. Eu prefiro adicionar ou remover classNames em vez de incorporar essa lógica no componente com estilo.

Material-ui api está realmente limpo no momento imho.

Não gosto de componentes com estilo devido à experiência do Typescript não ser ótima.

Eu usei styled-components e Typescript juntos em pelo menos 4 projetos grandes até agora e não tive nenhum problema com os tipos - eles podem ser um pouco complicados ao fazer coisas em uma biblioteca de componentes, mas isso seria no final dos MUIs - não do lado dos consumidores.

Tempos de compilação lentos

Eu não experimentei isso em nenhum projeto em que trabalhei que os use - você tem um exemplo em algum lugar do que você quer dizer?

interfaces insanas (tentar entender como os componentes de estilo funcionam através da interface é um pesadelo devido a todas aquelas mágicas de escolha aninhadas)

Você também pode considerar contribuir para o projeto @types se achar que pode melhorá-los de alguma forma - tenho certeza de que todos apreciariam qualquer trabalho lá se for uma melhoria em relação ao que existe agora!

Eu prefiro adicionar ou remover classNames em vez de incorporar essa lógica no componente com estilo.

Não há nada que o impeça de usar classes com componentes com estilo:

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 })} />

Vale a pena notar que, apesar de alguns comentários afirmarem o contrário, há 150 👍 e 27 🎉 na questão dos pais e apenas 18 👎 e 9 😕. Parece que há uma minoria vocal que não gosta dessa discussão e uma maioria que acha que é um passo positivo 🤷‍♂

@South-Paw o problema com a votação é que a única opção é: JSS vs styled-components. A parte vocal é sobre não gostar de componentes com estilo e não que eles gostem de JSS. Talvez se o voto

No final do dia, qualquer coisa é melhor que JSS. É velho. É lento e volumoso (tamanho do pacote) e deve ser movido. Portanto, os votos não apoiam sua conclusão.

Vocês poderiam passar para o chat do Spectrum ou algo que não preencha esse problema com o barulho de pessoas brigando entre si para ver quem ganha a discussão?

Estou seguindo o tópico para discussões sobre este tópico da equipe principal.

Acho que você está subestimando o julgamento da equipe principal e, pessoalmente, sinto que você deveria parar de discutir sobre esse assunto e confiar mais na equipe principal; no final do dia, cabe à equipe principal decidir a direção da interface do material.

Se você realmente se sente fortemente opinativo sobre isso, o Material UI é incrivelmente licenciado pelo MIT, faça um fork e continue com a visão que você tem, eu encorajo você a fazê-lo, talvez aprendamos no futuro com o ambiente diversificado.

Mas, por favor, eu imploro, deixe a equipe principal fazer seu trabalho, confie neles, porque são pessoas realmente competentes com habilidades incríveis.

Aqui está algo bonito de se ver

No final do dia, qualquer coisa é melhor que JSS. É velho.

@hc-codersatlas old == maduro -- você poderia explicar por que isso é um problema?

Ok, parece um problema importante, mas alguém pode confirmar esta informação simples: atualmente é possível usar uma sintaxe semelhante a styled-components , com literais de modelo marcados que se parecem com CSS, nas versões atuais do Mui (4 ou 5) ?
Não consegui encontrar uma resposta clara de sim ou não para essa pergunta. Eu realmente não me importo com a tecnologia subjacente, apenas com a conveniência do desenvolvedor. Copiar e colar CSS do InVision é basicamente bastante útil em alguns casos.

Este problema é sobre a solução de estilo usada no Material-UI, sua pergunta parece ser sobre como você estiliza seu aplicativo / reestiliza os componentes, para os quais você pode usar qualquer solução:

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

JSS tem suporte básico para literais de modelo como um plug-in.

Acabei de implementar um conversor CSS para JSS muito abrangente:

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

Espero que isso resolva o incômodo de copiar e colar CSS em estilos JSS.

@jedwards1211 veja isso
https://css2js.dotenv.dev/

@nainardev Percebi que e outros utilitários são muito limitados, eles convertem atributos CSS, mas não convertem seletores, seletores aninhados, quadros-chave de animação, consultas de mídia, etc. Por isso fiz minha ferramenta muito abrangente, ela pode converter espero que qualquer CSS completo que você jogue nele.

Pode ter perdido isso respondido em algum lugar, mas quero aumentá-lo de qualquer maneira. Estamos migrando para os componentes do Material UI e avaliando nossa solução de estilo ( less vs makeStyles vs styled-components ), a maior parte do nosso estilo é feita com menos files e a maior parte do novo código MUI está usando makeStyles , o que eu quero saber esclarecer é, já que isso fará parte da v5, o que podemos fazer para reduzir a dívida técnica em torno do estilo?

1. makeStyles estará disponível na v5? Como funcionará com styled-components e temas? Por exemplo, como isso ficará com styled-components :

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

1. (v4) Existe uma maneira melhor de recuperar o objeto theme em uma string de modelo com estilo do que isso, para que eu possa usá-lo várias vezes?

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

1. Supondo que makeStyles esteja presente na v5, devemos esperar algum impacto no desempenho se estivermos usando o provedor de temas styled-components e o provedor de temas Material UI para uma grande base de código?

Adoro usar o Material UI, obrigado por todo o trabalho duro!

@egilsster

1. Sim, seja de @material-ui/styles ou react-jss, veremos.
2. Sim 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. Os principais problemas são 1. sobrecarga de configuração, custo de uma vez, 2. carregamento de dois tempos de execução CSS-in-JS, que tem uma sobrecarga de ~ 15 kB gzipada, um custo semelhante, digamos, incluindo Sentry: https://bundlephobia.com /resultado?p=@sentry/browser.

Obrigado por uma resposta rápida, muito apreciado.

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

Isso é bem legal. Algum trabalho em torno de ferramentas provavelmente seguiria isso, o projeto que estou migrando não está usando TS, mas o VSCode / servidor de idiomas parece não ter ideia do que theme é neste caso e eu perco styled-components destaque de sintaxe também.

Obrigado mais uma vez, continuarei acompanhando este desenvolvimento.

@oliviertassinari se houver uma migração para componentes com estilo, isso significa que não podemos mais confiar em APIs CSS como <ListItem classes={{ selected: myCustomClassName}}> ?

@jedwards1211 A API classes permanecerá.

OK. Estou um pouco confuso como o MUI usaria componentes com estilo internamente, pois os componentes com estilo só podem aplicar uma única classe ao elemento raiz.

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>
  );
}

Isso faz sentido @jedwards1211 ?

@yordis Eu sei que parece simples, mas como você refatoraria seletores compostos como https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/Button/Button.js #L75 ?

Eu realmente não consigo pensar em uma maneira de preservar esse comportamento existente com styled-components , então isso pode causar mais alterações do que as pessoas esperam.

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

O código existente e as substituições personalizadas das pessoas provavelmente também dependem da especificidade do CSS em alguns casos.

Talvez isto? Não tenho certeza de seguir, pois isso parece básico para mim, provavelmente estou perdendo algum contexto e/ou informação.

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

<MyOutlinedComponent disabled/>

@yordis possivelmente. Como eu disse, embora as pessoas provavelmente não estejam pensando em quantas alterações isso causará aos usuários, não acho que esse exemplo impediria as alterações.

Você se importaria de compartilhar exemplos reais e mudanças reais em potencial?

É difícil segui-lo quando você não compartilha casos fortes. Com base em suas mensagens, acho que você não entendeu completamente este tópico, ou posso estar fazendo julgamentos errados. Por favor me ajude a entender, posso ser o errado.

@oliviertassinari as substituições de tema ainda funcionarão sem modificação na v5? Para que o exemplo de substituição a seguir funcione, parece que o MUI ainda teria que aplicar nomes de classe gerados por JSS além de um nome de classe raiz gerado por styled-components .

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

@yordis tendo pensado mais sobre isso, percebi que seletores compostos para estilos passados ​​via classes ainda funcionariam, felizmente. Não tenho certeza sobre os estilos de substituição de tema.

Eu tive o prazer de usar ambos os componentes com estilo sobre o MUI, juntamente com o estilo simples do MUI usando style={object}.

Pegue uma página de lista de resultados, que contém 50 cartões, cada um com carrosséis de mídia, informações, manipuladores de cliques, botões etc.

O uso de componentes estilizados adicionou quase meio segundo ao tempo de renderização; em comparação com const useStyles = makeStyles ou style={object}.

Vou ter que aceitar o resultado desse planejamento de roteiro; mas definitivamente causará uma torção em nossos planos de adoção da interface do usuário se não for substituível por outra coisa completamente de cima para baixo.

@Icehunter você poderia postar seus resultados e um projeto de amostra online para que as pessoas vejam?

@Icehunter você poderia postar seus resultados e um projeto de amostra online para que as pessoas vejam?

Projeto de amostra seria difícil, pois conteria código proprietário. Em breve, postarei uma imagem renderizada e a seção de resultados de tempo da guia de desempenho.

Pegue uma página de lista de resultados, que contém 50 cartões, cada um com carrosséis de mídia, informações, manipuladores de cliques, botões etc.

@Icehunter você está enviando algum adereço para esses estilos? sejam 50 cartões ou 500 cartões o número de classes geradas deve ser o mesmo. parece que seu exemplo específico contém código proprietário que não pode ser compartilhado, mas seria possível reproduzir esse problema com código que você pode compartilhar?

As APIs styled() / styled.div adicionam sobrecarga à renderização de _every_ elemento, portanto, mesmo com o armazenamento em cache de nomes de classes, pode ser mais lento. Com makeStyles você pode anexar um grupo de estilos uma vez e então apenas aplicar os nomes das classes manualmente, o que geralmente é significativamente mais rápido.

Eu montei um exemplo do CodeSandbox para ilustrar que soluções baseadas em componentes estilizados styled podem ser 3-4x mais lentas que um MUI makeStyles :

styled APIs são boas por conveniência, mas concordo com o sentimento de @Icehunter de que pode ser uma preocupação de desempenho quando usado fortemente em listas/tabelas. É bom ter makeStyles como backup.

@schnerd Obrigado por reunir esses exemplos, isso ilustra muito bem a preocupação. Assim como uma nota lateral, pense antes do post com "Não é difícil de ver ..." pode parecer meio condescendente e realmente não contribuiu para um excelente conjunto de exemplos

@tuxracer desculpas – atualizado.

@Icehunter Não entendo o que você quer dizer com isso, você usou os estilos comuns com SC ou JSS?

@Icehunter Não entendo o que você quer dizer com isso, você usou os estilos comuns com SC ou JSS?

Ambos na verdade. Acabamos indo com makeStyles, mas isso ou usar styled={object} nos deu os mesmos resultados de desempenho.

Estamos em um processo de migração para obter melhor desempenho em toda a biblioteca de componentes e no site principal.

Em termos de pilha, está escrito em nextjs.

Só para ficar claro (editar):

Eu usei SC como pretendido, envolvendo componentes mui. Ficou muito lento.

Então eu usei componentes mui usando makeStyles e/ou style={object} de uma configuração de arquivo compartilhado e local (cascata simulada). Muito muito mais rápido.

Eu não quero bloquear essa ideia de forma alguma; mas se for padrão; então deve haver uma maneira de substituir globalmente de cima para baixo a escolha padrão e injetar a sua própria.

Talvez isto? Não tenho certeza de seguir, pois isso parece básico para mim, provavelmente estou perdendo algum contexto e/ou informação.

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

<MyOutlinedComponent disabled/>

Talvez eu esteja atrasado para este jogo. Mas acho que @jedwards1211 está procurando uma maneira de como isso pode ser expresso com SC: https://codesandbox.io/s/magical-snow-5bzd8

Eu mesmo tenho isso em alguns lugares. Então seria bom se fosse simples migrar para v5 quando esse dia chegar

Na verdade, não tenho certeza de como algo assim funcionará usando componentes com estilo.

Por exemplo, se o Material UI suportar a substituição das variantes padrão de Typography no futuro, acho que o JSS é mais fácil do que os componentes com estilo.

@heb-mm há um RFC detalhado aqui que @oliviertassinari mencionou este tópico no dia 7 de março.

Levei menos de um minuto para rolar para cima e ver a menção.

Edit: para aqueles que se perguntam, heb-mm apagou seu comentário agora.

Eu montei um exemplo do CodeSandbox para ilustrar que soluções baseadas em componentes estilizados styled podem ser 3-4x mais lentas que um MUI makeStyles :

@schnerd Atualizei seu benchmark para incluir a API interna do Material-UI styled que deve imitar styled-components . Fiquei surpreso ao ver como é incrivelmente lento em comparação com as outras opções. Veja https://codesandbox.io/s/css-in-js-comparison-ljtjz?file=/src/App.js

Alguém sabe se @emotion/styled (que tem basicamente a mesma API que styled-components) seria igualmente lento? Eu só estou querendo saber se há alguma coisa sobre sua implementação que possa ser melhor otimizada.

Alguém sabe se @emotion/styled (que tem basicamente a mesma API que styled-components) seria igualmente lento? Eu só estou querendo saber se há alguma coisa sobre sua implementação que possa ser melhor otimizada.

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

Tão rápido quanto os componentes estilizados. Ainda não tão rápido quanto makeStyles. O problema que vejo na maior parte é a criação de objetos e as diferenças de armazenamento em cache/memoização de objetos.

Hmm, isso pode atrapalhar um pouco nossos planos de migração para o MUI. No momento, estamos nos afastando de styled-components em favor do sistema de estilo Material UI depois de enfrentar muitos problemas para gerenciar nosso CSS, temas e desempenho. styled components foi bom no começo, nós construímos nossa própria solução de temas em cima dela, mas quando a interface do usuário cresceu, o CSS também. Usamos TypeScript, então o fato de podermos refatorar facilmente um objeto JS em vez de uma string CSS inline foi um grande ponto de venda. 😕

Então, eu sou muito novo no Material UI e também acabei de ver o lançamento alfa da v5. @ldego08 você disse:

No momento, estamos nos afastando dos componentes de estilo em favor do sistema de estilo Material UI

Eu costumo usar componentes com estilo ao trabalhar com react. Qual é o sistema de estilo do Material UI e qual é a maneira recomendada de usar estilos e CSS no Material UI daqui para frente? Eu li esta página e não está claro para mim se você é a favor do CSS-IN-JS ou não: https://material-ui.com/system/basics/. Eu geralmente prefiro escrever CSS não em sintaxe de objeto, e tenho gostado dos benefícios de usar CSS-IN-JS, já que você pode usar "sintaxe css normal", mas também tem o poder do JS à mão.

Obrigado por qualquer ajuda para continuar!

Não sei por que a API de componentes com estilo é tão popular. É mais lento, você precisa envolver tudo no componente em vez de apenas gerar o nome da classe. E também, qual é o problema com literais de modelo marcados? Não queríamos escrever css em arquivos css, porque é muito melhor escrevê-lo em string javascript? :D A sintaxe do objeto é muito mais poderosa quando se trata de composição e refatoração, etc. Para mim, as funções css e cx de emoção simples que pegam o objeto css e retornam o nome da classe são a API mais flexível e poderosa. Então, simplesmente gerar nomes de classes com emoção e usar a API de classes é super flexível e poderoso. Então, eu não entendo por que você trocaria desempenho e flexibilidade por "API de desenvolvedor mais conveniente" (para algumas pessoas, para mim, é uma API terrível).

Não sei por que a API de componentes com estilo é tão popular. É mais lento, você precisa envolver tudo no componente em vez de apenas gerar o nome da classe. E também, qual é o problema com literais de modelo marcados? Não queríamos escrever css em arquivos css, porque é muito melhor escrevê-lo em string javascript? :D A sintaxe do objeto é muito mais poderosa quando se trata de composição e refatoração, etc. Para mim, as funções css e cx de emoção simples que pegam o objeto css e retornam o nome da classe são a API mais flexível e poderosa. Então, simplesmente gerar nomes de classes com emoção e usar a API de classes é super flexível e poderoso. Então, eu não entendo por que você trocaria desempenho e flexibilidade por "API de desenvolvedor mais conveniente" (para algumas pessoas, para mim, é uma API terrível).

Eu tive a mesma preocupação :) talvez esclareça um pouco as coisas:
https://github.com/mui-org/material-ui/issues/6115#issuecomment -580449539

@martinjlowm Sim, estamos na mesma página :) Eu acho que a maneira mais inteligente de ir para a equipe de material UI é implementar algum tipo de solução conectável e não acoplar com qualquer solução css em js, deixando as pessoas escolherem o que usar e salve algum tamanho de pacote dessa maneira. E também manter classes e API createMuiTheme, porque essa é a parte mais poderosa dela. Para mim, css em js é sobre estilo dinâmico fácil com base no estado do componente, confiança ao refatorar ou excluir css ou componentes inteiros (é onde a abordagem do objeto é superior), desempenho (não baixar vários estilos não utilizados de várias folhas de estilo externas) , etc. E, novamente, não entendo por que as pessoas gostam de escrever string com algum destaque do editor. Quer dizer, você tem que usar ${} para acessar props do contexto. Para qualquer coisa mais complexa do que definir o elemento div de fundo, essa abordagem é confusa e não legível na minha opinião. Não estou criticando, apenas dizendo o que penso e tentando provar um ponto que nem todo desenvolvedor gosta de componentes com estilo e, mesmo que gostassem, não vejo como é um bom negócio trocar desempenho e flexibilidade por isso :)

@vdjurdjevic De fato, acoplar material-ui a uma solução css em js é quase uma receita garantida para conflito quando as práticas css-in-js inevitavelmente crescem em direções diferentes.

Que tal algum padrão de adaptador que aplica estilo com um provedor css-in-js específico? Os estilos em si devem ser definidos em um formato consistente dentro dos pacotes material-ui. É a aplicação desses estilos que é realizada de forma diferente pelos adaptadores correspondentes.

Algo na linha de:

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

@vdjurdjevic Eu concordo com seus pensamentos em https://github.com/mui-org/material-ui/issues/6115#issuecomment -652762320. Você pode gostar deste resumo da direção que estamos tomando, que compartilhei recentemente em https://github.com/mui-org/material-ui/issues/16947#issuecomment -653797178.

Eu não entendo por que as pessoas gostam de escrever string com algum editor destacando

Algumas razões do meu ponto de vista:

• Perto de por que não escrevemos React.createElement('div', {}) .
• Pessoas com experiência limitada no desenvolvimento web (são muitas) lutam para aprender a API JavaScript, parece mais simples com a sintaxe CSS. Tome os designers como exemplo, pergunte aos da sua equipe o que eles pensam sobre isso :).
• Não é possível copiar e colar entre ferramentas de desenvolvimento e fonte (eu odeio este).

@oliviertassinari Ok, esses são alguns pontos sólidos, eu concordo :) Mas ainda assim, para mim (não um designer, não um iniciante, desenvolvedor sênior), componentes com estilo e literais de modelo marcados nunca seriam uma opção. Eu li seu resumo para a direção de desenvolvimento adicional e estou feliz em saber que o mecanismo css será opcional. Eu não me importo com styled-components como padrão (se é isso que a maioria dos usuários gosta), desde que eu possa mudar isso. E para ser honesto, acho que vou me ater ao JSS com v4 para o meu próximo projeto, ele tem alguns recursos interessantes (como expandir e compor plugins). Eu tive que escrever plugin stylis para emoção para ter algo semelhante.

PS. Eu também não sou grande fã de JSX :) Rapidamente fica confuso, você acaba com código de seta e para componentes que devem renderizar elementos dinâmicos, você não tem escolha a não ser usar createElement. Não estou dizendo que trabalhar diretamente com createElement é melhor, apenas dizendo que JSX não é o ideal. Na minha opinião, o Flutter tem o melhor DX, espero que um dia consiga lidar bem com a plataforma web.

@oliviertassinari De acordo com nossos testes de desempenho em andamento, conforme observado em https://github.com/mui-org/material-ui/issues/6115#issuecomment -643398897 Eu só espero que a equipe de materiais não escolha apenas componentes estilizados porque é popular. É lento. Sempre foi. Pessoalmente, é um ponto de ser um dev que você precisa aprender coisas como notação JS de CSS.

Faz parte do trabalho.

Facilitar a vida dos devs é parte do nosso trabalho como mantenedores de pacotes (para meus próprios projetos dos quais estou falando), mas existe uma linha entre facilitar e tornar o desempenho.

É por isso que eu só uso makeStyles e sempre usei desde que foi lançado.

Meu último arquiteto de equipes não quis ouvir e seguiu em frente com componentes estilizados e agora o site está lento. Mudei para makeStyles em um branch de teste e economizei 50% (10 segundos) em TTI em dispositivos móveis, mas assim como você disse naquele comentário, a notação JS não é conhecida por todos, então não foi aceita.

Internamente, o material pode escolher o que quiser, mas, por padrão, torne-o com bom desempenho.

[Pergunta movida para StackOverflow.]

@haysclark Por favor, use o StackOverflow para perguntas de suporte, em vez de encaixá-las em um RFC.

@haysclark Por favor, use o StackOverflow para perguntas de suporte, em vez de encaixá-las em um RFC.

@mbrookes Obrigado pelo aviso!

Alguém sabe se @emotion/styled (que tem basicamente a mesma API que styled-components) seria igualmente lento? Eu só estou querendo saber se há alguma coisa sobre sua implementação que possa ser melhor otimizada.

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

Tão rápido quanto os componentes estilizados. Ainda não tão rápido quanto makeStyles. O problema que vejo na maior parte é a criação de objetos e as diferenças de armazenamento em cache/memoização de objetos.

Eu queria saber qual seria o desempenho do componente Box comparado ao seu perfil, e adicionei o Box do Chakra-UI para uma boa medida, e os resultados foram... surpreendentes :P
https://codesandbox.io/s/css-in-js-comparison-forked-mg3gx?file=/src/App.js

@Nvveen você tentou Chakra-UI v1? Foi reescrito e espero que seja melhor. Há também emoção v11, embora ainda em beta.

@Nvveen você tentou Chakra-UI v1? Foi reescrito e espero que seja melhor. Há também emoção v11, embora ainda em beta.

Apenas tentei com o RC mais recente, mas nenhuma diferença perceptível; ainda é cerca de 1,5x a 2x mais lento que o SC normal. A maior pergunta para mim é por que o MUI Box é tão lento.

@Nvveen você tentou Chakra-UI v1? Foi reescrito e espero que seja melhor. Há também emoção v11, embora ainda em beta.

Apenas tentei com o RC mais recente, mas nenhuma diferença perceptível; ainda é cerca de 1,5x a 2x mais lento que o SC normal. A maior pergunta para mim é por que o MUI Box é tão lento.

Ele usa Jss. SC é pelo menos um pouco melhor.

Na minha máquina, a ordem em que os casos de teste são executados afeta os resultados. Comparar

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

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

Coleta de lixo @oliviertassinari e jit da v8 é o que está causando isso. Melhor ter execuções de teste isoladas / separadas realmente. Os testes posteriores têm um jit melhor, mas de vez em quando aciona a coleta de lixo.

Parece que Emotion, SC e Chakra estão todos perto de um desempenho máximo teórico para quando cada pequeno componente tem seus próprios estilos para montar, com o estilo MUI ainda não totalmente otimizado. Parece que a única maneira de obter um desempenho melhor do que isso é ter uma folha de estilo para toda a árvore de componentes como em makeStyles/CSS puro. Eu acho que os 30 ms adicionais para emoção, SC etc. são a sobrecarga inevitável de cada pequeno componente ter que garantir que seus estilos estejam montados.

@jedwards1211 se for para manter o dx, a Atlassian fez uma lib que compila para css, chamada compilada