Material-ui: [RFC] Solução de estilo v5 💅

Criado em 24 ago. 2020  ·  105Comentários  ·  Fonte: mui-org/material-ui

Este RFC é uma proposta para alterar a solução de estilo do Material-UI na v5.

TL: DR;

Qual é o problema?

  • Manter e desenvolver um excelente mecanismo de estilização leva um tempo considerável. Nós experimentamos isso em primeira mão. Nos últimos 12 meses, preferimos investir tempo em nossa proposta de valor principal: os componentes da IU, em vez de melhorar o mecanismo de estilo. Trabalhar nisso tem um alto custo de oportunidade.
  • Temos enfrentado problemas com o suporte de estilos dinâmicos para os componentes. O desempenho de nossa implementação de estilos dinâmicos personalizados (com base em adereços) não é ótimo (consulte os benchmarks de desempenho abaixo). Isso está limitando seriamente a qualidade da Experiência do Desenvolvedor que podemos oferecer. É um bloqueador para melhorar nossa API em torno da personalização ou facilidade de escrever estilos. Por exemplo, ele irá desbloquear: adereços de utilitários de estilo , variante de cor e variante personalizada .
  • A comunidade React, em geral, não votou a favor do uso de JSS em escala (JSS é ótimo e ainda é usado). Há 3 anos apostamos na melhor opção disponível . Temos que reconhecer que melhores opções estão disponíveis agora. Podemos nos mover mais rapidamente e desbloquear DX / UX melhores construindo sobre uma solução de estilo mais popular e existente.
  • Muitos desenvolvedores usam componentes estilizados para substituir os estilos da interface do usuário do material. Os usuários finais encontram-se com duas bibliotecas CSS-in-JS em seu pacote. Nada bom. Seria melhor se pudéssemos oferecer adaptadores diferentes para diferentes bibliotecas CSS-in-JS. (Problemas potenciais: podemos precisar reescrever os estilos principais para corresponder à sintaxe do mecanismo usado 🤷‍♀️)

Quais são os requisitos?

Qualquer que seja o mecanismo de estilo que escolhermos, devemos considerar os seguintes fatores:

  • desempenho: quanto mais rápido, melhor, mas estamos dispostos a negociar algum desempenho para melhorar o DX.
  • tamanho do pacote: abaixo dos nossos atuais 14,3 kB compactados em
  • suporta modo simultâneo: @material-ui/styles tem suporte parcial enquanto escrevo.
  • suporte SSR
  • personalização simples
  • permitir estilo dinâmico
  • bom tamanho da comunidade
  • tema
  • especificidade plana
  • RTL
  • TypeScript

Seria bom se ele pudesse suportar o seguinte:

Quais são nossas opções?

  • componentes estilizados
  • emoção
  • JSS (atualmente embrulhado em material-ui)
  • estiletron
  • Afrodite
  • fela
  • outro?

Comparação

atuação

Aqui estão benchmarks com estilos dinâmicos de várias bibliotecas populares (observe que o Material-UI v4 usa apenas estilos estáticos que têm bom desempenho ):

PR para referência: https://github.com/mnajdova/react-native-web/pull/1

Com base no desempenho, acho que devemos eliminar: JSS (atualmente envolvido em @ material-ui / styles), styletron e fela. Isso nos deixaria com:

  • componentes estilizados
  • emoção
  • Afrodite
  • JSS
  • reac-estiletron
  • fela

Adereços dinâmicos

Com base nos problemas em aberto, parece que Afrodite não suporta adereços dinâmicos: https://github.com/Khan/aphrodite/issues/141
o que na minha opinião significa que devemos retirá-lo de nossas opções também, deixando-nos com:

  • componentes estilizados
  • emoção
  • Afrodite
  • reac-estiletron

npm

Embora styled-components e emotion sejam ambas bibliotecas bastante populares, react-styletron na época ou escrita está muito atrasada, com cerca de 12.500 downloads por semana (isso na minha opinião é um forte motivo por que devemos eliminá-lo, se decidirmos ir com ele, a comunidade precisará novamente ter dois mecanismos de estilo diferentes em seus aplicativos).

Aqui está a lista variada pelo número de downloads semanais no momento da escrita:



Observe que o livro de histórias depende da emoção.

  • componentes estilizados
  • emoção
  • reac-estiletron

Suporta modo simultâneo

  • emoção: SIM . Desde a v10, é o modo estrito compatível com base na postagem de anúncio . Eu testei em um projeto simples que funciona conforme o esperado.
  • componentes estilizados: Parcial . Existe pelo menos um bug com estilos globais no modo estrito.

SSR

Estrelas

  • componentes estilizados: 30,6k
  • emoção: 11,4k
  • JSS : 5,9k

Trafic na documentação

Sessões estimadas da SimilarWeb / mês:

  • sass-lang.com : ~ 476K / mês (para comparação)
  • styled-components.com: ~ 239K / mês
  • emotion.sh: ~ 59K / mês
  • cssinjs.org : <30k / mês (para comparação)

Feedback dos usuários

Com base na pesquisa, 53,8% por cento estão usando os estilos Material-UI (JSS), o que não é uma surpresa, pois é o mecanismo vindo do Material-UI. No entanto, podemos ver que 20,4% já estão usando componentes estilizados, o que é um grande número considerando que não temos suporte direto para isso. Emotion é usado por cerca de 1,9% dos desenvolvedores atualmente com base na pesquisa.

Tendo esses números, queremos empurrar com melhor suporte para componentes estilizados, então isso é algo que devemos considerar.

Suporte de navegador

  • emoção: navegadores perenes modernos + IE11
  • componentes estilizados: não documentados para v5, mas as versões anteriores suportam o seguinte

Tamanho do pacote

Qual é a melhor opção?

Motor padrão

Mesmo se decidirmos oferecer suporte a vários mecanismos, ainda precisaríamos defender um por padrão e ter um documentado nas demos.

componentes estilizados

Prós:

  • Tem a maior comunidade, as pessoas adoram usá-la.
  • O desempenho a partir da v5 é bom.

Contras:

  • Isso significa que todos os estilos de componentes precisam ser criados usando a API styled , o que significa que os desenvolvedores sempre terão componentes de invólucro se precisarem mudar o estilo.
  • Falta de suporte simultâneo completo, o que pode criar bloqueios no futuro.

emoção

Prós:

  • Comunidade relativamente grande em crescimento.
  • Boa performance.
  • O modo simultâneo + SSR seria possível fora da caixa.
  • O prop CSS pode ser útil para substituições.
  • Suporte para mapa de origem.
  • Um pouco menor.

Contras:

Suporte a múltiplos

Podemos tentar oferecer suporte a várias soluções CSS-in-JS, fornecendo nossos adaptadores internos para elas. Algumas coisas que precisamos considerar é que podemos ter trabalho duplicado nos estilos, já que a sintaxe é diferente entre eles (pelo menos jss em comparação com componentes estilizados / emoção). Reutilizaremos o objeto de tema independentemente da solução que escolhermos.

O suporte menos envolvido para isso pode vir do uso de styled , já que as pessoas podem fazer algumas configurações de webpack para decidir qual usar - (isso é apenas algo a se considerar).

Comentários adicionais

Nomes de classe determinísticos nos componentes que podem ser direcionados para estilos personalizados

Em relação à aparência das classes e como os desenvolvedores podem direcioná-las, quero mostrar uma comparação do que temos atualmente e como o problema pode ser resolvido com a nova abordagem.

Como exemplo, pegarei o componente Slider. Esta é a aparência atual do DOM gerado:

Cada uma das classes tem uma semântica muito bem descritiva e as pessoas podem usar essas classes para substituir os estilos do componente.

Por outro lado, emoção, componentes com estilo ou qualquer outra biblioteca semelhante criará algum hash como um nome de classe. Para que possamos resolver isso e oferecer aos desenvolvedores a mesma funcionalidade para as classes de direcionamento, cada um dos componentes irá adicionar classes que podem ser direcionadas pelos desenvolvedores com base nos adereços.

Isso significaria que além das classes geradas pela emoção, cada componente ainda terá as classes que tínhamos anteriormente, como MuiSlider-root & MuiSlider-colorPrimary , a única diferença seria que essas classes agora serão usado puramente como seletores, em vez de definir os estilos dos componentes. Isso poderia ser implementado como um gancho - useSliderClasses

Conclusão

Não importa qual solução escolheríamos, usaríamos a API styled , que é compatível com os dois. Isso nos permitirá ter um suporte mais fácil para componentes estilizados + não estilizados (provavelmente com aliases de webpack, como para usar o preact).

Depois de investigarmos as duas opções que tínhamos no final, a equipe principal propõe que partamos com emoção . Alguns elementos-chave:

Um pequeno custo de migração entre componentes estilizados e emoção

Os desenvolvedores que já usam componentes estilizados devem ser capazes de usar as emoções quase sem esforço.

Existem diferentes maneiras de adicionar substituições além dos componentes do invólucro

O suporte de cx + css da emoção pode ser benéfico para os desenvolvedores usá-lo como uma alternativa para adicionar substituições de estilo, se não quiserem criar componentes de invólucro.

O modo simultâneo com certeza é compatível: +1:

Parabéns a @ryancogswell por fazer uma investigação mais profunda sobre este tópico. Até agora não encontramos nada no código do @emotion que pudesse nos preocupar se o modo simultâneo não funcionaria.
Também estávamos analisando createGlobalStyle de componentes estilizados como uma comparação com o componente global da emoção. Ele está fazendo a maior parte de seu trabalho durante a renderização (inerentemente problemático para o Modo Estrito / Concorrente) e apenas usando useEffect para remover estilos em sua função de limpeza. createGlobalStyle precisa de uma reescrita completa antes de poder ser usado no modo simultâneo - não é certo adicionar estilos durante a renderização se essa renderização nunca for confirmada. Parece que alguém tentou reescrevê-lo com mais algumas alterações no mês passado, portanto, precisaremos acompanhar esse progresso.

Como a especificidade é tratada

Os documentos da Emotion recomendam fazer a composição de CSS em uma única classe, em vez de tentar aproveitar estilos de vários nomes de classe. Na v5, nossos nomes de classes globais existentes seriam aplicados sem nenhum estilo anexado a eles. A composição de componentes com estilo de emoção combina automaticamente os estilos em uma única classe. Isso potencialmente elimina esses problemas de ordem da folha de estilo, pelo menos internos aos estilos definidos por Material-UI, porque os estilos de cada componente são orientados por um único nome de classe: +1 :.
Portanto, teríamos os nomes das classes globais (para os desenvolvedores direcionarem de várias maneiras para personalizações) e, em seguida, um único nome de classe gerado (por emoção) por elemento que consolidaria todas as fontes CSS que fluem para ele.
A especificidade é então tratada pela emoção com base na ordem de composição.
Todas as composições que usam emoção (seja composição de tempo de renderização ou de definição) resultam em uma única classe no elemento.
styled-components NÃO funcionam dessa maneira em relação à composição do tempo de renderização (a composição do tempo de definição é combinada em uma única classe). A mesma composição em componentes estilizados resulta em várias classes aplicadas ao mesmo elemento e a especificidade não funciona como eu esperava.

Alternativas


O que você acha disso?

discussion

Comentários muito úteis

Falando como mantenedor do Emotion - parece ótimo 🚀

Devemos também ser capazes de lançar um novo e importante em breve que não será nenhuma revolução, apenas algumas limpezas, melhorias gerais, ganchos sob o capô e melhorias de tipos de TS (melhor inferência e desempenho).

Oh, e analisador reescrito! que elimina alguns bugs de borda em Emotion e Styled-Components (como atualmente, ambos estão usando o mesmo analisador). É menor e mais rápido.

Todos 105 comentários

Apenas para algumas correções:

A comunidade React, em geral, votou contra o uso de JSS em grande escala.

Em vez disso, eu sugeriria que a comunidade React não votou _para_ JSS. Talvez não tenha sido "comercializado" tão bem quanto outras soluções?

Não apostamos no cavalo certo.

Apostamos no único cavalo - era uma corrida de um cavalo. Nenhuma das outras soluções disponíveis na época marcou todas as caixas.

Emoção parece ótimo! Adoro obter suporte para TS, por exemplo, preenchimento automático e todos os benefícios da digitação - com CSS-in-JS - ao construir a interface do usuário ou componentes de estilo, isso ainda será possível?

A última parte me pegou! Adoraria ajudar fazendo isso por trás de uma bandeira beta ou desenvolvendo alguns recursos:

Todas as composições que usam emoção (seja composição de tempo de renderização ou de definição) resultam em uma única classe no elemento.
Os componentes estilizados NÃO funcionam dessa maneira em relação à composição do tempo de renderização (a composição do tempo de definição é combinada em uma única classe).

Observei também que o objeto do tema vai permanecer o mesmo, a - na minha opinião - a melhor maneira de criar um tema para um aplicativo! Não tenho mais nada a dizer: espantado:

Obrigado pelo excelente trabalho no M-UI. Eu amo a direção que o projeto está tomando.

Mudar para uma forma de estilo mais padronizada é o caminho a percorrer. Eu sei que a equipe e a comunidade vão resolver os problemas, e a v5 - pelo que parece - vai ser ainda mais incrível! :foguete:

Como alguém que usou componentes estilizados e emoção, posso confirmar que a transição entre eles é fácil e indolor.

+ emoção é mais fácil de escrever

Falando como mantenedor do Emotion - parece ótimo 🚀

Devemos também ser capazes de lançar um novo e importante em breve que não será nenhuma revolução, apenas algumas limpezas, melhorias gerais, ganchos sob o capô e melhorias de tipos de TS (melhor inferência e desempenho).

Oh, e analisador reescrito! que elimina alguns bugs de borda em Emotion e Styled-Components (como atualmente, ambos estão usando o mesmo analisador). É menor e mais rápido.

E quanto às alterações interruptivas, qual opção introduz mais alterações interruptivas (se houver)?

Não tenho certeza se isso faz diferença, mas os benchmarks foram feitos com os plugins babel de emoção e / ou componente de estilo? Eles ajudam a otimizar ainda mais as coisas.

Pelo que entendi, a MUI havia indicado anteriormente que iria com estilo, então é uma surpresa. Eu acho que a emoção é uma ótima biblioteca, mas com mais pessoas usando o estilo atualmente, é importante que você encontre maneiras de dar-lhes boas opções se não quiserem migrar para a emoção

@ ee0pdt Emotion é muito, muito parecido com o estilo. Acho que isso é parte de toda a escolha do Emotion em vez de componentes estilizados. Há benefícios claros e a dívida de migração é pequena ou nenhuma.

E há uma seção inteira sobre o suporte de ambos, dando opções aos desenvolvedores. Isso poderia ser um caminho a percorrer, mas, novamente, a padronização provavelmente nos ajudaria mais no futuro. A simultaneidade total e nenhum componente de invólucro é um obstáculo para mim. Eu entendo que outras pessoas podem querer algo com estilo, e isso deve ser considerado. Prefiro buscar padronização

Por que o estiletron-react foi descartado? Ele deixa de fora uma métrica inteira que não foi considerada, que é o consumo de memória. O motor styletron padrão (e fela) é atômico. Embora um pouco mais lento, ele economiza muita memória. Ter visto muitas páginas de reação não fazerem nada e ultrapassarem 1 GB depois de um tempo é um pouco preocupante. O navegador congela depois disso.

Com uma estrutura atômica, o desempenho melhora globalmente com o tempo, entre os componentes, à medida que cada "classe" atômica é armazenada em cache. Provavelmente não refletido no teste também.

Feliz com ambos, desde que suporte SSR

Acabei de retirar meu voto da questão dos componentes estilizados originais: sweat_smile: - primeiro aprendi a conhecer as emoções através do livro de histórias, mas It will mean that all components styles need to be created using the styled API, which means for developers they will always have wrapper components if they need to re-style. me fez mudar.

Obrigado a todos pelo feedback rápido. Aqui estão as respostas a alguns dos comentários / perguntas.

E quanto às alterações interruptivas, qual opção introduz mais alterações interruptivas (se houver)?

@ sag1v usando styled-components vs emotion não introduz mais ou menos alterações importantes que precisaremos lidar. As mudanças gerais mais importantes seriam em torno da aparência das modificações dentro do tema:

// previosly
root: {
  contained: {
    '&$disabled': { // <-- this part will need to be transformed
      color: 'red',
    },
  },
  containedPrimary: {
    color: 'blue',
  },
}

// after
root: {
  contained: {
     '&.Mui-disabled': {
      color: 'red',
    },
  },
}

No entanto, como a sintaxe de estilos entre emotion & styled-components é idêntica, não fará nenhuma diferença.

Não tenho certeza se isso faz diferença, mas os benchmarks foram feitos com os plugins babel de emoção e / ou componente de estilo? Eles ajudam a otimizar ainda mais as coisas.

@ hc-codersatlas não, mas os perfs são aqueles que estão entre os poucos primeiros, então eu não acredito que faria qualquer diferença. Boa escolha, difícil!

Por que o estiletron-react foi descartado? Ele deixa de fora uma métrica inteira que não foi considerada, que é o consumo de memória. O motor styletron padrão (e fela) é atômico. Embora um pouco mais lento, ele economiza muita memória. Ter visto muitas páginas de reação não fazerem nada e ultrapassarem 1 GB depois de um tempo é um pouco preocupante. O navegador congela depois disso.

Com uma estrutura atômica, o desempenho melhora globalmente com o tempo, entre os componentes, à medida que cada "classe" atômica é armazenada em cache. Provavelmente não refletido no teste também.

Meus comentários sobre por que styletron-react foi descartado podem ser um pouco enganosos, desculpe sobre isso, atualizarei a descrição de PR imediatamente. O desempenho é bom, mas a maior preocupação que tenho com o styletron é a comunidade: https://www.npmtrends.com/styletron-react-vs-@emotion/core -vs-styled-components Enquanto os componentes de emoção e estilo são mais de 2000000 downloads nos últimos 6 meses, o styletron está em torno de 15000.

Além disso, o css atômico pode causar problemas com substituições, pois cada nome de classe contém apenas uma regra de estilizador.

Eu tenho uma pergunta se decidirmos usar o emoção que queremos adicionar abaixo do código no topo de todos os arquivos?
/ ** @jsx jsx * /
Este é o pragma JSX, por padrão o pragma JSX é React.createElement

Você precisa adicioná-lo se estiver usando a propriedade css em emoções. Para a API styled , bem como a API className regular, você não precisa dela.

É possível pular a adição do pragma JSX, mas requer configuração extra do Babel e vem com pior suporte do conjunto de ferramentas - por exemplo, o TS não é capaz de verificar o tipo de seu prop CSS com a mesma precisão que faz ao usar o pragma JSX. Mais informações podem ser encontradas aqui: https://github.com/emotion-js/emotion/pull/1941/files#diff -9abe25e5d2b00958d4b9849f5f20c139R5

@mnajdova obrigado. Eu estava apenas esperando que o uso de memória fosse coberto mais do que uma garantia para o estiletron em particular. Quanto a downloads ou comunidade - "apenas" o Uber usa styletron :) então não se preocupe. Votado pela emoção em primeiro lugar.

Seria legal se houvesse um plugin babel ou similar que pudesse transformar estilos estáticos em classes css reais. Já existe uma biblioteca semelhante chamada compiled . A maioria dos estilos são realisticamente estáticos.

Para ser útil, o Fela exigirá um conjunto de plug-ins como fela-plugin-rtl , fela-plugin-prefixer que tornará o desempenho ainda pior (https://github.com/microsoft/fluentui/pull/12289) 🐢 E então você provavelmente vai acabar com o Emotion (https://github.com/microsoft/fluentui/pull/13547), pois às vezes pode ser duas vezes mais rápido que o Fela 📦

Minha única preocupação é ter que usar css thingy do Emotion. Essa é uma grande bandeira vermelha com base na minha experiência. Tive que remover tal coisa de uma grande base de código e não foi divertido. Por quê? Porque é uma abstração que traz mais problemas do que aquela que resolve a longo prazo.

Na maioria das vezes, tentamos usar a função styled , mas ficamos muito felizes com a função makeStyles para gerar algumas classes em alguns casos.

Felizmente, não há nenhuma alteração significativa para essas duas APIs e não sou forçado a usar a macro css .

Minha única preocupação é usar o css thingy do Emotion.

@yordis Você definitivamente não será forçado a usar o css prop. Suspeito que haverá algum grau de mudança para os usos de makeStyles e withStyles . Esperançosamente, a quantidade de mudança necessária pode ser limitada principalmente a um codemod nas importações. Eu não acho que a abordagem usada em makeStyles ou withStyles será prática para apoiar o uso de emoção, então eu esperaria que qualquer suporte contínuo dessas APIs fosse por meio de um pacote separado (de modo que " @ material-ui / core "não tem mais uma dependência JSS), que provavelmente receberia apenas o mínimo de manutenção após o lançamento da v5 (os detalhes sobre o que acontece com makeStyles e withStyles não estão definidos ainda, então esta é apenas minha especulação sobre as implicações de avançar com emoção).

👍 a escolha de usar o Emotion. Evitar a API styled de styled-components é um dos motivos pelos quais minha equipe escolheu a emoção (que também oferece suporte a uma API styled semelhante, além da css prop). Atualmente, usamos o Emotion para personalização do estilo da IU do material e funciona muito bem. Suporte embutido seria apenas a cereja do bolo.

Em relação a esses fatos:

Muitos desenvolvedores usam componentes estilizados para substituir os estilos da interface do usuário do material. Os usuários finais encontram-se com duas bibliotecas CSS-in-JS em seu pacote

Suporta modo simultâneo
componentes estilizados: Parcial

Se os componentes estilizados tivessem suporte total para o modo simultâneo, seria uma escolha mais sensata, visto que a maioria dos desenvolvedores está substituindo o MUI por componentes estilizados (excluindo JSS)? O ponto sobre a emoção ser menor em tamanho de pacote é discutível se 2 soluções css-em-js precisam ser incluídas. E eu presumiria que a maioria das aplicações práticas do MUI envolvem a substituição de seus estilos.

Onde eu e minha equipe usamos o Emotion como uma forma principal de componentes de estilo, me deparei com algumas ineficiências presentes na biblioteca de emoções. E eu me pergunto o que vocês pensam sobre essas ineficiências explicadas abaixo.

Considere a seguir Emotion StyledComponent;

const StyledComponent = styled.div`
  ${({color}) => color && `color: ${color}`};
  display: flex;
  justify-content: center;
  align-items: center;
  background: teal;
  font-size: 20px;
  padding-top: 8px;
  padding-bottom: 8px;
  margin-top: 12px;
  margin-bottom: 12px;
  border: 1px solid grey;
`

Quando a cor prop muda, uma nova classe css é gerada com todas as props css ( display: flex, justify-content, ..., border: 1px soild grey ) copiadas. O que resultaria em classes css com exatamente os mesmos adereços css para cada suporte de cor, veja abaixo;
image

Outra ineficiência que encontramos é quando um novo componente é derivado de StyledComponent ele criará uma nova classe com todos os props css copiados da base StyledComponent . Considere abaixo;

const DerivedComponent = styled(StyledComponent)`
  font-family: monospace;
`

Ele cria outra classe css que adiciona apenas font-family: monospace à classe css acima gerada a partir de StyledComponent . Ou seja, ele cria um css que tem todos os adereços copiados de StyledComponent como pode ser visto abaixo;

image

Agora, se acima de StyledComponent e DerivedComponent forem usados ​​juntos, nós (inicialmente) temos duas classes css que têm props css duplicados (diferindo apenas na família de fontes). Como pode ser visto abaixo;

image

Como você pode imaginar, várias classes css que possuem props css duplicados umas das outras podem crescer rapidamente.

Descobri que com o Emotion, como os estilos de componentes são compostos juntos, acabamos com classes css com muitos adereços css duplicados.

Não tenho certeza se essa duplicata de adereços de css em cada classe de css tem algum impacto perceptível nos aplicativos, mas me pergunto se isso é levado em consideração ao escolher usar emoção.

Não estou questionando o desempenho do Emotion na criação e aplicação de CSSStyle em tempo de execução. A emoção é uma das formas mais rápidas de aplicar estilos CSS, como fica evidente em testes de desempenho.
Estou apenas preocupado com o estilo CSS resultante estar inchado. E como o Emotion pode ser SSR (ed), o que significa que os estilos são embutidos no HTML, podemos ficar desnecessariamente inchados (com tags de estilo css) no arquivo HTML. O que, por sua vez, resulta em muito mais tags para analisar com adereços css desnecessários pelos navegadores.

Se os componentes estilizados tivessem suporte total para o modo simultâneo, seria uma escolha mais sensata, visto que a maioria dos desenvolvedores está substituindo o MUI por componentes estilizados (excluindo JSS)? O ponto sobre a emoção ser menor em tamanho de pacote é discutível se 2 soluções css-em-js precisam ser incluídas. E eu presumiria que a maioria das aplicações práticas do MUI envolvem a substituição de seus estilos.

@petermikitsh as razões pelas quais concluímos sobre a emoção são, na verdade, os quatro pontos da conclusão

  • Um pequeno custo de migração entre componentes estilizados e emoção
    Os desenvolvedores que já usam componentes estilizados devem ser capazes de usar as emoções quase sem esforço.
  • Existem diferentes maneiras de adicionar substituições além dos componentes do invólucro
    O suporte de cx + css da emoção pode ser benéfico para os desenvolvedores usá-lo como uma alternativa para adicionar substituições de estilo, se não quiserem criar componentes de invólucro.
  • O modo simultâneo com certeza é compatível 👍
  • Como a especificidade é tratada

Tendo o primeiro ponto em mente, se os desenvolvedores realmente quiserem evitar ter duas soluções css-in-js no pacote, o custo de migração é realmente pequeno para mudar para o emotion + ele suporta API diferente além de styled .

@ ko-toss, obrigado por escrever isso são todos pontos positivos. O fato de que a emoção gera um className com todos os estilos torna-o o melhor mecanismo para resolver substituições. O problema que podemos ter com vários classNames gerados é que a última classe escrita vencerá, o que pode se tornar problemático no futuro.

Em outro projeto, eu estava usando css atômico, em que o consumo de memória é muito melhor porque todas as regras de css são escritas apenas uma vez, mas fazer substituições previsíveis lá é muito difícil, já que cada className é uma regra atômica e, novamente, qual vence, depende da ordem em que são escritos, se você não decidir processar previamente todos os estilos e mesclá-los corretamente, o que pode afetar o desempenho no final.

Por outro lado, acredito que usando qualquer solução css-in-js, as pessoas não irão apenas criar combinações infinitas de estilos aleatoriamente, elas ainda são bastante estruturadas com base no valor dos adereços.

No entanto, novamente esses são pontos positivos, que teremos em mente, muito obrigado por compartilhá-los 👍

  • outro?

e quanto à compatibilidade de ideias [stylex] (como [style9])

  • outro?

style9 ou qualquer outro mecanismo CSS compatível com o stylex idea

Isso parece exigir uma configuração de tempo de construção que desencorajaria muitas pessoas de usá-lo, especialmente iniciantes.

(isso é bastante para sua informação, a emoção é uma boa escolha)

https://github.com/cristianbote/goober (1kB, desempenho um pouco pior do que emoção)

Não tenho experiência com isso ainda, mas quero experimentar um dia.
image
image

@cztomsik Semelhante a https://github.com/kuldeepkeshwar/filbert-js, mas não tem suporte para sintaxe JavaScript (apenas string de modelo CSS)

Aqui estão alguns testes feitos com o farol do google no tempo de interação:

https://jantimon.github.io/css-framework-performance/

css-lighthouse-scores

Para sua informação, fiz alguns benchmarks detalhados de componentes estilizados v5, emotion v10 e emotion v11, com / sem plugin babel, com API vanilla, API css props e API estilizada. Espero que isso ajude a discussão!

https://github.com/simnalamburt/css-in-js-benchmark

Você considerou a nova onda de bibliotecas css-in-js que dependem fortemente de css atômico e suporte de texto digitado?

Você considerou a nova onda de bibliotecas css-in-js que dependem fortemente de css atômico e suporte de texto digitado?

Não está no benchmark, mas atualmente otion é 2 ~ 4 vezes mais lento do que emoção. Acho que o otion realmente tem um potencial muito grande e acredito que há espaço para a otimização, mas o otion ainda não está realmente pronto para a produção.

Mas ainda não testei os pontos. 😃

Que tal uma biblioteca real de tempo de execução zero? Não vi ninguém mencionar linaria .

Eu tropecei em linaria em algum momento e eu realmente gostei. Minha única preocupação é que os estilos de adereços dinâmicos dependem exclusivamente de variáveis ​​css, e não há suporte para o IE 11 baseado em https://github.com/callstack/linaria/issues/445 Também em comparação com styled-components e emotion a comunidade é muito menor no momento.

@TheHolyWaffle
Linaria é incrível.
Se você configurá-lo corretamente, acredito que seja o melhor de ambos css-in-js (em termos de experiência de desenvolvimento) e css puro (não pode superar o desempenho de css puro). Ele ainda otimiza (desduplica) e reutiliza regras de css.
Mas linaria requer etapas de construção e agrupamento, o que seria difícil para iniciantes.

Eu adoraria ver portas para outras bibliotecas css-in-js com superfície de API semelhante, por exemplo, filbert-js / goober

@kuldeepkeshwar Avisaremos assim que examinarmos os adaptadores para a API estilizada :)

Como https://compiledcssinjs.com/ se encaixa em tudo isso? Parece ser uma abordagem incrivelmente interessante; Compiled também executa RFCs para o projeto, o que prova ser ótimo para código aberto e colaboração. _wink wink_

Acho que o futuro é muito, muito brilhante para estilizar a web e espero que o Material-UI seja uma parte integrante da solução para estilizar qualquer aplicativo.

A explicação de como funciona o Compiled me atingiu:

Este tipo de transformação nos permite entregar seu componente a qualquer consumidor sem a necessidade de configurar / configurar suas ferramentas. Basta importar e pronto. Isso é poderoso e, mais importante, o mesmo que o CSS atual nas bibliotecas JS funciona - com um detalhe.

_CSS não pode ser gerado em tempo de execução._

Essa única restrição abre muitas portas para nós. Otimizações de tempo de construção. Garantias de tempo de execução. Os gargalos de desempenho desapareceram.

Por outro lado, gostaria de salientar que popularidade não significa muito para um bom projeto. Eu amo o MUI e o trabalho que foi feito até agora; Também acho fantástico que se tenha tornado um produto premium.
Mas escolher um _nome_ 'popular' por causa da popularidade não é um argumento razoável.
Eu vi popularidade referenciada várias vezes, e não gosto mesmo de considerar se a quantidade de pessoas x usa tecnologia x - MUI é (em meus livros) focado em desempenho, DX e outras coisas, apenas não popularidade.

A MUI nem sempre teve 60 mil estrelas, ela as conquistou porque escolheu a melhor tecnologia (ou quase), não porque escolheu uma tecnologia popular.

Se a escolha com base no voto popular se refere a ser um projeto mais amplamente acessível, isso é uma preocupação de negócios, não possíveis melhorias de desempenho. Um projeto vive com ou sem usuários. Ele morre com escolhas erradas. Acho que há tantos ditados em torno disso e ler "não é popular o suficiente, portanto, é uma escolha ruim" soa muito alto.

As pessoas usam um produto certo porque é bom, não porque usa tecnologia popular; O MUI já foi um nicho, mas ficou famoso mesmo tendo CSS-in-JS, que não ganhou o voto popular, aliás. Ele apenas tem algumas propriedades incríveis e fez as escolhas certas que não eram baseadas na comunidade atual, mas no DX e desempenho reais.

Tendo anotado essa nota, estou do lado do voto popular; então, se qualquer coisa, também estou me sabotando. Não tenho nenhum ganho pessoal ao escolher um produto bem menos popular, tenho a opinião que popularidade não deve ser considerada de forma alguma quando se fala em revoluções e mudanças. Reconsidere algumas dessas opções com base no que realmente são, não no que as pessoas pensam que são com base na popularidade atual da opção.

Para realmente terminar, sou grato por cada pensamento e qualquer quantidade de tempo que passei no MUI. Eu fiz algumas soluções incríveis (infelizmente particulares) seguindo todos os padrões, etc. nos últimos dois anos, que levaria meses ou anos para fazer sozinho! Não consigo descrever minha apreciação o suficiente para que brilhe no papel 🙇‍♂️ 🙏 🙇‍♂️

Estou curioso para saber se Compilado é uma opção e como funcionaria com adaptadores e tal. Acho que a abordagem compilada:

Compiled compila seu CSS em JS no momento da construção, analisando estaticamente seu código e, em seguida, transformando-o em Compiled Components. Tudo o que precisamos para usar o componente está incluído ao lado dele no pacote JavaScript.

é um caminho a ser considerado, dada a restrição 'css at runtime' de compilação.

Estou dizendo isso como mantenedor do Emotion - Compilado é ótimo. Ou melhor - pode ser no futuro, isso é algo muito emocionante, mas ainda está no início da experimentação. Eu duvido muito que o MUI possa ir com ele neste momento.

Corrija-me se eu estiver errado, mas compilado implica em ter uma configuração, o que significa que seria obrigatório ter um arquivo de configuração para MUI mesmo sem usar estilos personalizados.

Eu odiaria ser forçado a criar uma configuração apenas para usar o MUI. Em uma nota lateral: isso não seria difícil de usar em bootstrappers opinativos como Create React App?

@Andarist eu concordo inteiramente. Eu sugeriria começar uma colaboração ou pelo menos considerar participar do desenvolvimento da biblioteca. Estou curioso sobre aonde isso pode levar no futuro! : olhos: Acho que algo como compilado - como você está dizendo - no futuro vai ser ótimo. Seria incrível ter mais grandes mentes se reunindo para fazer algo notável.

@shilangyu Não tenho certeza do que você está página inicial do compilado tem o seguinte a dizer sobre isso:

Migrar para uma realidade de configuração zero

As APIs que amamos estão todas aqui para o passeio - prop CSS e componentes de nomes de classe também! Nossos consumidores nem precisam mudar a forma como consomem nossos componentes, continuando a história de configuração zero, eles não precisam configurar seu bundler, nem precisam configurar nada específico para renderização do lado do servidor. Simplesmente funciona.

Só o começo

Com zero configuração out-of-the-box hoje, não estamos esquecendo como será o amanhã. Com a possibilidade de extração opcional de CSS, transformando o CSS em uma forma Atômica e até mesmo sendo capaz de usar os dados CSS para análise em nossa base de código, estamos pensando em um amanhã emocionante.

@MathiasKandelborg
Eu folheei https://compiledcssinjs.com/ . Não é ainda runtime css-in-js?
Ele cria classes css em tempo de construção, mas aplica esse estilo (cria tag de estilo com classes css geradas em tempo de construção) com <CC>...</CC> tag em tempo de execução.
Se for tão rápido quanto usar css puro, então realmente é o futuro (já que usa variáveis ​​css). Obrigado por compartilhar
Eu me pergunto o quão mais rápido é em comparação com a emoção.

Que tal uma biblioteca real de tempo de execução zero? Não vi ninguém mencionar linaria.

O que não incluímos nos requisitos é que qualquer solução deve ser zero-config da perspectiva dos consumidores de Material-UI. Se eu entendi as soluções de tempo de execução zero, elas geram algum CSS no momento da compilação. Não tenho que configurar meu bundler para incluí-lo corretamente?

Portanto, embora o tempo de execução zero seja provavelmente a solução mais rápida, ele também requer atenção extra. Ter uma solução zero-config que pode ser configurada para rodar com zero-runtime seria o ideal, eu acho.

Portanto, embora o tempo de execução zero seja provavelmente a solução mais rápida, ele também requer atenção extra. Ter uma solução zero-config que pode ser configurada para rodar com zero-runtime seria o ideal, eu acho.

Realmente não posso dizer sobre o estado atual do Compiled, mas eu estava falando sobre isso várias vezes com o mantenedor e este é aproximadamente o plano - a ideia é manter o suporte para APIs de Emotion & Styled Components, portanto, otimizar o código escrito deve ser apenas uma questão de alterando as importações e incluindo um plugin de transformação ou um carregador de webpack. Ele, com certeza, não lidará com todo o código que pode ser escrito (JS é selvagem), mas deve ser capaz de lidar com código escrito de maneira sensata. Se não for capaz de compilar algo, o. Ele simplesmente jogará - forçando alguém a abandoná-lo ou reescrever uma parte específica do código para auxiliar na análise estática.

Então, para resumir - se você usar 0config Emotion (ou Styled Components), então deve ser possível adaptar Compiled como uma otimização opcional no futuro (se o projeto conseguir cumprir o que promete)

@ ko-toss Acho que compila no componente estilizado no momento da construção. No tempo de execução, os estilos do componente são movidos para seus lugares corretos.

Como se costuma dizer na página da web:

Tudo o que precisamos para usar o componente está incluído ao lado dele no pacote JavaScript.

Aceitamos seu código inicial em toda a sua glória:

import { styled } from '@compiled/css-in-js';

export const ColoredText = styled.span`
  color: #ff5630;
`;

E então transforme-o em um componente compilado:

...
...

Que então, em tempo de execução, moverá os estilos para o cabeçalho do documento.

Este tipo de transformação nos permite entregar seu componente a qualquer consumidor, sem a necessidade de configurar / configurar seu ferramental. Basta importar e pronto. Isso é poderoso e, mais importante, exatamente o mesmo que o CSS atual nas bibliotecas JS - com um detalhe

CSS não pode ser gerado em tempo de execução.


Ter uma solução zero-config que pode ser configurada para rodar com zero-runtime seria o ideal, eu acho.

Eu acho que você acertou o prego na cabeça. Seria utópico de repente apenas sonhar com carinho .

Existem algumas ideias para explorar e talvez alguma colaboração a ser obtida. Alguns dos códigos e conceitos são um pouco estranhos para mim, então não estou em posição de entrar em muitos detalhes. Aqui estão algumas das coisas que me entusiasmam:

  • Análise estática - esta é uma grande. Imagine obter os dados de como você está usando uma solução de estilo, obter recomendações com base na regra X, convenção ou especificação e ser mostrado onde você pode otimizar
  • Configuração zero - embora eu priorizasse mais liberdade em favor da preguiça (instalando um plugin para x bundler)
  • CSS-in-JSS para CSS puro, basicamente extraindo estilos em tempo de compilação para incluí-los estaticamente, sem necessidade de um tempo de execução.

Em relação ao suporte do IE11, como você vê as estatísticas? Tenho certeza de que é uma coisa perfeitamente viável de se fazer. O Edge agora é baseado em cromo, e a maioria das empresas deve fazer a mudança quando a MS finalmente interromper o suporte para o IE, quando cada sistema operacional no qual o IE11 foi instalado chega ao fim de seu ciclo de suporte. É realmente um ciclo longo, mas eu acho que os mantenedores também têm uma parte em promover mudanças, e manter o suporte para algo que está essencialmente obsoleto parece permitir que as pessoas esperem até que a 'mudança' realmente aconteça.

Seria bom ter a opção de não oferecer suporte ao IE11. Não é mais o padrão da indústria e será preterido. É uma questão de tempo, e o suporte _padrão_ de coisas incríveis como o MUI provavelmente impede a mudança.

Seria bom ter a opção de não oferecer suporte ao IE11.

Veja https://github.com/mui-org/material-ui/issues/14420 para isso.

Não planejamos descartar completamente o suporte ao IE. A versão padrão provavelmente não será direcionada ao IE 11 na v5, mas não podemos escolher uma solução que não funcione no IE 11. Ou melhor, deve ser uma solução que podemos trocar no tempo de construção e produzir a mesma resultado.

Isso me faz feliz.

existe um mod de código para converter jss existente para com estilo / emoção, eu me pergunto?

Olá a todos. Estou aproveitando a oportunidade para entrar nessa discussão.

Na versão atual, o Material UI faz uso pesado de withStyles HOC sem nenhum estilo dinâmico (o estilo é uma função que depende de adereços), que usa internamente makeStyles . O desempenho de makeStyles (sem adereços dinâmicos) é bastante notável e a IU do material poderia ser ainda mais rápida se fosse usada diretamente, em vez de withStyles , que cria um invólucro desnecessário.

Eu criei um benchmark bifurcado deste benchmark e o implantei no Vercel, para que todo o código seja compilado com sinalizadores de produção ativados. O benchmark renderiza cartões usando CSS diferentes em bibliotecas JSS. Aqui estão os links:

Para 100 cartas :

Para 500 cartas :

Para 2500 cartões :

No geral, emotion e styled-components são muito semelhantes em desempenho. No entanto, makeStyles parece ser 2-4x mais rápido no geral na montagem e renderiza 6-8x mais rápido para atualizações.

A diferença é significativa o suficiente, especialmente quando estamos renderizando em dispositivos de baixo consumo de energia, como nossos telefones ... e existem muitos telefones ruins por aí.

Tudo isso para dizer que estou preocupado com a migração do material e usando emotion por padrão, o que diminuirá o desempenho de (isso não é verdade, depende do componente; quanto mais complexo for, menos diferença haverá).

Algumas perguntas e alimentos para reflexão:

  • O DX realmente vale a pena a troca de UX? Mesmo o DX é discutível, pois muitos preferem makeStyles
  • O problema com makeStyles tem a ver com estilos dinâmicos que parecem ser corrigidos pela implementação de um ID de cache determinístico. Atualmente, cada instância do componente obtém seu próprio id para adereços dinâmicos, mesmo que os adereços e estilos de saída sejam os mesmos, causando sobrecarga de tempo de execução, muitas tags de estilo na cabeça e desempenho de SSR reduzido. Parece corrigível usando uma estratégia de hash para estilos dinâmicos, assim como muitos outros CSS em bibliotecas JS estão fazendo isso. Relacionado: https://github.com/mui-org/material-ui/pull/16858
  • Há espaço para melhorias em emotion e styled-components para chegar mais perto, ou mesmo ser melhor do que makeStyles ?
  • O Material UI oferecerá suporte a um adaptador de mecanismo JSS oficial para que os desenvolvedores possam escolhê-lo para obter mais desempenho?

Posso viver com uma pequena perda de desempenho.

Não é uma perda de desempenho de 300%, a nenhum custo. 😅

@satazor obrigado por explorar isso. Fizemos um teste de desempenho pesado antes de iniciar esse esforço, consulte PR https://github.com/mui-org/material-ui/pull/22173 para mais detalhes (fizemos isso no componente ListItem) e a diferença de desempenho estava em a maioria 10% para renderizar x1000 instâncias, no modo de produção .

https://deploy-preview-22173--material-ui.netlify.app/performance/list-raw/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-mui/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-styled/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-styled-wrapper/

Com base nisso, decidimos ignorar essa diferença, por causa dos benefícios que obteríamos (adereços dinâmicos fora da caixa, API estilizada que já foi usada por uma grande porcentagem dos desenvolvedores etc - o resumo completo pode ser encontrado no Descrição PR :))

Não tenho certeza do que está acontecendo em seus benchmarks, mas 3-5x parece muito para mim, me faz pensar por que alguém usaria emotion / styled-compoenents se fosse esse o caso. Podemos tentar para ver onde está a diferença entre os dois benchmarks, caso esteja faltando alguma coisa. Além disso, fazer benchmarks em um componente MUI real seria muito melhor na minha opinião, portanto, obteríamos números mais realistas, portanto, deixe-me saber se você deseja explorar mais sobre este lado. O PR I linkado é um bom ponto de partida.

Obrigado pela resposta @mnajdova. Você está certo ao dizer que testar em um componente Mui seria mais realista. O que provavelmente está acontecendo é que o código Mui para os componentes de Lista é o fator de lentidão predominante, e a diferença entre eles (~ 30 ms) é a diferença de tempo de renderização real associada aos estilos. Vou pegar o código desse PR e adicioná-lo ao benchmark, para ver os resultados.

Isso vai importar no final? Provavelmente não, mas depende do aplicativo. A diferença de desempenho entre os componentes Mui atuais e os estilizados aumentará conforme o código de renderização em si é mais simples. Como exemplo, espero ver diferenças maiores nos componentes Ícone ou Tipografia, mas diferenças menores nos Cartões. Então, realmente depende do aplicativo e da quantidade de componentes de cada tipo que o aplicativo está usando.

o que diminuirá o desempenho de renderização da IU do material e dos sites que a utilizam em um fator 3-5x.

Você criou um benchmark que tem esse fator. Isso não significa que todos os componentes apresentarão essa diminuição. Tente evitar tirar conclusões precipitadas, pois essas informações enganosas se espalham facilmente a partir de um problema tão visível.

Usando a extensão devtools vi 140ms para montagem com emoção vs 120ms para montagem com makeStyles.

Você criou um benchmark que tem esse fator. Isso não significa que todos os componentes apresentarão essa diminuição. Tente evitar tirar conclusões precipitadas, pois essas informações enganosas se espalham facilmente a partir de um problema tão visível.

Você está certo, veja meu comentário anterior.

Você criou um benchmark que tem esse fator. Isso não significa que todos os componentes apresentarão essa diminuição. Tente evitar tirar conclusões precipitadas, pois essas informações enganosas se espalham facilmente a partir de um problema tão visível.

Usando a extensão devtools vi 140ms para montagem com emoção vs 120ms para montagem com makeStyles.

Eu atualizei o benchmark para usar actualDuration vez de baseDuration , então agora devemos ver os valores mais alinhados com o que é mostrado no profiler devtools. O baseDuration mede o tempo sem memoizações, enquanto actualDuration é o oposto. Observe que essa alteração afeta apenas o desempenho do rerender, e agora estou vendo makeStyles 6-8x mais rápido para rerenders, o que significa que tem melhor armazenamento em cache / memoização? No entanto, não estou entendendo os valores que você está vendo. Você pode tentar com os links atualizados?

Screenshot 2020-09-22 092415
Screenshot 2020-09-22 092514

@satazor Não acho que seus casos de teste sejam equivalentes. Devemos ser bons.

Algumas mudanças que você pode tentar entender e que irão reduzir a diferença de desempenho:

  • Montar componentes de reação tem um custo, especialmente ao renderizar muitos deles. makeStyles usa div diretamente enquanto emoção / sc cria novos componentes. Em nosso benchmark de tabela, percebi que cada componente de adição adiciona o tempo de renderização da linha de base, então se 3 níveis de componentes => x3 (ou porque <MenuItem> é quase x10 mais lento do que <li> ).
  • Sua demonstração com makeStyles cria uma única folha de estilo, emoção / sc não. Tente usar uma única folha de estilo com seletores CSS para direcionar os itens em cada recipiente de cartão. Ou faça o oposto, divida a folha de estilo makeStyles principal em várias, uma por item.

Na verdade, @oliviertassinari. Parece que o desempenho daqui para frente com componentes de emoção / estilo está mais no fator 1,5x-2x máximo, mesmo para componentes simples, como Typography , que implementei aqui: https://codesandbox.io/ s / css-in-js-compare-forked-lr3sr? file = / src / components / EmotionTypography.js.

Verifique a compilação de produção e benchmark em: https://csb-lr3sr-7lp24bj5l.vercel.app/

makeStyles é 1,5-2x mais rápido na montagem e 3-4x mais rápido nos re-renderizadores. Isso é potencialmente algo para ficar de olho, mas acho que o desvio será muito menor para componentes mais complexos.

Então, para concluir, não estou mais preocupado com o desempenho e estou ansioso para ver como será esse esforço.

@mnajdova Aqui está o build de produção para o teste List: https://csb-lr3sr-3zi42510w.vercel.app/?components=1000 , copiado do PR que você mencionou. Link Codesandbox: https://codesandbox.io/s/css-in-js-comparison-forked-6s4nl

makeStyles parece 1,7x mais rápido na montagem e 2,2x mais rápido na renderização. Não estou entendendo a diferença de 10% que você está vendo. Estou fazendo algo errado?

@satazor Interessante, obrigado por colocá-lo junto. Usei este benchmark com # 22435 para comparar o desempenho de

import Slider from '@material-ui/core/Slider';

vs (emoção).

import SliderStyled from '@material-ui/lab/SliderStyled';

vs (componentes estilizados).

import SliderStyled from '@material-ui/lab/SliderStyled';

Capture d’écran 2020-09-23 à 17 23 23
Capture d’écran 2020-09-23 à 17 25 07
Capture d’écran 2020-09-23 à 17 23 54

Neste ponto, é difícil dizer por que está mais lento. O gargalo pode não estar nos estilos. E lembre-se de que o executei no modo dev ⚠️!

Eu adicionei duas novas páginas para dar uma olhada no desempenho da versão WIP emotion do Slider:

Depois de construído para produção, as estatísticas parecem ser semelhantes a https://github.com/mui-org/material-ui/issues/22342#issuecomment -697540546, é cerca de x1.6 mais lento (mas CSS é totalmente dinâmico). Observe que você pode jogar com a versão WIP emotion com:

Capture d’écran 2020-09-23 à 18 56 01

Capture d’écran 2020-09-23 à 18 55 48

Além disso, observe que sabemos que poderíamos tornar a versão atual do JSS x1.1 mais rápida usando makeStyles em vez de withStyles: # 15023.

@oliviertassinari no modo prod as coisas ficam um pouco mais rápidas, mas acho que as diferenças permanecem lá. Você pode clicar em deploy> vercel on code sandbox para implementar rapidamente com sinalizadores de construção de produção.

Olhando como makeStyles é implementado, vejo como é mais rápido quando você apenas usa estilos estáticos :

  1. Em cada montagem, attach é chamado.
  2. Se for a primeira instância desse tipo de componente, stylesCreator.create é chamado, que por sua vez chama fn especificado em makeStyles(fn) .
  3. Em todas as outras instâncias, stylesCreator.create é ignorado porque a contagem de referências é> 0.

Para reprocessadores:

  1. Em cada nova renderização, attach é chamado.
  2. Depois disso, stylesCreator.create é ignorado porque a contagem de referências é> 0, então nenhum trabalho é feito.

Observe que, se estilos dinâmicos estiverem em jogo, as folhas devem ser atualizadas aqui , em cada montagem e reenvio.

Ao contrário, styled-components e emotion parecem executar nossas funções de estilo em cada instância do componente, o que resulta em mais ciclos de CPU e contrapressão de memória. Achei que eles poderiam de alguma forma fazer um cache multi memoize com base na combinação de adereços, mas isso presumiria que as funções de estilo são puras, o que pode não ser o caso, considere:

     const someContext = useContext(FooContext);

    return <div css={ { paddingTop: someContext.padding(1) } }>;

Se minhas suposições estiverem corretas, será muito difícil atingir o nível de desempenho de makeStyles para a geração de estilos estáticos, pois a maneira como funciona e como a API é projetada permite otimizações que styled ou css API não pode.

Vejo algumas direções possíveis que podemos explorar:

  • Na descrição do problema inicial, apenas comparamos o desempenho com o suporte dinâmico de Material-UI. Poderíamos adicionar uma entrada para o caso estático (o que a v4 usa). Também poderíamos ter um caso para react-jss estático e dinâmico. Isso deve nos ajudar a entender o escopo das opções de mecanismo de estilo disponíveis.
  • Podemos investigar onde está o gargalo. Poderíamos imaginar ter um adaptador para jss, como temos para componentes estilizados, e ver se o desempenho é melhor. Deveria ser muito pior com a versão dinâmica do JSS, mas poderíamos compará-lo com a versão estática. Talvez esteja vindo de uma abstração sem estilo.
  • Poderíamos considerar a desaceleração um preço que vale a pena gastar para desbloquear estilos dinâmicos e sem estilo. Se quiser renderizar uma lista longa, você usará virtualização ou dependerá de seletores CSS aninhados.
    emoção e componentes estilizados provaram fornecer flexibilidade e serem rápidos o suficiente pela indústria, assim como React.

Se de alguma forma emotion expôs um gancho useCss como foi solicitado em https://github.com/emotion-js/emotion/issues/1321 e https://github.com/emotion- js / emotion / issues / 1853 , poderíamos reter makeStyles API e, conseqüentemente, os benefícios do "CSS estático". No entanto, continuaríamos usando CSS estático em todos os lugares, para aumentar o desempenho, que não é tão "limpo", mas é o que já estamos fazendo na v4.

Na verdade, com a API ClassNames , acho que poderíamos fazer um porte de withStyles agora que reteria os benefícios do desempenho CSS estático e o bom desempenho do CSS dinâmico que o emoção tem. Se const css = useCss() existisse, seria simples criar uma porta de API useStyles também.

As principais vantagens de manter withStyles + makeStyles API que usa emoção sob o capô são:

  • A migração que o material tem que fazer é praticamente nenhuma, só precisaríamos fazer o port dessas 2 funções.
  • Os usuários que já usam withStyles e makeStyles fora da IU de material não precisariam migrar. Eles obteriam o benefício de desempenho aprimorado para CSS dinâmico, de graça.
  • Nenhuma lógica adicional é necessária para manter a API classes + CSS. Com styled , precisaríamos criar os className s globais manualmente ou com um utilitário.
  • Nesta estratégia, useCss é a nossa função de adaptador para CSS em soluções JS, em vez de styled .
  • Para oferecer suporte a outros CSS em soluções JS, eles precisariam fornecer um gancho useCss ou semelhante. Idealmente, seríamos capazes de fazer aliasing de webpack / babel para trocá-los, assim como styled .

Exploramos mais o problema de desempenho em https://twitter.com/olivtassinari/status/1309247827839680512. Acho que podemos seguir em frente como está. Para equipes que se preocupam profundamente com o desempenho, eles podem optar pelos componentes sem estilo, pois eles fornecem melhor desempenho. Para os outros, como a maioria da indústria, a emoção e os componentes estilizados são bons o suficiente.

  • nativo: 7,71 ms
  • v5 sem estilo: 20,89ms
  • v4: 29,93 ms
  • v5: 37,37ms
  • antd: 53,48ms
  • chakra: 64,67ms

https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js…

Desculpe incomodá-lo aqui tão tarde na discussão, mas estou um pouco surpreso por você não estar olhando de perto para styled-jsx

A lista deles atendeu exatamente aos seus requisitos:

  • Servidor e cliente funciona
  • Suporte total a CSS, sem vantagens e desvantagens
  • Tamanho do tempo de execução de apenas 3 kb (gzip, de 12 kb)
  • Isolamento completo: seletores, animações, quadros-chave
  • Prefixo de fornecedor de CSS integrado
  • Transpilação muito rápida, mínima e eficiente (veja abaixo)
  • Injeção de CSS em tempo de execução de alto desempenho quando não estiver renderizando no servidor
  • À prova de futuro: equivalente a "Shadow CSS" renderizável por servidor
  • Suporte a mapas de origem
  • Suporte a estilos e temas dinâmicos
  • Pré-processamento CSS por meio de plug-ins

Eu prestaria atenção ao fato de que é quase uma API padrão CSS sombra . Portanto, ao remover o atributo jsx você poderá fazer a transição para componentes da web no futuro que já estão funcionando nos navegadores normais, BTW.

Sim, eu sei que pode não ser o mais popular.
Mas eu só quero salientar que o Flash era muito popular há alguns anos.
Mas secou no final por não ser compatível com o padrão da web, e agora temos SVGs.
Só para constar, o padrão SVG esteve presente muito tempo quando o Flash dominava a indústria.
Eu apenas vejo os eventos históricos como boas lições e tentaria identificar o padrão de que a popularidade é o último indicador de ser à prova de balas de manutenção e futura.

@mifrej Eu pessoalmente tive uma experiência ruim com ele: https://github.com/vercel/styled-jsx/issues/142.

Exploramos mais o problema de desempenho em https://twitter.com/olivtassinari/status/1309247827839680512. Acho que podemos seguir em frente como está. Para equipes que se preocupam profundamente com o desempenho, eles podem optar pelos componentes sem estilo, pois eles fornecem melhor desempenho. Para os outros, como a maioria da indústria, a emoção e os componentes estilizados são bons o suficiente.

  • nativo: 7,71 ms
  • v5 sem estilo: 20,89ms
  • v4: 29,93 ms
  • v5: 37,37ms
  • antd: 53,48ms
  • chakra: 64,67ms

https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js…

Você experimentou os plugins babel para componentes de emoção / estilo? Isso fez alguma diferença nos horários?

O que significaria uma mudança do JSS para o classes prop disponível nos componentes MUI existentes? Como uma migração v5 pareceria para usuários existentes que aproveitam esse suporte extensivamente?

Em vez disso, imaginamos que as pessoas usem a seguinte sintaxe: https://next.material-ui.com/components/slider-styled/#unstyled -slider as classes são basicamente substituídas pelos seletores de classe disponíveis para cada slot no componente. Você também pode dar uma olhada no exemplo de personalização: https://next.material-ui.com/components/slider-styled/#customized -sliders

Como vantagem, você pode usar apenas os adereços e aplicar estilos dinâmicos baseados neles.

Em vez disso, imaginamos que as pessoas usem a seguinte sintaxe: https://next.material-ui.com/components/slider-styled/#unstyled -slider as classes são basicamente substituídas pelos seletores de classe disponíveis para cada slot no componente. Você também pode dar uma olhada no exemplo de personalização: https://next.material-ui.com/components/slider-styled/#customized -sliders

Como vantagem, você pode usar apenas os adereços e aplicar estilos dinâmicos baseados neles.

Eu amo essa API! Uma mudança muito bem-vinda e parece funcionar muito bem com os motores de estilo.

Antes de v5 , se bem me lembro, o compilador JSS estragava esses nomes de classe e você não conseguia defini-los de forma confiável? Mas agora parece que eles serão expostos para fins de segmentação? 🙌 Além disso, havia o problema com a precedência de CSS. E essas preocupações são resolvidas com esta nova abordagem? Obrigado por trabalhar neste refatorador!

@ConAntonakos exatamente essas classes podem ser direcionadas para as versões sem estilo e com estilo dos componentes. A ordem em que o estilo é chamado garante que os novos estilos vencerão, é claro se a especificidade for a mesma :)

Antes da v5, se bem me lembro, o compilador JSS destruía esses nomes de classe e você não podia direcioná-los de forma confiável?

Você já pode segmentá-los na v4.

as classes são basicamente substituídas pelos seletores de classe disponíveis para cada slot no componente.

Eles são "basicamente" substituídos ou realmente substituídos? Achei que tivéssemos decidido manter algumas das APIs antigas para reduzir o número de alterações importantes.

Achei que tivéssemos decidido manter algumas das APIs antigas para reduzir o número de alterações importantes.

Decidimos manter a mesma API para as substituições theme.components.overrides - definidas no tema funcionam da mesma maneira.

Para as substituições de instância, temos a abordagem styled agora com os seletores de classe, é por isso que o classes prop não é mais suportado. Os desenvolvedores podem fazer o mesmo de maneira mais flexível agora.

Os desenvolvedores podem fazer o mesmo de maneira mais flexível agora.

Isso soa como um problema menor, porque há uma alternativa, mas o custo de migração para isso é enorme. Como é o plano de migração?

Os desenvolvedores ainda podem usar as substituições de tema, se eles apenas moverem as substituições de instância para um ThemeProvider aninhado, eles não precisarão alterar os estilos definidos, pois a estrutura entre os dois é a mesma (não é perfeita , mas se eles quiserem uma atualização incremental, é um caminho a percorrer)

Por outro lado, ainda podemos suportar as classes prop facilmente, mas nesse caso não podemos garantir se a combinação de classes + styled é usada no mesmo componente que deve ganhar. Devemos fazer backport do suporte de classes pelo menos na versão estilizada dos componentes?

Posso ter perdido isso ao longo deste tópico - outra questão relacionada à minha pergunta classes . Que tipo de garantia de "correção" pode haver?

Por exemplo, eu editei o exemplo do controle deslizante:

const StyledSlider = styled(SliderUnstyled)`
  & .MuiSlider-raill {
    display: block;
    position: absolute;
    width: 100%;
    height: 2px;
    border-radius: 1px;
    background-color: currentColor;
    opacity: 0.38;
  }
)

Você perceberá que escrevi acidentalmente MuiSlider-rail incorretamente. Anteriormente, com classes haveria algo como classes.rail e, se eu digitasse incorretamente a propriedade, receberia um aviso em tempo de execução de que classes.raill não existe na folha de estilo. Acredito que o Tema teve o mesmo comportamento?

As vantagens da API classes que posso imaginar:

  1. Limite contra os seletores CSS globais que vazam entre os filhos: por exemplo, em .css-e7ylz8 .MuiTreeItem-group . Você não tem garantias de que o componente não aplica o estilo a um componente filho (não é o efeito que você esperava, uma surpresa!). Provavelmente OK para nossos componentes, pois seremos cuidadosos.
  2. Torne o manuseio de portais um acéfalo: https://material-ui.com/guides/interoperability/#portals. Para estilizar a dica de ferramenta, precisaremos estilizar o componente popper, não a raiz como fizemos com o Slider.
  3. A sintaxe $styleRule avisa se a regra de estilo não está definida.
  4. Permite personalizar os nomes das classes utilizadas. A solução atual é usar o componentsProps prop. Nós mesclamos os nomes das classes.

Existe um mundo alternativo onde poderíamos:

uma. Permite resolver 1. e 3. com seletores de componentes estilizados .
b. Exponha a API classes para compatibilidade com versões anteriores.
c. Para obter um. e B. funcionando, precisaríamos nivelar como os estilos do componente são escritos internamente. x componente estilizado em vez de 1 raiz estilizada. Mas ⚠️ com a implicação de perfeição.

Nós realmente precisamos fazer isso?


Eu olhei para a história do classes prop do jQuery UI. Eu poderia encontrar dois problemas: https://bugs.jqueryui.com/ticket/7053 , https://bugs.jqueryui.com/ticket/8928 e o commit inicial: https://github.com/jquery/jquery- ui / commit / c192d4086d9bbaf09d5f870857af30c60a427e22.

Em vez disso, imaginamos que as pessoas usem a seguinte sintaxe: https://next.material-ui.com/components/slider-styled/#unstyled -slider as classes são basicamente substituídas pelos seletores de classe disponíveis para cada slot no componente. Você também pode dar uma olhada no exemplo de personalização: https://next.material-ui.com/components/slider-styled/#customized -sliders

Como vantagem, você pode usar apenas os adereços e aplicar estilos dinâmicos baseados neles.

Uau, essa é a melhor coisa de todas.
Componentes sem estilo ou sem cabeça serão a melhor coisa para customização (um dos críticos do mui, eu acho).
Isso não é uma coisa pequena para consertar, mas uma grande vantagem para o MUI.

PS: Lembro-me de algumas dificuldades para personalizar alguns componentes no passado
PS2: Você deu uma olhada em https://github.com/modulz/stitches ?

Você notará que escrevi MuiSlider-rail acidentalmente. Anteriormente, com classes haveria algo como classes.rail, e se eu digitasse incorretamente a propriedade, receberia um aviso de tempo de execução de que classes.raill não existe na folha de estilo. Acredito que o Tema teve o mesmo comportamento?

@ianschmitz além da opção @oliviertassinari sugerida para usar os seletores de componentes estilizados, temos outra opção, que é expor constantes para as classes que expomos. Talvez algo como:

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

const StyledSlider = styled(SliderUnstyled)`
  & .${sliderClasses.rail} {
    display: block;
    position: absolute;
    width: 100%;
    height: 2px;
    border-radius: 1px;
    background-color: currentColor;
    opacity: 0.38;
  }
)

Não é o mesmo que o aviso de tempo de execução classes.rail , mas deve ajudar a evitar erros ortográficos nas classes.

@mnajdova Também podemos considerar um plugin eslint.

Com relação ao suporte no classes prop - para que possamos fazer isso de forma confiável, teremos que criar componentes para cada parte (slot) do componente principal. Por exemplo, para Slider , precisaríamos criar componentes para trilho, trilho, marca, rótulo de marca, polegar e rótulo de valor. Isso nos permitirá especificar os estilos diretamente nesses componentes, em vez de usar classes para aumentar a especificidade. Essas mudanças podem ser encontradas neste PR - https://github.com/mui-org/material-ui/pull/22893

Com essas mudanças, criamos um codesandbox, que pode comparar o desempenho deste novo componente Slider atualizado com o da v4, com estilo nativo, sem estilo, assim como com duas outras bibliotecas competitivas - https://codesandbox.io/s/ slider-compare-with-multiple-components-2tytc? file = / package.json

Se compararmos esses perf com o perf de ter apenas um componente e usar os seletores de classes para as partes dele - https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js notaremos que adicionar componentes por slot tem uma degradação de desempenho de 20% 😢

Versões de produção:

Para ser honesto, não sei neste momento se é melhor adicionar essa compatibilidade com versões anteriores ou não.

Esses são casos de uso reais para o suporte de classes ou é apenas para facilitar a atualização?
Podemos ter degradação de 20% do desempenho apenas para facilitar o caminho de migração?
Existe alguma alternativa que não podemos ver, que nos ajudaria a fazer ambos sem pagar o custo de desempenho?

@ianschmitz @ eps1lon @oliviertassinari e outros :) há alguma opinião sobre isso?

Contanto que possamos definir e usar temas e estilos com TypeScript, eu não me importaria de perder tempo migrando em comparação a perder 20% de desempenho

Geralmente fico curioso e me perdoe se não entendo o design subjacente, mas classes era uma API para JSS? Se o design da API está mudando de JSS para componentes estilizados, faz sentido continuar oferecendo suporte a classes ?

Esses são casos de uso reais para o suporte de classes ou é apenas para facilitar a atualização?
Podemos ter degradação de 20% do desempenho apenas para facilitar o caminho de migração?
Existe alguma alternativa que não podemos ver, que nos ajudaria a fazer ambos sem pagar o custo de desempenho?

Peço desculpas se perdi alguma coisa com a API proposta, mas, IMO, o caso de uso que mais vejo em nossa organização é a abstração do sistema de estilo subjacente usado pelo MUI. Sim, acho que classes é uma espécie de "API para JSS", como @ConAntonakos mencionou, mas para o consumidor isso não importava. Como consumidor, eu poderia usar a tecnologia CSS de preferência (há alguma limitação hoje com classes ?). Temos vários produtos que usam uma variedade de:

  • Arquivos CSS Vanilla
  • SCSS
  • JSS

dependendo das necessidades e preferências dessas equipes.

Exportar os nomes das classes ajuda se você estiver usando algum tipo de CSS-in-JS, mas o que você acha das que não estão?

RÉ. 20% de desempenho, concordo que provavelmente não é uma troca aceitável. No final do dia, vocês devem fazer o que é melhor para a maioria da comunidade. Apenas oferecendo meus pensamentos 😄

Um desejo que nunca tive foi que o material-ui fosse compatível com o nativo reagente. Muitos projetos são multiplataforma atualmente e ter uma solução de estilização unificada oferece muitas vantagens para componentes de plataforma cruzada. Acabamos enrolando nosso próprio usando material-ui no lado da web e react-native-paper no lado nativo e padronizando na API material-ui. Eu estaria interessado em entender se esta nova solução de estilo tornará o uso de (alguns / todos) os componentes da IU do Material em react-native? Qualquer referência de janela em componentes seria obviamente um bloqueador, mas o estilo em si também suporta nativo, não é?

@mschipperheyn react -native não tem objetivos até agora. É + 5% de potencial de uso (1 mês de crescimento) e + 50% a mais de esforço (um palpite). O custo de oportunidade é muito alto, sem nenhuma direção óbvia sobre como monetizá-lo (fora do modelo da Ionic). Além disso, essa vibração parece ter capturado uma grande parte do público que tem como alvo os nativos.

Agora que a v5 está em versão alfa, há uma solução para esse problema? Em particular, a solução de estilo ainda é baseada em JSS? Vimos problemas substanciais de desempenho relacionados ao JSS, portanto, estamos aguardando ansiosamente uma nova solução.

@zzzev Este não é um problema em si. É um thread RFC (Request for Comments).

Estou curioso sobre quais problemas substanciais de desempenho você está falando e como sair do JSS pode melhorar isso. Porque a meu ver é que se você tem problemas de desempenho, provavelmente não são os estilos, mas como eles são implementados, ou seja, o mesmo resultado poderia ser alcançado escrevendo os estilos de outra forma, usando menos poder de processamento.

No mínimo, não consigo entender como ir de JSS para Emotion (que é mostrado neste tópico para _mais provavelmente_ tem alguma degradação de desempenho) poderia melhorar alguma coisa.

Meu entendimento é que a emoção vai causar um pequeno golpe no desempenho dos estilos estáticos e muito melhor no desempenho dos estilos dinâmicos - mas talvez isso não seja bem assim? Existem muitos números diferentes neste tópico e é difícil conciliar em uma imagem de desempenho (e, obviamente, depende muito da situação de um indivíduo).

Quando você diz que devemos escrever os estilos de uma maneira diferente, você quer dizer evitar estilos dinâmicos? Ou existem outras práticas recomendadas que devemos considerar?

@zzzev Correto na primeira parte, não exatamente na segunda (a menos que você conte ir de não suportado para suportado como um ganho de desempenho infinito 🙂).

Emotion permite suporte para estilos dinâmicos, ao custo de um desempenho moderadamente mais lento para estáticos.

Estou confuso; não há estilos dinâmicos nos makeStyles / v4 atuais? por exemplo, este padrão

Estou confuso; não há estilos dinâmicos nos makeStyles / v4 atuais? por exemplo, este padrão

Existem, mas há um grande problema de desempenho conhecido. Minha equipe fica longe ATM

Eu simplesmente odeio estilo de componente
jss é bom, mas existem alguns problemas na depuração, desempenho e ainda alguns bugs ainda não resolvidos, como aninhados como &:after

são meus pacotes construídos para react-native e react-native-web
https://www.npmjs.com/package/@material-native-ui/theme -provider

Eu gostaria de algo assim (é construído em cima de RN e RNW)

Portanto, há uma conclusão sobre a solução de estilo recomendada para usar com o Material UI v5? Parece que há uma intenção de se afastar do JSS sobre o qual @material-ui/styles está atualmente construído. Ou @material-ui/styles será refatorado para se basear em outras soluções de estilo como styled-components ?

Portanto, há uma conclusão sobre a solução de estilo recomendada para usar com o Material UI v5? Parece que há uma intenção de se afastar do JSS sobre o qual @ material-ui / styles está sendo desenvolvido atualmente. Ou @ material-ui / styles será refeito para construir outras soluções de estilo, como componentes estilizados?

@ matthewkwong2 não adotaríamos o pacote @material-ui/styles para o novo mecanismo estilizado, ele continuará suportando jss. Na v5, ele será isolado do resto da base de código e planejamos removê-lo na v6, para ajudar na transição para o novo mecanismo de estilo.

Para a v5, teremos novas práticas de batida em relação à solução de estilo, como o sx prop e o utilitário styled , ainda trabalhamos na documentação em torno disso.

Além disso, as substituições e variantes de tema ainda terão suporte na v5.

Para a v5, teremos novas práticas de batida em relação à solução de estilo, como o suporte sx e o utilitário estilizado, ainda trabalhamos na documentação em torno disso.
Além disso, as substituições e variantes de tema ainda terão suporte na v5.

Portanto, se bem entendi, para o estilo de componentes individuais, é recomendado usar sx ou styled vez de makeStyles .

Mas e quanto ao tema (ou seja, createMuiTheme )? Eu acredito que essa parte também é construída sobre JSS, certo? Qual seria a forma recomendada de criar um tema (ou seja, com o objetivo principal de definir estilos globais) agora?

Ainda mantemos a mesma estrutura para a criação do tema, apenas esperamos que os valores para as substituições e variantes de componentes sigam a sintaxe para componentes de emoção / estilo. Não há mudanças na forma como o tema é criado, a API é exatamente a mesma, o mesmo contexto de tema é reutilizado para o novo mecanismo de estilo também. Isso faz sentido @ matthewkwong2 ?

@mschipperheyn react -native não tem objetivos até agora. É + 5% de potencial de uso (1 mês de crescimento) e + 50% a mais de esforço (um palpite). O custo de oportunidade é muito alto. Além disso, essa vibração parece ter capturado uma grande parte do público que tem como alvo os nativos.

Não quero nos levar a uma tangente muito grande, mas gostaria de voltar atrás em alguns desses fundamentos.

  • No passado, ao criar aplicativos RN, uma das coisas mais difíceis de lidar era o material design. Na verdade, era um problema grande o suficiente que poderia decidir se deveria se preocupar em criar um aplicativo móvel. Ouvi dizer que é um pouco melhor com uma nova biblioteca promissora. Mas eu duvido que seja tão promissor quanto seria se MUI estivesse na mistura. Talvez seja só eu, mas pude ver um MUI de plataforma cruzada realmente aumentando o uso de RN. Eu sei que é apenas uma pequena fração do uso do react-dom, mas a web é enorme e o react-dom domina os frameworks web modernos . Mesmo que o uso de reagir nativo é relativamente pequeno, que ainda pode ser um número razoável de pessoas como um absoluto que iria utilizá-lo. Uma pesquisa com os usuários atuais do MUI provavelmente seria uma métrica melhor do que as estatísticas do npm.
  • Eu sei que estou fora do circuito, mas não acredito que o Flutter assumiu o React Native. Essa comparação de tráfego não é realmente uma ótima maneira de comparar. É afetado por muitos fatores de confusão (o Flutter é mais recente, então mais pessoas já conhecem o RN e não precisam consultar a documentação; a documentação do Flutter poderia ser mais útil referenciando o aumento do tráfego; Parte do tráfego de leitura de documentos do RN também pode estar acontecendo para Expo em vez). Essa comparação um tanto falha do
  • JSS foi um dos maiores problemas (na verdade, possivelmente o maior) em fazer o MUI funcionar com o React Native. Eu sei que ainda haverá alguns fatores complicadores, mas IMHO a mudança para a emoção provavelmente eliminou 2/3 da dificuldade em fazer o MUI funcionar no RN, pelo menos experimentalmente.

a mudança para a emoção provavelmente eliminou 2/3 da dificuldade em fazer o MUI funcionar no RN

Estamos ansiosos para ver seu POC 😄

Estamos ansiosos para ver seu POC 😄

Adoraria brincar com ele se tiver uma chance. Mas as pessoas geralmente não se incomodam em fazer POCs para coisas pelas quais os mantenedores mostram desinteresse. Não adianta construir algo quando a atmosfera atual é que provavelmente acabará abandonado. Daí porque eu quero afastar de descartar o valor do RN ou o valor do RN como uma possibilidade para o futuro.

Duas questões:

  1. Você pode usar a nova solução de estilo sem HOCs? Eu, por exemplo, adoro a API de gancho React que o MUI possui atualmente ... não tenho certeza se a sintaxe estilizada também é um HOC subjacente, mas isso superaria os esforços (praticamente em todos os lugares nas bibliotecas React) para se afastar dos HOCs.
  2. O classes prop a maioria dos componentes ainda terá suporte (daria total flexibilidade na solução de estilo que os usuários podem usar)?

o fast-refresh é habilitado por padrão no create-react-app v4 . devemos adicionar suporte de atualização rápida como um novo requisito?

Tentando fazer isso com Gatsby. Quando eu faço import { Link } from '@material-ui/core' , recebo:

Can't resolve '@emotion/core' in 'node_modules/@material-ui/styled-engine'
File: node_modules/@material-ui/styled-engine/index.js

Can't resolve '@emotion/styled' in '/node_modules/@material-ui/styled-engine'
File: node_modules/@material-ui/styled-engine/index.js

Quando alterado para import Link from '@material-ui/core/Link' problema desapareceu.

Se eu instalar @emotion/styled @emotion/core terei:

Não é possível resolver '@ emotion / react' in '/ node_modules / @ emotion / styled / dist'

Então eu instalo @emotion/react .

Ocorre um erro de tempo de execução.

Error: The `@emotion/core` package has been renamed to `@emotion/react`. Please import it like this `import { jsx } from '@emotion/react'`.
./node_modules/@emotion/core/dist/emotion-core.cjs.dev.js
node_modules/@emotion/core/dist/emotion-core.cjs.dev.js:3

Versões de pacote envolvidas:

    "@emotion/core": "^11.0.0",
    "@emotion/react": "^11.0.0",
    "@emotion/styled": "^11.0.0",
    "@material-ui/core": "^5.0.0-alpha.15",
    "@material-ui/lab": "^5.0.0-alpha.15",

Instale versões v10 dos pacotes Emotion

Oh 11 é a versão "mais recente" agora, então eu acho que mui precisa atualizar ou documentar isso

Oh 11 é a versão "mais recente" agora, então eu acho que mui precisa atualizar ou documentar isso

Temos isso documentado por meio de intervalos de versão em peerDependencies . Não o mencionamos explicitamente nas instruções de instalação, pois planejamos atualizá-lo para a v11 em breve.

Lembrete amigável de que este é um alfa e uma emoção de apenas alguns dias atrás. Como um pioneiro, você deve esperar algumas arestas.

Olá a todos, sou novo aqui e estava procurando soluções de css de interface do usuário material e cheguei a esse problema.
Apenas dando meus 2 centavos sobre isso, gostaria de sugerir Linaria https://github.com/callstack/linaria.
É uma biblioteca de tempo de execução zero, com extração de css e variáveis ​​CSS como adereços do React.

Espero que isso ajude neste RFC 😄.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

chris-hinds picture chris-hinds  ·  3Comentários

reflog picture reflog  ·  3Comentários

ryanflorence picture ryanflorence  ·  3Comentários

activatedgeek picture activatedgeek  ·  3Comentários

mattmiddlesworth picture mattmiddlesworth  ·  3Comentários