Feliz: Ajouter des surcharges de chaîne aux propriétés CSS pour les valeurs personnalisées brutes

Désolé, je suis perdu. Les accessoires CSS de base n'ont rien à voir avec MUI. Feliz a raison de les modéliser selon la spécification CSS. Quand vous dites que MUI utilise un tableau de chaînes, que voulez-vous dire ? AFAIK CSS n'a pas de concept de tableau. Pourriez-vous mélanger des accessoires CSS avec des accessoires de composants ?

Eh bien, c'est juste un tableau de chaînes auquel j'accède par index comme dans l'extrait ci-dessus. Ouais je suis d'accord que Feliz ne devrait pas spécifiquement prendre en compte une bibliothèque. Ma question était de savoir si les choses devaient se replier pour autoriser l'entrée de chaîne pour ces accessoires.

Ah, c'est vrai. Tu fais référence à ça :

Oui, peut-être que le boxShadow Feliz devrait être desserré ?

Au fait, voir cette page . Je n'ai aucune idée de ce qu'ils entendent par là, mais il existe peut-être une autre façon d'utiliser le tableau shadows du thème dans MUI, en spécifiant l'index dans une propriété boxShadow (pas de style) ?

Malheureusement, le fondu ne prend pas en charge cet accessoire, c'est pourquoi j'utilise cette propriété particulière.

Je n'ai vu cet accessoire pour aucun composant, et je n'ai pas non plus vu le composant Box qu'ils utilisent sur la page que j'ai liée, c'est pourquoi je suis confus. Juste pour le plaisir, vous pouvez essayer de définir un accessoire personnalisé "boxShadow" ou "box-shadow" sur n'importe quel composant et voir ce qui fonctionne.

Dans tous les cas, la page docs "shadow" devrait vraiment être améliorée.

Oui, peut-être faudrait-il desserrer la boxShadow de Feliz ?

Idéalement, cela ne devrait pas être nécessaire car c'est à cela que sert style.custom . Parce que c'est de réagir dont nous parlons, je pense que cela devrait être boxShadow . Encore une fois, une surcharge de string ne devrait pas être nuisible. j'y penserai

Avoir une surcharge de chaîne de base pour tout permet aux gens de faire la même chose que style.custom sans avoir à rechercher/se rappeler quel est le nom css réel. Une option serait d'avoir quelque chose comme style.boxShadow.custom afin qu'ils sachent toujours qu'ils s'éloignent des cas d'utilisation typiques de ce style.

Avoir une surcharge de chaîne de base pour tout permet aux gens de faire la même chose que style.custom sans avoir à rechercher/se rappeler quel est le nom css réel.

Hum, pas une mauvaise idée, en fait. Je veux dire, nous voulons vraiment encourager la sécurité de type. Mais en CSS, de toute façon, tout est une chaîne, et ce serait bien d'avoir une trappe d'évacuation parfois pour des trucs "rapides et sales", ou, comme le dit @Shmew , si quelque chose n'est pas actuellement pris en charge.

Je ne suis pas convaincu que ce soit une bonne idée d'avoir des surcharges de chaîne pour tous les attributs de style, mais c'est au moins quelque chose à considérer.

Que diriez-vous de tous les noms de styles connus attachés à style.custom pour éviter d'avoir à donner des surcharges aux styles individuels.

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

Je ne suis pas convaincu que ce soit une bonne idée d'avoir des surcharges de chaîne pour tous les attributs de style, mais c'est au moins quelque chose à considérer.

@cmeeren L' utilisation de n'importe quelle bibliothèque externe qui pourrait fournir des données à un style va être un problème lorsqu'elles sont destinées à être fournies directement au style. Nous devons soit extraire les données, soit toujours utiliser style.custom ("..", someLibraryThing)

Que diriez-vous de tous les noms de style connus attachés à style.custom pour éviter d'avoir à donner des surcharges aux styles individuels.

@zanaptak J'aime aussi cette idée, je ne sais pas si c'est mieux ou pire que ce que j'ai suggéré pour la découvrabilité.

L'utilisation de n'importe quelle bibliothèque externe qui pourrait fournir des données à un style va être un problème lorsqu'elles sont destinées à être fournies directement au style

Vrai.

Je pense que la solution la plus simple est d'avoir simplement une surcharge string pour tous les accessoires de style. Le paramètre de chaîne pourrait être appelé rawValue ou similaire pour indiquer clairement que vous êtes seul.

Je pense que la solution la plus simple est d'avoir simplement une surcharge de chaîne pour tous les accessoires de style. Le paramètre de chaîne peut être appelé rawValue ou similaire pour indiquer clairement que vous êtes seul.

@cmeeren Je pense que celui-ci est bon et qu'il s'agit d'une extension naturelle des surcharges fournies, mais je crains que si nous utilisons simplement style.boxShadow(rawValue: string) il sera beaucoup abusé au lieu d'écrire le code de la manière recommandée. J'aime aussi l'approche fournie par @zanaptak car elle décourage l'utilisation de valeurs brutes pour CSS à moins que vous ne sachiez ce que vous faites et qu'il n'existe aucun moyen sûr d'écrire le CSS. Mais encore une fois, dans le cas d'utilisation ci-dessus lors de l'interopérabilité avec un CSS externe, l'utilisation d'une valeur personnalisée ne devrait pas ressembler à un hack ou à une solution de contournement, donc style.boxShadow(rawValue: string) et j'imagine que plus de gens voudraient ce niveau de facilité lors de l'écriture du valeurs personnalisées.

Les deux approches sont bonnes et ont de bonnes raisons. Personnellement, je penche plus vers l'ancienne approche de style.boxShadow(rawValue: string) .

Désolé, je n'ai pas pu discuter / résoudre de nombreux problèmes autour de Feliz/Feliz.Mui cette semaine à cause du travail, j'essaie de revenir à ces problèmes dès que possible et de prendre celui-ci aussi (à moins que quelqu'un ne veuille le prendre, ce serait impressionnant)

il sera beaucoup abusé au lieu d'écrire le code de la manière recommandée

Feliz existe pour le bonheur des développeurs. Si les développeurs sont plus heureux d'en abuser que d'utiliser les surcharges de type sécurisé - pas que je pense nécessairement qu'ils le soient - devrions-nous vraiment les arrêter ?

Dans tous les cas, il semble que nous soyons tous plus ou moins d'accord sur une surcharge de rawValue: string pour tous les accessoires de style. :)

Feliz existe pour le bonheur des développeurs. Si les développeurs sont plus heureux d'en abuser que d'utiliser les surcharges de type sécurisé - pas que je pense nécessairement qu'ils le soient - devrions-nous vraiment les arrêter ?

Je suis d'accord, ce n'est pas vraiment un problème mais je veux faire attention à ajouter trop de choses qui vous permettent de vous tirer une balle dans le pied. Dans ce contexte, ce n'est certainement pas le cas.

Je veux faire attention à ajouter trop de choses qui vous permettent de vous tirer une balle dans le pied.

Absolument avec vous sur ce coup-là