Feliz: Adicione sobrecargas de string às propriedades CSS para valores personalizados brutos

Desculpe, estou perdida. Os adereços CSS básicos não têm nada a ver com o MUI. Feliz está certo em modelá-los de acordo com as especificações CSS. Quando você diz que o MUI usa uma série de strings, o que você quer dizer? AFAIK CSS não tem conceito de array. Você poderia misturar adereços CSS com adereços de componentes?

Bem, é apenas uma matriz de strings que estou acessando por índice, como no trecho acima. Sim, concordo que Feliz não deveria levar especificamente em consideração uma biblioteca. Minha pergunta era se as coisas deveriam retroceder para permitir a entrada de string para esses adereços.

Oh, certo. Você está se referindo a isto :

Sim, talvez o boxShadow Feliz deva ser afrouxado?

A propósito, veja esta página . Não tenho ideia do que eles querem dizer com isso, mas talvez haja outra maneira de usar a matriz shadows do tema no MUI, especificando o índice em uma propriedade boxShadow (não estilo)?

Infelizmente, não parece que o fade suporta esse suporte, que é para isso que estou usando essa propriedade em particular.

Eu não vi esse adereço para nenhum componente, e também não vi o componente Box que eles usam na página vinculada, e é por isso que estou confuso. Só por causa disso, você pode tentar definir um prop "boxShadow" ou "box-shadow" em qualquer componente e ver o que funciona.

Em qualquer caso, a página de documentos "sombra" realmente deveria ser melhorada.

Sim, talvez a caixa do FelizSombra deva ser afrouxada?

Idealmente, não deveria, porque é para isso que serve style.custom . Como esta é a reação de que estamos falando, acho que deveria ser boxShadow . Porém, novamente, uma sobrecarga de string não deve ser prejudicial. eu vou pensar sobre isso

Ter uma sobrecarga de string de base para tudo permite que as pessoas façam o mesmo que style.custom sem ter que procurar / lembrar qual é o nome css real. Uma opção seria ter algo como style.boxShadow.custom para que eles ainda saibam que estão errando os casos de uso típicos para aquele estilo.

Ter uma sobrecarga de string de base para tudo permite que as pessoas façam o mesmo que style.custom sem ter que procurar / lembrar qual é o nome css real.

Hm, não é uma má ideia, na verdade. Quer dizer, nós definitivamente queremos encorajar a segurança de digitação. Mas em CSS tudo é uma string de qualquer maneira, e seria bom ter uma saída de emergência às vezes para coisas "rápidas e sujas" ou, como @Shmew diz, se algo não for suportado no momento.

Não estou convencido de que seja uma boa ideia ter sobrecargas de string para todos os atributos de estilos, mas é algo a se considerar, pelo menos.

Que tal todos os nomes de estilo conhecidos anexados a style.custom para evitar ter que sobrecarregar estilos individuais.

style.custom.boxShadow "3px 3px red, -1em 0 0.4em olive"
style.custom.transition "margin-right 4s ease-in-out 1s"
style.custom("-webkit-text-stroke", "4px navy") // keep original custom fallback too

Não estou convencido de que seja uma boa ideia ter sobrecargas de string para todos os atributos de estilos, mas é algo a se considerar, pelo menos.

@cmeeren Usar qualquer biblioteca externa que possa fornecer dados para um estilo será um incômodo quando eles se destinam a ser fornecidos diretamente para o estilo. Temos que extrair os dados ou sempre usar style.custom ("..", someLibraryThing)

Que tal todos os nomes de estilo conhecidos anexados a style.custom para evitar sobrecarregar estilos individuais.

@zanaptak Eu gosto dessa ideia também, não tenho certeza se é melhor ou pior do que o que sugeri para descoberta.

Usar qualquer biblioteca externa que possa fornecer dados para um estilo vai ser um incômodo quando se destina a ser fornecido diretamente para o estilo

Verdade.

Acho que a solução mais simples é simplesmente ter uma sobrecarga de string para todos os adereços de estilo. O parâmetro string pode ser chamado de rawValue ou similar para deixar claro que você está sozinho.

Acho que a solução mais simples é simplesmente ter uma sobrecarga de cordas para todos os adereços de estilo. O parâmetro string pode ser chamado rawValue ou similar para deixar claro que você está sozinho.

@cmeeren Acho que este é bom e é uma extensão natural das sobrecargas fornecidas, mas me preocupo que se usarmos apenas style.boxShadow(rawValue: string) , haverá muitos abusos em vez de escrever o código da maneira segura de tipo recomendada. Também gosto da abordagem fornecida por @zanaptak porque desencoraja o uso de valores brutos para CSS, a menos que você saiba o que está fazendo e não haja uma maneira segura de escrever CSS. Mas, novamente, no caso de uso acima, ao interagir com um CSS externo, usar um valor personalizado não deve parecer um hack ou uma solução alternativa, então style.boxShadow(rawValue: string) e eu imagino que mais pessoas gostariam desse nível de facilidade ao escrever o valores personalizados.

Ambas as abordagens são boas e têm boas razões. Pessoalmente, estou mais inclinado para a abordagem anterior de style.boxShadow(rawValue: string) .

Desculpe, não pude discutir / consertar muitos problemas em torno de Feliz / Feliz.Mui esta semana por causa do trabalho, tento voltar a esses problemas o mais rápido possível e pegar este também (a menos que alguém queira levá-lo, seria incrível)

será muito abusado em vez de escrever o código da maneira de segurança de tipo recomendada

Feliz existe para a felicidade do desenvolvedor. Se os desenvolvedores estão mais felizes com o abuso do que com as sobrecargas de segurança de tipo - não que eu necessariamente ache que sejam - devemos realmente impedi-los?

Em qualquer caso, parece que estamos todos mais ou menos de acordo com uma sobrecarga de rawValue: string para todos os adereços de estilo. :)

Feliz existe para a felicidade do desenvolvedor. Se os desenvolvedores estão mais felizes com o abuso do que com as sobrecargas de segurança de tipo - não que eu necessariamente ache que sejam - devemos realmente impedi-los?

Eu concordo, realmente não é um problema, mas eu quero ter o cuidado de adicionar muitas coisas que permitem que você dê um tiro no próprio pé. Nesse contexto, definitivamente não é o caso.

Quero ter o cuidado de adicionar muitas coisas que permitem que você dê um tiro no próprio pé.

Absolutamente com você nisso 👍