@ callemall / material-ui, por favor, deixe algumas informações aqui quando puder 👍
Precisamos decidir sobre uma solução de estilo para 0.16.0
que ajudará a resolver problemas antigos. Fora os problemas de desempenho, existem hacks e adereços em todos os lugares para compensar o fato de estarmos perdendo alguns dos recursos poderosos do CSS que não podem ser usados com estilos embutidos - pseudo classes, consultas de mídia (sem matchmedia ), etc.
Pelo que entendi, o consenso geral é que queremos uma solução de estilo JS que tenha a capacidade de escrever estilos em uma folha de estilo real no DOM.
Aqui estão algumas das soluções mantidas que fazem isso:
https://github.com/rofrischmann/react-look
https://github.com/Khan/aphrodite
https://github.com/jsstyles/react-jss
Aqui estão alguns pontos que precisamos considerar ao implementar a nova solução (IMO):
react-look
, tente e veja como podemos importar módulos para um tamanho mínimo de compilação.Algumas outras perguntas:
6) Removeremos ou teremos como objetivo remover xxxxStyle
props e faremos os usuários passarem xxxClassName
para modificar estilos? Ou serão complementares?
7) Vamos permitir a substituição de estilos via CSS e simplificar as interfaces de nossos componentes. Portanto, se eu quiser substituir menuItemStyle
no IconMenu, devo criar uma substituição de tipo style = StyleSheet.create({ IconMenu: {MenuItem: { color:red }})
?
@chrismcv Minha opinião pessoal é que definitivamente precisamos aproveitar a solução para remover esses adereços superespecíficos que estamos vendo propostos: [TextField] add floatingLabelFocusStyle prop # 4043
Antes de sabermos, as pessoas vão pedir adereços para estilos de subcomponentes para cada estado de foco / ativo / pairar / qualquer que seja possível.
Vejo tantos problemas que são "como estilizar XXXX", "não é possível estilizar XXX dentro de YYYY", "adicione somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
prop a XXX, por favor"
@chrismcv em 6. em relação aos xxxxStyle
props mais gerais vs classNames, o que você acha? com alguns de nossos componentes, você precisará ser capaz de alcançar de uma forma ou de outra (felizmente, poderemos usar :hover
etc!).
@chrismcv Acho que xxxxStyle
props devem ir na propriedade style
, não no objeto de estilo className
-ified.
@nathanmarks Obrigado por iniciar a conversa. Esse é definitivamente um dos principais problemas que precisamos abordar nos próximos lançamentos 💯.
Fora dos problemas de desempenho
Para mim, essa é uma das principais preocupações que tenho com a solução que vamos escolher.
Não temos muitos benchmarks, mas podemos facilmente imaginar que perdemos muitos ciclos de CPU com nossa abordagem atual. Os ciclos da CPU são perdidos em alocações de memória e coleta de lixo para nosso objeto de estilo inline.
@oliviertassinari
Estou testando algumas das soluções de estilo JS no momento. É interessante, mas claro que ainda é "primeiros dias", por assim dizer.
Uma coisa que eu estava pensando - fora das propriedades de estilo dinâmico (por exemplo, se o componente tem um color
prop), deveríamos mudar a maneira como criamos o objeto de estilo base?
Parece que com as bibliotecas de estilo JS, para obter o desempenho máximo, você deve usar seu método StyleSheet.create()
uma vez e ter chaves (css "classes") nesse objeto para props / estados como open={true}
em vez de construir dinamicamente o literal de objeto de estilo com algumas propriedades condicionais e passá-lo para o método de fábrica de folha de estilo a cada renderização de cada estilo.
Mesmo que os seletores de folha de estilo sejam armazenados em cache no sentido de que são gravados apenas uma vez no DOM (e em algumas bibliotecas apenas gravados no DOM quando necessário para render()
), ainda estamos desperdiçando recursos com alguns cálculos + criação de objeto + coleta de lixo como você mencionou acima, se estivermos criando um novo objeto de estilo a cada renderizado apenas para que seja jogado fora.
Hmmm ... deixei um comentário aqui ontem (domingo). Ele foi excluído?
@rvbyron Lembro-me claramente. Eu certamente não o apaguei.
@rvbyron Eu também me lembro. Eu não tenho idéia do que aconteceu.
@rvbyron - tinha no meu e-mail, então de volta aqui na forma de citação!
Bem, eu, pelo menos, gostaria de ver uma série de coisas acontecendo.
A) Sim, de forma alguma, livre-se de usar o parâmetro de estilo do elemento no nível da biblioteca. Todos os componentes devem ser definidos usando className. Ter os componentes usando estilo destrói todo o poder que o CSS oferece.
B) Seria ótimo ter classNames automaticamente anexado ao elemento raiz de cada componente (por exemplo, O componente RaisedButton teria implicitamente className = "mui-raised-button" no elemento raiz do componente). Isso tornaria o estilo muito mais fácil. Isso pode até ser configurável.
C) Obtenha o tema dos arquivos muiTheme.js juntos. Um arquivo muiTheme.SCSS de themeing seria muito melhor, pois permitiria que quaisquer propriedades escolhidas pelo criador do tema fossem aplicadas e não apenas aquelas especificamente permitidas pelo componente. É claro que isso provavelmente exigiria que B fosse implementado e ativo.
D) React-look parece ser um bom meio-termo, pois converte objetos JSON contendo propriedades de estilo em classNames. Isso torna as coisas mais fáceis de substituir. Porém, como falei em C acima, ainda gostaria que a base temática fosse criada no SCSS. Estou bem aberto sobre qual pacote de assistência CSS usar. Mas eu ficaria longe de qualquer coisa que quisesse usar o parâmetro de estilo do elemento em vez do parâmetro className.
@chrismcv Obrigado cara!
Acho que o que @rvbyron tem a dizer é importante porque, de certa forma, o estilo JS é uma mudança de paradigma do CSS normal. A maioria das pessoas não usa o estilo JS em seu trabalho diário e isso requer uma maneira diferente de pensar + torna mais difícil para os designers que geralmente podem contribuir para projetos que não são tão proficientes em JS.
É importante considerar todos os ângulos aqui.
@oliviertassinari @chrismcv
Uma coisa que percebi sobre react-look
é que você precisa envolver todos os seus componentes no look
HoC . Isso parece muito invasivo, ele até sequestra a função render()
, armazena super.render()
em um const
e executa operações de resolução de estilo dessa maneira. Algumas outras soluções, como Khan / aphrodite, requerem apenas um wrapper de função em torno da referência styles.xxxx
de Stylesheet.create()
dentro de className={}
.
O sequestro da função render()
apenas para css parece um excesso de engenharia para mim. Isso me diz que o conjunto de ferramentas / suporte integrado do React para esse tipo de funcionalidade de estilos profundamente integrados simplesmente não existe, não tenho certeza sobre a ideia de um HoC auxiliar CSS controlando a renderização de todos os nossos componentes.
Pensamentos?
Olá, equipe do Material-UI!
Tenho seguido você por um tempo e agora, vendo este tópico, também gostaria de contribuir com algumas idéias sobre por que mudar de estilos inline para css pode ser uma boa ideia. Eu li muitas discussões neste repositório que cobrem o desempenho de renderização, estilos filhos / elementos aninhados, as consultas de mídia, pseudoelementos, etc., então vou me concentrar em outra coisa que ainda não discuti, mas acho que também é relevante. E é uma organização de estilos. Aqui está o que quero dizer:
size={40}
define largura, altura e altura da linha para 40px
)Quando se trata de ajustar os estilos, existem pelo menos 4 locais diferentes (👆) para olhar, o que torna difícil investigar os problemas.
Quando os estilos vêm com css, você vê o seletor e sabe exatamente onde corrigir. Com estilos embutidos, leva tempo para entender de onde vem a propriedade específica, e onde e o que deve ser modificado. E se o desenvolvedor modificá-lo no lugar errado (digamos na área styles
vez do parâmetro size
, já que nada realmente diz que size
é o estilo), isso afetará o width=height=line-height=40px
bloqueará o desempenho inteiro ou levará à escrita novamente width/height/line-height
que tornará o parâmetro size
inaplicável.
Além disso, também torna difícil investigar quais dos elementos pais têm propriedades específicas aplicadas, porque tudo o que você pode ver no inspetor é element.style
.
Quando os estilos vêm com seletores (nomes de classes), isso dá muito mais controle sobre a estrutura dos estilos do que os estilos embutidos.
Atualização: Esqueci de mencionar a sugestão (da qual trata este tópico):
/component
--component.js
--component.css (or sass that is converted to css when the page is rendering)
Essa estrutura manterá o componente no escopo, mas dará mais controle sobre o estilo. E uma convenção de className BEM ajudará a evitar aninhamento desnecessário:
.mui-component {}
.mui-component__child {}
O que no geral ajudará a implementar, ajustar e manter os estilos de interface do usuário do material.
@chrismcv
Obrigado por encontrar o e-mail e colocá-lo no comentário!
Que tal um conceito de "comportamento" de importar a técnica de estilo que melhor se adapte às suas necessidades. Uma importação de "StyleTheme" ou "ClassTheme" pode ser usada para selecionar o comportamento. StyleTheme pode se referir ao objeto muiTheme que o material-ui possui hoje e deixar felizes os desenvolvedores de estilos centrados em componentes. Ou ClassTheme que usaria um arquivo SCSS que é construído a partir do objeto muiTheme.js (sincronizado), deixando felizes os desenvolvedores CSS centrados. Isso significaria que todos os componentes precisariam acomodar {... theme.ComponentName} nos elementos de renderização.
Para oferecer um exemplo muito simplificado, um componente RoundButton teria o método de renderização como:
render() {
return (<button {...theme.RoundButton} />);
}
Para o comportamento StyleTheme, theme.RoundButton conteria:
{
style: {
display: 'inline-block';
borderRadius: '20px';
width: '40px';
height: '40px';
}
}
Para o comportamento ClassTheme, theme.RoundButton conteria:
{
className: 'mui-round-button'
}
Uma combinação dos dois poderia ser recuperada como comportamento ClassStyleTheme, theme.RoundButton conteria ambos:
{
className: 'mui-round-button',
style: {
display: 'inline-block';
borderRadius: '20px';
width: '40px';
height: '40px';
}
}
O arquivo mui-theme.scss seria gerado a partir do arquivo muiTheme.js e refletiria no SCSS as propriedades exatas que o arquivo JS contém. As maiúsculas e minúsculas dos nomes JS seriam convertidas em nomes de classe mais padrão:
mui-round-button {
display: inline-block;
border-radius: 20px;
width: 40px;
height: 40px;
}
Qualquer customização CSS para os componentes MUI seriam simplesmente classes idênticas carregadas após o arquivo mui-theme.scss ser carregado, substituindo assim as propriedades mui-theme.
@oliviertassinari
Acho que usar algo como scss
(+ módulos css para namespacing / hashing) traz muitos benefícios. É algo a que você se opõe 100%? Provavelmente sou um pouco tendencioso porque é o que estou acostumada a usar no trabalho, mas muitas pessoas estão no mesmo barco.
Meu principal problema com a situação de estilo do JS é que parece que todas as soluções ainda são um trabalho em andamento. Não há muitas avaliações de desempenho no mundo real para serem observadas, as bibliotecas que estamos examinando não foram comprovadas e sinto que estamos gastando muito do nosso tempo tentando descobrir como fazer estilos em JS de maneira adequada. O principal objetivo desta biblioteca é implementar as especificações do material design e não posso deixar de sentir que isso está nos prejudicando no momento. (nós definitivamente precisamos classificar os problemas de impacto de desempenho)
Acho que temos preocupações diferentes em relação a isso.
Tudo parece bom quando você está escrevendo um aplicativo, ninguém fora do seu código precisa mudar nada.
Mas com as bibliotecas as coisas são diferentes, todas as preocupações acima estão lá, mais as seguintes:
O que temos agora de alguma forma lida com todas essas preocupações com estas advertências:
somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
Se mudarmos nossa abordagem de estilo, teremos que fazer tudo de novo. Nesse caso, devemos responder a todas essas perguntas antes de iniciar a migração.
Na minha humilde opinião, acho que o CSS e o que quer que seja compilado para ele não fazem parte do futuro. Acho que todos concordamos que os estilos inline tornaram nossas vidas muito mais fáceis. Honestamente, a única limitação que vejo nos estilos embutidos é :hover
!
Podemos resolver esses problemas fazendo um pouco de design.
ListItem
com MUITAS pequenas funcionalidades embutidas nele? podemos dividi-lo e torná-lo combinável, então não temos que adicionar monstruosidades como somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
:hover
Acho que podemos conviver com isso até que os navegadores ou reajam a respeito.Meu ponto é, já tratamos de um grande número de preocupações com nossa abordagem de estilo atual. Tem limitações porque não seguimos todos os padrões em torno dos estilos embutidos. se começarmos a quebrar nossos componentes e torná-los muito mais combináveis, não precisamos nos preocupar com nada. pegue MeuItem
Eu tirei isso e tornei-o combinável, você vê como é fácil de usar e como o desempenho pode ser melhorado usando renderização pura!
Portanto, em vez de mudar nossa abordagem e resolver todos esses problemas novamente, vamos investir tempo melhorando o que já temos. não precisamos oferecer suporte a consultas de mídia, podemos alterar nossos componentes de uma maneira que seja fácil para outros implementarem a capacidade de resposta neles. Difícil de depurar? se quebrarmos nossos componentes, os estilos embutidos serão menores e mais fáceis de ler. discutível embora! Quero dizer, tudo que você precisa é um ponto de interrupção para ver o que participa de Object.assign
para ver de onde vêm os estilos.
É claro que é minha opinião. Estou muito aberto à discussão.
@alitaheri
Você levantou alguns pontos importantes. Obrigado. Estou me perguntando se algum tipo de solução híbrida é uma possibilidade. Parece que não importa o ângulo que tomemos, há um monte de problemas 😆
Tenho tempo para trabalhar nisso na próxima semana - vamos conversar e ver se podemos ter uma ideia inteligente.
Eu concordo em tentar minimizar a quantidade de mudanças e ter que resolver novamente os problemas já resolvidos. Existem 2 objetivos importantes aqui em minha mente:
Preciso pensar mais nisso 😄 mas enquanto conseguirmos resolver esses 2 pontos ficarei feliz com a nossa solução.
Outra observação aleatória - seria ótimo se tivéssemos uma maneira automatizada de impor certas convenções de código e padrões de design para / jsstyle / qualquer que seja na biblioteca.
É algo a que você se opõe 100%?
@nathanmarks Não sou 100% contra o uso de SCSS ( beco sem saída .
Uma das principais vantagens do React é abstrair a especificidade de renderização dos navegadores: o DOM.
Até onde eu sei, o objetivo de longo prazo da Equipe Central do React é fornecer uma API para escrever componentes de plataforma cruzada. Na verdade, eles estão fazendo experiências nessa direção. SCSS não ajudará.
Eu concordo totalmente com @alitaheri. Podemos começar com essas duas etapas:
getStyles
todos os lugares para que possamos migrar mais facilmente mais tarde.@oliviertassinari Concordo com a conclusão sem saída - não é o futuro. Eu a mencionei principalmente para estimular a conversa sobre como fazer os estilos JS funcionarem para nós. Eu sabia que algumas pessoas por aqui tinham algumas boas ideias em relação aos problemas 😄 Gostaria que o FB fosse _ um pouco_ mais adiante com seus experimentos!
Na verdade, acho que o padrão getStyles()
que empregamos atualmente tem seus próprios problemas. @alitaheri e eu tivemos uma boa conversa hoje sobre o que fazer para melhorar nossa configuração de estilo JS (incluindo temas!). Eu responderei amanhã com mais algumas informações assim que eu tiver a chance de fazer algumas anotações!
Na próxima semana, estou de férias e vou experimentar uma solução para nossos problemas atuais, mantendo todos os estilos baseados em JS.
Basta ler este post sobre Lições Aprendidas no React Amsterdam (https://medium.com/@kitze/lessons-learned-at-react-amsterdam-51f2006c4a59#.o12h794or) e uma das apresentações foi sobre soluções para estilização no React: http : //slides.com/kof/javascript-style-sheets#/ Uma apresentação oportuna para esta discussão.
Um requisito que fico pensando e que não vi explicitamente declarado (pelo menos que me lembro) é a necessidade de oferecer suporte apenas para web versus web e reagir de forma nativa. Se a intenção for apenas web (ou seja, reagir nativo não é um requisito), então as soluções que aproveitam o que os navegadores já suportam de forma eficiente e robusta e as pessoas estão muito familiarizadas seriam uma boa coisa. Se o suporte a reagir nativo é uma necessidade, isso abre um conjunto diferente de necessidades e requisitos. Apenas algo para pensar e manter em mente enquanto as escolhas de tecnologia, compromissos, etc. são avaliados.
@hburrows
Obrigado por compartilhar essa apresentação!
@alitaheri
Podemos querer dar uma olhada na biblioteca mencionada nessa apresentação ( aqui está uma demonstração ). Isso pode nos poupar muito trabalho. Eu estava olhando para isso antes, mas havia algumas coisas que eu não gostei (como a necessidade de envolver cada componente em um HoC proprietário). No entanto, há alguma discussão sobre isso acontecendo aqui . Ele menciona que implementar mudanças como essa permitiria o uso livre de HoC. Eu prefiro esse método / design para escrever a folha (também visto em aphrodite
).
Alternativamente, podemos sempre criar nossas próprias associações de reação para jss
que podem funcionar com mixout
.
O autor da lib também disse isso, o que está de acordo com meus próprios pensamentos sobre o assunto 👍:
No entanto, você precisa entender que nem tudo faz sentido ser folhas de estilo. Para as mudanças mais dinâmicas, você deve usar estilos embutidos.
@nathanmarks A implementação é bastante pequena e muito fácil de misturar: grin:
https://github.com/jsstyles/react-jss/blob/master/src/index.js
Acho que esta biblioteca pode nos ajudar: +1:
@alitaheri Sim, concordo!
Estou testando alguns vínculos personalizados para jss
também - há alguns problemas / limitações que quero tentar resolver. (Um, porém, pode exigir trabalho na biblioteca central)
Parece haver um sentimento prevalecente na comunidade React de que o estilo JavaScript é a melhor solução. Esse sentimento é bom, não estou em desacordo com quem o tem. No entanto, a maneira como o estilo do JavaScript é implementado quase sempre não leva em consideração o desenvolvedor CSS. A implementação muitas vezes favorece style=/[element property]=
vez de className=
e impede o desenvolvedor CSS de fazer seu trabalho.
Como mencionei em um comentário anterior, acho que os dois poderiam viver bem juntos. Deve-se simplesmente adotar uma abordagem comportamental para aplicar as propriedades de estilo. A biblioteca deve acomodar a aplicação direta de propriedades de estilo a um elemento ou deve permitir a abordagem indireta de criar um className composto dessas propriedades de estilo. Uma biblioteca que permite ao desenvolvedor escolher o comportamento parece a solução ideal.
Existem muitas razões pelas quais os desenvolvedores de CSS não querem simplesmente abandonar sua abordagem. Pesquise "por que usar css" para ver por que as pessoas acham que ele é benéfico. Você encontrará abstração de estilos e uma linguagem de seleção poderosa entre seus benefícios. Não vamos esquecer a enorme quantidade de código que existe hoje que beneficia os usuários de CSS.
Novamente, este não tem a intenção de ser um comentário CSS profissional de forma alguma. Alguns de nós gostariam de usar CSS para estilizar. Este comentário tem como objetivo encorajar uma abordagem de estilo arquitetonicamente neutra que permite que os desenvolvedores tenham escolha.
@rvbyron Um dos principais motivos pelos quais queremos mudar nossa abordagem atual é tornar mais fácil personalizar os componentes usando css também. usar uma biblioteca como jss
nos permitirá usar os recursos de css enquanto tiramos proveito de js-styles. E uma vez que transforma esses estilos em css, eles podem ser facilmente substituídos por um nome de classe extra sem o hack feio !important
.
@alitaheri Bom saber! Estou realmente ansioso para ver o material-ui acomodar uma abordagem baseada em className.
Mais uma vez, é fantástico ouvir sobre a abordagem className. Com isso em mente, tenho algumas perguntas sobre como ele pode ser implementado:
@rvbyron
Idealmente:
Prefixo personalizável. Notação de traço de algum tipo para melhor experiência de desenvolvimento e um sufixo hash que também pode ser definido como uma string fixa (portanto, não muda se as configurações do tema são alteradas) usando um ID de tema personalizado. Incluindo uma opção de produção menos detalhada ou até mesmo uma função de retorno de chamada para personalizar. E eu presumo que uma aula sobre o root geralmente sempre será necessária de qualquer maneira.
Acho que há muitos requisitos listados e sugestões oferecidas. Então, há uma lição em toda essa discussão? Qual é o próximo curso de ação? Há algum trabalho sendo feito para implementar o react-jss neste material-ui?
@rvbyron Sim, estamos experimentando algumas ideias
Na minha humilde opinião, acho que o CSS e o que quer que seja compilado para ele não fazem parte do futuro. Acho que todos concordamos que os estilos inline tornaram nossas vidas muito mais fáceis. Honestamente, a única limitação que vejo nos estilos embutidos é: hover!
A questão é: pairar é uma parte muito básica e vital dos estilos. Futurismo à parte, pode ser prudente evitar o compromisso prematuro com uma solução que deve recorrer a cheats e soluções alternativas para reimplementar um recurso nativo.
@wtgtybhertgeghgtwtg , estamos trabalhando em uma solução que usa folhas de estilo reais para que funcionalidades como :hover
sejam suportadas.
Dado que os pontos principais foram decididos (estilo JSS via className e elemento raiz classNames), existe algum roteiro e cronograma para o lançamento do material-ui v0.16.0?
@rvbyron Não temos um cronograma prometido, mas a partir de agora, a abordagem de estilo e desempenho são nosso foco principal para a versão v0.16.0 e algo em que estamos trabalhando ativamente agora. Provavelmente usaremos esse problema em um futuro próximo para feedback da comunidade, uma vez que definimos a direção certa em algumas outras áreas no que se refere a internos, API, migração, etc.
@newoga Obrigado Neil! Agradeço a atualização. Quanto às outras questões, gostaria de acrescentar que apenas ir para um sistema baseado em className pode ser uma mudança visualmente inovadora para muitos e eu sugeriria limitar esta versão apenas a isso. Outras mudanças além dessas podem realmente impedir uma migração. No entanto, sei que sua equipe escolherá o melhor equilíbrio.
@newoga aqui, jss foi apontado como o futuro do sistema de estilo para material-ui. Este é um plano concreto o suficiente para que outros possam começar a integrar jss em nossos projetos agora, em antecipação ao lançamento 16.0?
@sorahn ainda não
@sorahn Este problema foi criado para obter feedback da comunidade sobre o que ainda é um problema realmente desafiador de resolver. Nenhuma decisão oficial foi feita. A partir de agora, todos devem escolher e usar apenas uma biblioteca de estilos ou abordagem que tenham avaliado ser a melhor para eles e seus projetos.
Para que conste, o objetivo dessa mudança de estilo não é migrar todos para algum padrão diferente, mas tornar mais fácil usar e estilizar os componentes da interface do usuário do material, independentemente da abordagem de estilo que você usa com ele.
tl; dr Não! Faça o que é melhor para você, não o que os outros dizem :)
@nathanmarks @newoga Obrigado pela atualização!
Estamos enfrentando as limitações de design responsivo + renderização do lado do servidor com todos os estilos embutidos, portanto, estamos investigando as alternativas. Não há opiniões particularmente fortes sobre (s) css-modules ou csx ou qualquer outra coisa, mas nós amamos o material-ui, então seria ótimo apenas acompanhar o que quer que vocês façam :)
Corri para consultas de mídia, li este tópico (e outros). Eu mergulhei em algumas das soluções e artigos potenciais.
Eu realmente gosto da solução JSS + CSX (da perspectiva do desenvolvedor _joy_).
Benefícios e desempenho do JSS
Semelhante ao @sorahn , ficaria feliz em adotar um padrão material-ui, espero que @nathanmarks trabalhe nessa direção valide essa abordagem. Além disso, parece que ambos os desenvolvedores CSX / JSS estão ansiosos para ajudar e promover a adoção de suas bibliotecas.
@rosskevin Trabalhando nisso enquanto falamos - há coisas a considerar aqui que não foram abordadas em nenhuma das soluções até agora.
Nossos requisitos são muito mais amplos do que as soluções existentes são capazes de suportar devido a limitações de design ou opiniões. Isso ocorre principalmente porque as soluções existentes foram desenvolvidas com aplicativos em que você tem controle total sobre o consumo de suas APIs de componentes em comparação a uma biblioteca onde você tem um conjunto diversificado de usuários que desejam definir o estilo de seus componentes com ferramentas diferentes.
@sorahn Pergunta rápida - o que você está fazendo sobre prefixos de fornecedores com renderização do lado do servidor? Você está apenas renderizando todos os prefixos no servidor? Ou você está passando pela UA?
@nathanmarks Estamos enviando o agente do usuário para o navegador, mas pessoalmente não gosto de confiar nisso. Que tal apenas colocá-los todos por padrão e permitir que as pessoas os substituam por meio de props no objeto muiTheme, ou o contrário, não fazer nada por padrão e permitir que as pessoas optem por isso.
muiTheme: {
// other stuff...
stylePrefixes: ['webkit', 'moz', 'ms']
}
@sorahn Você poderá fazer o que quiser, prefixar, não prefixar, passar all
, passar um UA, etc.
@nathanmarks Acabei de lançar [email protected]. Mudança mais importante - geração de id determinística, aqui está um exemplo de ssr com react http://jsstyles.github.io/examples/index.html
Apenas colocando meu $ 0,02 aqui ... embora eu realmente goste da ideia de estilos embutidos e afrodite me atrai, quase parece que seria mais fácil se os estilos fossem baseados em um formato de biblioteca em scss como bootstrap 4.
O que eu geralmente faço é literalmente copiar o arquivo bootstrap.scss e o arquivo _variables.scss ao criar um arquivo _mixins.scss ... com essa cópia em ./lib/style, eu atualizo o arquivo bootstrap.scss local para fazer referência ao local variáveis e mixins, enquanto usa o caminho para as versões do node_modules de todo o resto ...
Em seguida, configurei minha configuração do webpack para tornar ./lib/style parte do caminho de pesquisa para a configuração do sassLoader.
Desta forma, posso ter um arquivo main.scss que carrega bootstrap, etc ... Posso a partir daí referenciar variáveis e / ou mixins dentro do resto do meu projeto, e quando eu construo / agrupo a saída, os estilos apropriados são incluído.
O lado ruim disso é que ele prescreveria o uso de material-ui como fonte (não pré-compilado) e webpack para incluir scss nos pacotes. Dito isso, provavelmente seria o caminho mais simples de usar variáveis, classes e mixins de estilo existentes.
Novamente, eu realmente gosto da ideia do estilo JS, e tbh gosto do que Afrodite tem a oferecer ... Eu estava trabalhando em algo semelhante (ia chamá-lo de derma) como uma biblioteca de estilos para estilos embutidos, mas Afrodite já faz tudo que eu planejado e muito mais.
A solução de estilo está finalizada?
Há alguma atualização sobre isso?
Sim, a filial next
está usando jss
Acabei de encontrar este projeto e estava extremamente animado com ele porque parecia ótimo, a página de exemplo tornava muito fácil descobrir como usar os componentes e parecia que era amplamente utilizado; no entanto, estou muito desapontado com os estilos inline e estou feliz em ver que vocês estão se afastando deles. Uma das coisas que eu gostaria de apontar é que qualquer coisa que tenha a ver com layout fora desses componentes deve ser removida e deixar que o estilo do componente pai cuide disso. O componente de nível mais baixo não deve ter margens ou preenchimento de qualquer forma que afaste os elementos circundantes ... especialmente porque é quase impossível de substituir sem mexer com os stiles embutidos, o que significa que preciso procurar e descobrir como fazer este. Eu realmente não cavei muito neste projeto porque infelizmente o acho inutilizável. Eu certamente li muitas das discussões sobre estilo inline versus estilo CSS. De qualquer forma, você me perdeu no TextField. Há uma margem superior de 14 px e inferior de 16 px. Eu não me importaria muito de escrever um estilo simples para substituí-lo, mas isso é impossível por causa do estilo embutido e seria completamente louco para mim ter que criar um componente de nível superior apenas para reverter isso, como envolver seu componente com um div e fazendo margem: -14px 0 -16px ou ajuste levemente com um cálculo do jeito que eu quero, mas ter que corrigir isso de qualquer forma não deveria ser realmente necessário. Eu preferiria muito mais se você permitisse que um className fosse passado como um acessório, como você já faz, para que o estilo do layout pudesse ser aplicado ao componente da maneira que sua comunidade deseja. Enfim, são meus $ 0,02.
Para adicionar a isso, criar componentes de tipo de layout para eles ou fazer adereços adicionais para lidar com as propriedades de layout pode ser ideal, como usar um sistema de grade como o Foundation e o bootstrap fazem. Por exemplo, usando adereços como tamanho, calha, largura, colunas, etc., mas comece sem nenhum estilo ao redor do que é visível com o componente.
Estou completamente com @ jbsmith969
seria completamente louco para mim ter que criar um componente de nível superior apenas para reverter isso como envolver seu componente com uma div e fazer a margem: -14px 0 -16px ou ajustá-lo levemente com um cálculo do jeito que eu quero
@ jbsmith969 Concordo que componentes de baixo nível não devem ter nenhuma lógica de layout. No entanto, criar um componente mais abstrato para a especificidade do seu aplicativo não parece loucura.
IMHO, esse é um dos padrões mais poderosos que o React permite (graças às propriedades de isolamento).
@oliviertassinari @ jbsmith969 Foi exatamente o que fizemos! Criamos nosso componente CustomTextField
que eu passo como 2 parâmetros para (nome do campo e cor), e ele faz um pouco de lógica em torno deles, em seguida, renderiza material-ui/TextField
com o que quer que nós quer.
São todos os componentes para baixo!
Então, com o react, estamos pegando nosso html e colocando-o em nosso js e isso é ótimo. Mas pegar nosso css e colocá-lo em nosso html? Isso não se coaduna com mais ninguém?
Qual foi a vantagem de mudar de atitude?
Pode me chamar de antiquado, mas o que há de tão errado em manter js / html e css separados?
Estou legitimamente procurando por algumas respostas aqui ...
Relacionado a https://github.com/callemall/material-ui/issues/3614#issuecomment -249095805, o estilo simplesmente se torna um componente.
Vejo as classes CSS como novos componentes: (por exemplo, btn-danger
-como do boostrap)
const DangerButton = ({ hoverColor, style, ...others }) => {
return (
<MUI.FlatButton
hoverColor={hoverColor || Colors.pink100}
style={{ color: Colors.black, ...style }}
{...others}
/>
);
};
As transições são uma dor embora ..
(para @ jbsmith969 , o MUI segue as especificações do Material Design. Se eu não quisesse seguir as especificações, esperaria fazer alguma solução alternativa. No entanto, concordo que o MUI é difícil de modificar, mas é principalmente por causa da inconsistência estranha adereços de componentes, não porque seus estilos sejam embutidos)
@vizath certo, definitivamente tenho o mesmo pensamento. Mas quais são as vantagens desta solução?
Se houvesse uma solução que funcionasse pelo menos tão bem quanto o CSS, eu consideraria tentar. No entanto, como não há atualmente uma solução (que eu saiba) que pode fazer isso sem ressalvas, eu realmente não vejo o apelo.
Por que este repo está tentando adotar o que parece ser uma ideia de estágio alfa para uma solução em uma base de código muito útil? Só não acho que estamos lá com o tec ainda, nem acho que este seja o ambiente de teste adequado para esse tec.
@nathanmarks você pode aconselhar sobre como sobrescrever estilos de componentes usando JSS? Estou usando o código mais recente em next
EDIT: Ok, apenas descobri que ainda não está totalmente implementado. Foi mal! 😬
Eu ainda não encontrei uma boa maneira de eliminar o código morto em chaves de objeto, e com JSS torna obrigatório o uso de objetos para armazenar estilos.
Exemplo aleatório em um componente do branch next
(que não foi concluído): https://github.com/callemall/material-ui/blob/b372f6223ec2528dbe02f100e4802334f88445b7/src/IconButton/IconButton.js#L36
Não consigo encontrar uma maneira confiável de descobrir que as classes primary
e accent
não são usadas.
Também não gostei da maneira como o MUI gerenciava estilos embutidos antes, pelo mesmo motivo (o lint teria capturado variáveis não utilizadas se os estilos fossem definidos separadamente, consulte https://github.com/callemall/material-ui/blob/ 60a202fdc9645aa00f20c52e5152f168a1b0031b / src / IconButton / IconButton.js # L26).
Qual foi a vantagem de mudar de atitude?
@gdaunton Depende de qual lado você é quanto a não usar a abordagem inline-style / sass.
Do ponto de vista do usuário , fornecerá a seguinte melhoria:
Do ponto de vista do contribuidor / mantenedor , ele fornecerá as seguintes melhorias:
Por que este repo está tentando adotar o que parece ser uma ideia de estágio alfa
Depende do que você entende por ideia de estágio alfa.
Estamos longe de ser os únicos a usar essa abordagem. Por exemplo, AirBnB, Khan Academy, ReactNative.
funcionou pelo menos tão bem quanto o CSS
CSS foi projetado desde o início para estilizar documentos , não componentes .
Essa é uma grande mudança em nosso setor.
Do meu ponto de vista, é péssimo para estilizar componentes.
As pessoas por trás das especificações da Web estão bem cientes desse problema e estão tentando resolvê-lo com o estilo de escopo local de _Componentes da Web_.
Você notou todos esses novos projetos desde que o React foi lançado para melhorar CSS e escrever estilo baseado em componentes?
Sim, o próximo ramo está usando jss
@nathanmarks onde posso obter informações atualizadas sobre essa mudança?
Encontrei: https://github.com/callemall/material-ui/blob/next/docs/customization/themes.md
@bramick parece não ser sobre next
porque está funcionando a partir de 0.15.0
Ok, estou perdendo o que há de novo ... Alguém?
@bramick next
ainda não está totalmente documentado (no entanto, tem um site de documentação). Por enquanto, você terá que ler o código-fonte e pode consultar o código-fonte do site de documentação para ver como funciona. Apenas perceba que parte dele ainda pode ser um alvo em movimento.
@oliviertassinari Uau! Obrigado pela resposta detalhada.
Não posso dizer que concordo inteiramente, mas você desafiadoramente esclareceu algumas perguntas que eu tinha.
Eu concordo, devemos (e estamos) nos movendo em direção a um mundo onde nossos estilos são baseados em componentes, e css não é bom para isso. No entanto, (na minha opinião) ainda existem algumas rugas a resolver antes de adotarmos isso em escala.
Estou curioso, porém, alguém olhou para ver se há uma diferença de desempenho entre este css padrão? Eu sinto que o CSS ainda pode ter uma vantagem sobre o javascript; após carregá-lo ainda precisa gerar e injetar seus estilos.
@gdaunton leia sobre o desempenho do jss em https://github.com/cssinjs/jss/blob/master/docs/performance.md
É css padrão conforme renderizado, adicionado à página, mas criado dentro do componente. Estou usando o branch next
e está funcionando muito bem.
@newoga, você pode me enviar um link do que está se referindo?
@bramick OMG! É muito simples, não é? Por exemplo, para Botão em next
veja aqui .
Eu entendo o apelo de colocar CSS dentro do arquivo JavaScript, após o sucesso do JSX, mas não tenho certeza se é uma boa ideia fazer o mesmo com todo o CSS de um aplicativo. Eu sei que JSS tem alguns bons casos de uso, por exemplo, ao lidar com estilos dinâmicos supercomplexos.
Minha maior preocupação é que as informações de estilo acabem atrapalhando a definição do componente . O CSS expresso com objetos JavaScript é muito mais detalhado e mais difícil de organizar . Por exemplo, no componente Button
referenciado no post anterior, quase metade do código é informação de estilo. Não há mais separação de preocupações . Eu sei que você pode mover o código de estilo para um arquivo separado, mas então não faz sentido tê-lo em JavaScript em primeiro lugar.
Para os desenvolvedores, a maior desvantagem é que eles perdem todas as informações do intelli sense para as propriedades CSS e seus valores. Na verdade, eu gosto de toda aquela boa estrutura de código e expressividade que um pré-processador CSS pode oferecer, se usado corretamente.
Não me importo de adicionar complexidade aos meus projetos, se isso agregar mais valor. Portanto, nunca me importei com o linter CSS, o pré-processador, o carregador e a sintaxe extra que tive de aprender. Também estou tentando me manter aberto sobre o JSS, só que depois da primeira olhada ele não me convenceu.
Minha maior preocupação é que as informações de estilo acabem atrapalhando a definição do componente.
Isso é inteiramente com você, depende de como você organiza seu código, se você seguir algumas regras, nada de ruim acontece (falando com experiência em produção de 2 anos).
O CSS expresso com objetos JavaScript é muito mais detalhado e mais difícil de organizar.
Na verdade, é menos prolixo porque você tem um nível mais alto de reutilização de código e menos repetições.
Para os desenvolvedores, a maior desvantagem é que eles perdem todas as informações do intelli sense para as propriedades CSS e seus valores.
Acho que o objetivo aqui é dar aos usuários do material-ui a escolha de usar o que quiserem para estilizar. Autocompletes para CSS é um argumento que ouço com frequência. Geralmente vem de pessoas que não usavam muito cssinjs e é apenas medo de perder algumas das conveniências que costumavam usar.
Não me importo de adicionar complexidade aos meus projetos, se isso agregar mais valor.
Acho que a questão toda é reduzir a complexidade e tornar a base de código mais consistente e fácil de usar e entender, mas todos os cenários complexos são cobertos ao mesmo tempo.
Minha maior preocupação é que as informações de estilo acabem atrapalhando a definição do componente.
Em nosso projeto, extraímos as informações de estilo dos componentes em arquivos separados e os carregamos com o webpack. O principal benefício é que tudo está bem organizado e que o webpack pode agrupar o código por componente, de modo que a divisão do código js E as informações de estilo são possíveis.
Também é dada separação de interesses, quando você separa a lógica para produzir suas regras de estilo. Um exemplo é que introduzimos funções de fábrica de estilos que produzem stlying como mixins em pré-processadores CSS bem conhecidos.
Meu ponto é que você ganha muito mais flexibilidade para modelar seus próprios fluxos de trabalho específicos e se adaptar melhor às necessidades do projeto e da equipe.
verifique este https://styled-components.com/
É muito tarde para mudar as tecnologias, mas concordo que os componentes estilizados são muito promissores. Lida com SSR, consultas de mídia, sintaxe muito boa e assim por diante. Comparado ao JSS, ele também lida com autoprefixing e temas.
Pelo que eu sei, ele usa postcss dentro, o que não vai dar um desempenho aceitável quando usado em tempo de execução, porque é um analisador css completo com muitos casos de controle e plug-ins. Eu poderia imaginar um pré-processamento para JSS JSON, mas para ser honesto, não vejo muito valor em usar a linguagem CSS e misturá-la com variáveis JS e chamadas de função vs. apenas usar JS até o fim.
Só para mencionar, a construção atual de componentes estilizados é 250kb, já reduzido . Para ser justo, é porque eles agrupam React e co, mas ainda assim, mesmo o analisador PostCSS sozinho tem 13kb (não reduzido, pode ser 2kb ~) que já é quase do tamanho de JSS ou Fela.
É ótimo para prototipagem rápida e simples de componentes (de apresentação), mas não vejo nenhum benefício / recurso que outras soluções não possam oferecer.
Concordo, experimentei em uma biblioteca que desenvolvo e era muito pesado para publicar. Tenho certeza de que farão progresso com isso, mas parece que o trabalho do JSS aqui está quase concluído e oferece a maioria dos mesmos benefícios.
Eu usei o react-toolbox recentemente, eles usam módulos CSS para temas que basicamente dependem apenas do sassLoader
do webpack. Para mim funcionou muito bem. Talvez valha a pena investigar.
Ei, eu tenho que apoiar a opinião de suporte a temas react -toolbox é simplesmente incrível - estou mudando, pois personalizar a aparência dos componentes é o aspecto mais importante da história do frontend.
Eu não acho que ninguém deveria esperar que o bom e velho estilo de CSS seja um cidadão de primeira classe na IU de materiais, essa é a razão pela qual react-toolbox
foi iniciado
Pelo menos essa é minha impressão depois de ler muitos problemas e postagens sobre este assunto. Posso me lembrar vagamente de coisas como a equipe se esforça para melhorar a compatibilidade do React Native e muitos comentários sobre casos extremos de estilo que são muito mais fáceis de resolver com JSS.
No entanto, essa informação se perde entre muitas discussões. Por ser um tópico tão polêmico, acho que seria de um valor incrível se alguém pudesse ter uma página Wiki sobre os objetivos e filosofia do projeto (escrita pelos principais mantenedores) com uma forte observação sobre por que o estilo Javascript está tão arraigado no estrutura.
Eu realmente gosto de Material UI porque é a estrutura de estilo de material mais ativa e polida para React. No entanto, o JSS completo me causa muitas dores de cabeça quando quero manter um estilo unificado com componentes de terceiros.
Para mim, aprecio a forma como o Material-UI faz o estilo, em oposição a algo como react-toolbox, e aqui está o porquê: Em um de nossos projetos, temos a capacidade de o usuário selecionar temas dinâmicos:
Como o usuário pode selecionar um par de cores que não podemos determinar com antecedência, qualquer esquema de tema que usarmos deve ser altamente dinâmico. Com
Em react-toolbox et. al., isso parece ser mais uma tarefa, pelo que posso ver.
@jrop sim, neste caso muito especial você precisa de JSS dinâmico, mas para muitos aplicativos isso não é um requisito importante e a história atual de customização (nem mesmo falando sobre testes de IU) material-ui simplesmente não é aceitável. Estamos construindo um aplicativo altamente visual e projetado que não pode apenas usar a aparência material-ui padrão, já que mais precisamos / queremos as partes de comportamento dele.
@DominikGuzei você pode personalizar next
branch usando jss. Isso _não_ é o que você vê na versão atual.
Gente, sinto que estamos batendo em um cavalo morto aqui. O ramo next
escolheu um caminho diferente (muito melhorado) com os temas e permite substituições. Ele não está mais usando estilos embutidos e fornece a flexibilidade que vi solicitada. Para outros que desejam mais personalização, eles podem usar um HOC sobre os componentes next
e escrever suas próprias folhas de estilo.
@nathanmarks , uma vez que esta decisão foi tomada (pelo que posso dizer, e funciona muito bem 👍), sugiro que escreva um resumo e feche / bloqueie este problema para que aqueles que o encontrarem compreendam o caminho a seguir.
se alguém pudesse ter uma página Wiki sobre os objetivos e filosofia do projeto (escrita pelos principais mantenedores) com uma forte observação sobre por que o estilo Javascript está tão arraigado no framework.
@fgarcia Eu fiz uma apresentação em um evento local em Paris no início desta semana sobre a evolução da abordagem de estilo usada pelo Material-UI. Você pode se interessar por dar uma olhada nos slides e nas _notas_: Uma jornada para um estilo melhor . Concentro-me nos desafios, problemas e soluções.
o usuário seleciona temas dinâmicos
O aspecto de geração de estilo estático dos Módulos CSS tem algumas consequências.
O estilo de injeção em tempo de execução é menos econômico, mas nos permite:
CircularProgress
tem um thickness
fixo vinculado a como a animação do quadro-chave CSS é implementada. Com o estilo dinâmico, podemos adicionar uma propriedade de espessura para que os usuários possam alterar o valor dinamicamente. ⚠️ não ser abusado.@oliviertassinari Isso é incrível de ouvir. Posso ter um ponto de vista fora do padrão em relação aos módulos CSS, mas não acho que valem todo o alarido. Fiquei animado em ouvir falar de JSS por meio do material-ui por esse motivo. Parece muito mais alinhado com a filosofia do JavaScript do que módulos CSS.
@oliviertassinari obrigado pelo resumo dos benefícios. É definitivamente interessante quando você olha para esses aspectos. A desvantagem de JSS e seu ecossistema (também postcss) no momento é que tudo isso é de ponta e você não pode confiar na cadeia de ferramentas e base de conhecimento bem estabelecidas como com módulos css + SASS simples. Mas esse é o preço que você paga pela inovação, só depende se você tem certos requisitos / está disposto a pagar o preço dos bugs e do caminho menos documentado.
JSS foi criado antes de css-modules. Os módulos CSS tornaram-se populares mais rapidamente porque resolviam um problema para a maioria dos usuários sem alterar a sintaxe muito radicalmente.
Dito isso, você está usando o react, que também é uma tecnologia meio "nova". Se você quiser SASS, talvez você deva escolher vanilajs ou backbonejs)
@kof React é uma história muito diferente, pois é usado por centenas de milhares de desenvolvedores e é gerenciado pelo Facebook (não vai embora durante a noite), então pode ser "novo", mas muito sólido (não esbarrei em muitos problemas com ele até agora).
SASS é um dos pré-processadores css mais estabelecidos e pode ser usado em qualquer projeto - é muito sólido e traz muito valor para a mesa. Então eu só escolheria algo como JSS se absolutamente necessário (por exemplo: por causa de temas dinâmicos), mas não gosto de jogar fora anos de experiência / frameworks / base de conhecimento etc. em um projeto de software comercial com vários desenvolvedores. Então, eu até consideraria construir apenas o aspecto do tema dinâmico no JSS e o resto com módulos sass / css.
Eu entendo essa forma de pensar, mas também a considero contraproducente e a culpo por retardar a inovação e a indústria.
Por que você simplesmente não suporta os dois? Estilos escritos em JavaScript E estilos escritos em módulos css? Se eu der uma olhada em https://github.com/callemall/material-ui/blob/next/src/Button/Button.js por exemplo, seria muito fácil usar nomes de classes passados por um prop ( https://github.com/javivelasco/react-css-themr) em vez de usar:
const classes = this.context.styleManager.render(styleSheet);
Não é?
Não parece que a discussão sobre o uso de JSS ou CSS está chegando ao fim (ainda?). Para mim, parece uma coisa meio a meio no momento.
Com relação ao SASS, o react-toolbox está atualmente migrando para longe dele em favor de uma solução postCSS completa , eu pessoalmente acho que o postCSS (com plugins sassLike) é uma escolha melhor, mais poderosa sem build deps.
O estilo em todos os JS, e em React em particular, obviamente ainda está em um rápido estado de evolução. Portanto, faça o que fizer, eu tentarei evitar ser opinativo - apenas se encaixa bem com um amplo conjunto de uso atual.
Considere apenas adicionar um prop * className sempre que houver um prop * style. Período.
Divulgação completa: sou uma usuária feliz de Afrodite.
Adicionar className
ainda exigirá !important
hacks porque os estilos inline (da propriedade style
) têm precedência.
@ligaz Claro, você está certo. Afrodite adiciona !important
a tudo por padrão, então talvez meu pensamento sobre um "amplo conjunto de uso" esteja muito distorcido.
@ligaz @estaub - next
já está codificado _without_ style
e permite que os usuários dos componentes substituam fornecendo className
(e vários nomes de classes para as várias partes de componentes complexos) .
A configuração do paradigma de estilo no branch next
pelos mantenedores está usando JSS. É um prazer usar e fácil de substituir individualmente ou por tema.
Este cavalo está morto. Vamos parar de bater. @oliviertassinari Eu sugiro que você feche e bloqueie este problema com uma declaração de direção em next
.
Olá @rosskevin - você pode me apontar alguns exemplos de como isso está funcionando a seguir?
No momento, estou procurando frameworks para um novo projeto, adoraria usar o Material UI, mas precisamos que as mudanças que você mencionou estão a seguir. Eu adicionei o próximo branch a um projeto de teste e adicionei um componente simples e estou vendo um inspetor cheio de estilos embutidos, então acho que estou fazendo algo errado.
Quaisquer detalhes adicionais seriam realmente úteis!
obrigado
@giuseppepaul next
não foi publicado no npm porque é pré-alfa e ainda não está completo. Você pode clonar https://github.com/callemall/material-ui.git#next e executar docs/site
para ver se não há mais estilos embutidos. Ele também tem uma quantidade razoável de demos.
Estou publicando minha própria versão privada do next (para que eu possa controlar as atualizações) e estou usando isso em um aplicativo que em breve será produzido.
Este cavalo está morto. Vamos parar de bater. @oliviertassinari Eu sugiro que você feche e bloqueie este problema com uma declaração de direção a seguir.
Esse cavalo não está totalmente morto. Mas definitivamente em uma situação difícil 🔫.
Eu concordo, vamos encerrar este assunto.
Um grande obrigado a @nathanmarks pelo seu trabalho árduo nessa história 👏!
Reuni mais informações sobre a estrada à frente com # 5718.
Olá,
IconButton
tem uma propriedade CSS3 transition
para efeito cascata. Na complexa interação do documento do Card @next , você adicionou transition
à transformação para adicionar uma transição quando o ícone inverter.
Se eu fizer o mesmo em meu aplicativo, uma transição (ondulação ou reversão) substitui a outra (um elemento não pode ter duas propriedades, caso contrário, uma substitui a outra).
No entanto, seu ícone em forma de divisa teve dois transitions
aplicados a ele. Porque de alguma forma você mescla as transições fornecidas por IconButton
e aquela definida em seu código. Como você consegue isso?
Alguns outros materiais são obscuros para mim e não consigo encontrar documentos relacionados. theme
tem muitos métodos / propriedades como breakpoints
(não usado aqui) transitions
(usado aqui). Já existe um documento sobre a propriedade theme
do que MuiThemeProvider.createDefaultContext()
retorna como parece útil, especialmente porque é usado extensivamente dentro do seu código.
this.context.styleManager.render(styleSheet)
? O que ?
Você também usa jss-theme-reactor
que ainda não entendi, comparado com react-jss
.
@NitroBAY Este tópico acabou. Faça suas perguntas no canal certo. Se você notar um bug ou quiser que a documentação seja melhorada, abra um problema. Caso contrário, você pode usar StackOverflow de gitter.im.
Comentários muito úteis
A solução de estilo está finalizada?