Material-ui: [Core] Deve haver uma solução de estilo mais sofisticada.

Criado em 22 abr. 2016  ·  100Comentários  ·  Fonte: mui-org/material-ui

@ 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):

  1. Está alinhado com nossos objetivos? (tocado levemente acima)
  2. Implementar consultas de mídia que seguem os pontos de interrupção de alto nível detalhados na especificação que podem ser facilmente usados ​​em componentes com um mixin de folha de estilo (ou o que quer que a implementação que usamos os chame). Se estivermos revisando a implementação do estilo, é o momento oportuno para plantar a semente para um suporte de interface do usuário muito melhor nesta biblioteca. Seria ainda melhor se essas ferramentas também estivessem disponíveis na área do usuário 👍
  3. Devemos criar componentes auxiliares de layout e / ou mixins para ajudar a unificar as implementações de layout do flexbox na biblioteca?
  4. Os temas precisam mudar para maximizar o melhor uso da nova solução? Embora os temas sejam um componente de um estilo consistente, também devemos olhar para a criação de variáveis ​​para muitos dos estilos de materiais comuns, como linhas-chave / tamanhos de fonte / espaçamento / margens / etc. Eu recomendo fortemente que melhoremos nossa consistência tipográfica criando estilos de tipo predefinidos que correspondam ao guia de tipografia material-ui, e tentemos combinar elementos componentes como títulos etc da melhor forma possível com essas variáveis ​​de estilo de tipo global como padrão.
  5. Se estiver usando uma biblioteca tão grande quanto react-look , tente e veja como podemos importar módulos para um tamanho mínimo de compilação. Seria ótimo se pudéssemos minimizar o impacto no tamanho da construção. Percebi que 9kb disso é https://github.com/rofrischmann/inline-style-prefixer que já usamos ... 😄
discussion performance umbrella

Comentários muito úteis

A solução de estilo está finalizada?

Todos 100 comentários

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:

  • Alguns estilos vêm dos padrões do componente (que são definidos na pasta do nó e não são tocáveis)
  • Alguns vêm de parâmetros de componente (por exemplo, parâmetro de componente Avatar size={40} define largura, altura e altura da linha para 40px )
  • Quando os padrões do componente são customizados (as cores do tema), os estilos vêm do local de customização do tema
  • Quando o resto dos estilos de componente são modificados, os estilos vêm de uma implementação de componente, que é outra parte do código

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 .
image

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!

Melhor abordagem de comportamento de dois mundos?

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.

  1. Onde colocar os estilos estáticos (fácil, um arquivo css pode fazer)
  2. Como mudar alguns estilos dependendo da entrada (switch className)
  3. Como aplicar estilos dinâmicos (estilos embutidos podem fazer 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:

  1. Como permitir que os usuários personalizem os estilos estáticos?
  2. Como implementar o tema de uma forma que seja fácil de alternar, personalizar e isolar (subárvore diferente tema diferente)?
  3. Como evitar poluir o namespace global para que possamos jogar bem com os outros?
  4. Como os usuários podem substituir os estilos dinâmicos embutidos?
  5. transformadores! (rtl, prefixer, etc)

O que temos agora de alguma forma lida com todas essas preocupações com estas advertências:

  1. Atuação!
  2. Componentes profundamente aninhados são difíceis de personalizar, como @nathanmarks disse: somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
  3. Não podemos utilizar o poder de alguns recursos do CSS.

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.

  1. memoize o objeto de estilos, para componentes que têm estado, podemos dividir o estado e colocá-lo em um componente menor para que o objeto de estilo nele possa ser memoizado com base nos adereços passados ​​que são o estado do componente superior. Isso é facilmente resolvido!
  2. quebre-os! por que temos um 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
  3. meh! tudo o que conseguimos com o desempenho é :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:

  1. atuação
  2. Experiência do desenvolvedor (bibliotecas de estilo JS ajudam muito aqui, permitindo que os desenvolvedores usem classes em seus aplicativos com facilidade)

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:

  • Use o padrão getStyles todos os lugares para que possamos migrar mais facilmente mais tarde.
    Seremos capazes de usar um codemod? Quem sabe.
  • Dividindo cada componente conforme proposto por @alitaheri.

@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:

  • Como você acredita que a convenção de nomenclatura de nomes de classe pode ser semelhante?
  • Todos os nomes de classe terão um "mui-" ou outro prefixo?
  • A classe será uma notação de traço do nome do componente?
  • Um nome de classe será aplicado ao elemento raiz de cada componente?

@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:

  • Método de renderização de reação mais rápida, já que vamos contar com folhas CSS geradas em cache.
  • Substituição de estilo simplificada, já que a precedência CSS é menor do que a do estilo embutido e os usuários podem usar as DevTools para identificar a planilha a ser alterada.
  • Primeira pintura mais rápida ao fazer a renderização do lado do servidor.

    • Os usuários serão capazes de embutir as folhas CSS críticas, e apenas a usada na página. Isso é algo que você NÃO PODE fazer com o _Bootstrap_, pois é um grande monólito 🙈.

    • Os usuários devem ser capazes de modificar as chaves dos nomes das classes na produção.

  • Sem dependência de cadeia interna como _scss-loader_ ou _Webpack_.

Do ponto de vista do contribuidor / mantenedor , ele fornecerá as seguintes melhorias:

  • Chega de CSS linter
  • Chega de CSS pré-processador
  • Sem sintaxe CSS para aprender
  • Uma linguagem muito mais poderosa para estilizar o componente: JavaScript
  • Abra a possibilidade de abstrair o mecanismo de estilo. Por exemplo, usando reagir com estilos

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.

É 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:

Imgur

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, as mudanças no tema podem acontecer ao vivo, b / c todos os estilos são gerados inline: tudo o que tenho a fazer é fornecer cores primárias / de destaque.

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:

  • Nos dá mais flexibilidade com a implementação do estilo. Por exemplo, 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.
  • Em aplicativos de grande escala, permite injetar apenas os estilos necessários para o componente exibido na tela. Reduzindo a quantidade de trabalho necessária para o navegador inicializar a página. Conseqüentemente, tempo mais rápido para pintar pela primeira vez após a interação. Por exemplo, CSS crítico embutido com SSR.
  • Permitir que os usuários usem tema dinâmico e variação de componentes. Por exemplo, mudar a cor de um botão com todas as variações de cores necessárias.

@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.

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

Questões relacionadas

mb-copart picture mb-copart  ·  3Comentários

rbozan picture rbozan  ·  3Comentários

anthony-dandrea picture anthony-dandrea  ·  3Comentários

iamzhouyi picture iamzhouyi  ·  3Comentários

ericraffin picture ericraffin  ·  3Comentários