Quelques questions supplémentaires:
6) Allons-nous supprimer ou viser à supprimer les accessoires xxxxStyle et demander aux utilisateurs de passer un xxxClassName pour remplacer les styles? Ou seront-ils gratuits?
7) Autoriserons-nous le remplacement des styles via CSS et simplifierons les interfaces de nos composants. Donc, si je veux remplacer menuItemStyle dans IconMenu, dois-je créer un remplacement de type style = StyleSheet.create({ IconMenu: {MenuItem: { color:red }}) ?

@chrismcv Mon opinion personnelle est que nous devons certainement tirer parti de la solution pour supprimer ces accessoires super spécifiques que nous voyons proposés: [TextField] add floatingLabelFocusStyle prop # 4043

Avant que nous le sachions, les gens vont demander des accessoires pour les styles de sous-composants pour chaque focus possible / actif / survol / quel que soit l'état.

Je vois tellement de problèmes qui sont "comment styliser XXXX", "impossible de styliser XXX dans YYYY", "ajouter somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle prop à XXX s'il vous plaît"

@chrismcv en 6. en ce qui concerne les accessoires plus généraux xxxxStyle vs classNames, qu'en pensez-vous? avec certains de nos composants, vous aurez besoin de pouvoir atteindre d'une manière ou d'une autre (heureusement, nous pourrons utiliser :hover etc cependant!).

@chrismcv Je pense que les accessoires xxxxStyle devraient aller dans la propriété style , pas dans l'objet de style className .

@nathanmarks Merci d'avoir amorcé la conversation. C'est certainement l'un des problèmes majeurs que nous devons résoudre pour les prochaines versions 💯.

En dehors des problèmes de performance

Pour moi, c'est l'une des principales préoccupations que j'ai avec la solution que nous choisirons.
Nous n'avons pas beaucoup de benchmarks, mais nous pouvons facilement imaginer que nous avons perdu de nombreux cycles CPU avec notre approche actuelle. Les cycles du processeur sont perdus dans les allocations de mémoire et le garbage collection pour notre objet de style en ligne.

@oliviertassinari

Je joue actuellement avec quelques solutions de style JS. C'est intéressant mais clair que c'est encore "les premiers jours" pour ainsi dire.

Une chose à laquelle je pensais - en dehors des propriétés de style dynamique (par exemple, si le composant a un accessoire color ), devrions-nous changer la façon dont nous créons l'objet de style de base?

Il semble qu'avec les bibliothèques de style JS, pour obtenir des performances maximales, vous devez utiliser leur méthode StyleSheet.create() une fois et avoir des clés (css "classes") dans cet objet pour les props / états tels que open={true} plutôt que de construire dynamiquement l'objet de style littéral avec quelques propriétés conditionnelles et de le transmettre à la méthode de fabrique de feuille de style à chaque rendu pour chaque style.

Même si les sélecteurs de feuille de style sont mis en cache dans le sens où ils ne sont écrits qu'une seule fois dans le DOM (et dans certaines bibliothèques uniquement écrites dans le DOM lorsque cela est nécessaire pour le render() ), nous gaspillons toujours des ressources avec certains calculs + création d'objet + garbage collection comme vous l'avez mentionné ci-dessus si nous créons un nouvel objet de style à chaque rendu juste pour le jeter.

Hmmm ... J'ai laissé un commentaire ici hier (dimanche). At-il été supprimé?

@rvbyron Je m'en souviens clairement. Je ne l'ai certainement pas supprimé.

@rvbyron Je m'en souviens aussi. Je n'ai aucune idée de ce qui s'est passé.

@rvbyron - l'avais dans mon e-mail, alors revenons ici sous forme citée!

Eh bien, pour ma part, j'aimerais voir un certain nombre de choses se produire.

A) Oui, supprimez certainement l'utilisation du paramètre de style de l'élément au niveau de la bibliothèque. Tous les composants doivent être définis à l'aide de className. Le fait que les composants utilisent le style détruit toutes les offres de puissance CSS.
B) Ce serait génial d'avoir classNames automatiquement attaché à l'élément racine de chaque composant (par exemple, le composant RaisedButton aurait implicitement className = "mui-raise-button" sur l'élément racine du composant). Cela rendrait le style beaucoup plus facile. Cela pourrait même être configurable.
C) Supprimez complètement le thème des fichiers muiTheme.js. Un fichier de thème muiTheme.SCSS serait bien meilleur en ce qu'il permettrait d'appliquer toutes les propriétés choisies par le créateur du thème et pas seulement celles spécifiquement autorisées par le composant. Bien sûr, cela nécessiterait probablement que B soit implémenté et actif.
D) React-look semble être un bon compromis car il convertit les objets JSON contenant des propriétés de style en classNames. Cela rend les choses plus faciles à contourner. Cependant, comme je l'ai dit en C ci-dessus, j'aimerais toujours que la base de thème soit créée dans SCSS. Je suis assez ouvert sur le package d'assistance CSS à utiliser. Mais je resterais à l'écart de tout ce qui voulait utiliser le paramètre de style de l'élément sur le paramètre className.

@chrismcv Merci mec!

Je pense que ce que @rvbyron a à dire est important car, à certains égards, le style JS est vraiment un changement de paradigme par rapport au CSS ordinaire. La plupart des gens n'utilisent pas le style JS dans leur travail quotidien et cela nécessite une façon de penser différente + rend la tâche plus difficile pour les concepteurs qui peuvent généralement contribuer à des projets qui ne maîtrisent pas si bien JS.

Il est important de considérer tous les angles ici.

@oliviertassinari @chrismcv

Une chose que j'ai réalisé à propos de react-look est que vous devez envelopper tous vos composants dans le look HoC . Cela semble assez invasif, il détourne même la fonction render() , stocke super.render() dans un const et effectue des opérations de résolution de style de cette façon. Certaines autres solutions telles que Khan / aphrodite nécessitent juste un wrapper de fonction autour de la référence styles.xxxx de Stylesheet.create() intérieur de className={} .

Le détournement de la fonction render() juste pour css me semble sur-conçu. Cela me dit que les outils / support intégrés de React pour ce type de fonctionnalité de styles profondément intégrés ne sont tout simplement pas là, je ne suis pas sûr de l'idée d'un assistant CSS HoC contrôlant le rendu de tous nos composants.

Pensées?

Salut l'équipe Material-UI!

Je vous suis depuis un moment et maintenant, en voyant ce sujet, je voulais également contribuer avec quelques réflexions sur les raisons pour lesquelles le passage des styles en ligne au CSS pourrait être une bonne idée. J'ai lu beaucoup de discussions dans ce référentiel qui couvrent les performances de rendu, le style des enfants / éléments imbriqués, les requêtes multimédias, les pseudo-éléments, etc., donc je vais me concentrer sur autre chose dont je n'ai pas encore discuté, mais qui je pense est également pertinent. Et c'est l'organisation des styles. Voici ce que je veux dire:

• Certains styles proviennent des valeurs par défaut du composant (qui sont définies dans le dossier du nœud et ne sont pas touchables)
• Certains proviennent de paramètres de composant (par exemple, le paramètre de composant Avatar size={40} définit la largeur, la hauteur et la hauteur de ligne sur 40px )
• Lorsque les paramètres par défaut du composant sont personnalisés (les couleurs du thème), les styles proviennent de l'emplacement de personnalisation du thème
• Lorsque le reste des styles de composant est modifié, les styles proviennent d'une implémentation de composant, qui est une autre partie du code

Quand il s'agit d'ajuster les styles, il y a au moins 4 emplacements différents (👆) à regarder, ce qui rend difficile l'étude des problèmes.

Lorsque les styles sont livrés avec css, vous voyez le sélecteur et savez exactement où corriger. Avec les styles en ligne, il faut du temps pour comprendre d'où vient la propriété particulière, où et ce qui doit être modifié. Et si le développeur le modifie au mauvais endroit (disons dans la zone styles au lieu du paramètre size , puisque rien ne dit réellement que size est le style), cela affectera le toute la performance du bloc width=height=line-height=40px , ou conduira à réécrire width/height/line-height ce qui rendra le paramètre size inapplicable.

En outre, il est également difficile de rechercher quels éléments parents ont des propriétés spécifiques appliquées, car tout ce que vous pouvez voir dans l'inspecteur est element.style .

Lorsque les styles sont livrés avec des sélecteurs (noms de classe), cela donne beaucoup plus de contrôle sur la structure des styles que les styles en ligne.

Mise à jour: j'ai oublié de mentionner la suggestion (sur laquelle porte ce sujet):

/component
--component.js
--component.css (or sass that is converted to css when the page is rendering)

Cette structure gardera le composant dans la portée, mais donnera plus de contrôle sur le style. Et une convention BEM className aidera à éviter une imbrication inutile:

.mui-component {}
.mui-component__child {}

Ce qui dans l'ensemble aidera à mettre en œuvre, ajuster et maintenir les styles Material-UI.

@chrismcv

Merci d'avoir trouvé l'e-mail et de l'avoir placé dans le commentaire!

La meilleure approche comportementale des deux mondes?

Qu'en est-il d'un concept de «comportement» d'importation de la technique de style qui correspond le mieux à vos besoins. Une importation de "StyleTheme" ou "ClassTheme" peut être utilisée pour sélectionner le comportement. StyleTheme pourrait faire référence à l'objet muiTheme dont dispose aujourd'hui material-ui et rendre les développeurs de styles centrés sur les composants heureux. Ou, ClassTheme qui utiliserait un fichier SCSS qui est construit à partir de l'objet muiTheme.js (synchronisé) rendant les développeurs centrés sur CSS heureux. Cela signifierait que tous les composants devraient alors intégrer {... theme.ComponentName} dans les éléments de rendu.

Pour offrir un exemple très simplifié, un composant RoundButton aurait la méthode de rendu comme:

render() {
    return (<button {...theme.RoundButton} />);
}

Pour le comportement StyleTheme, theme.RoundButton contiendrait:

{ 
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

Pour le comportement ClassTheme, theme.RoundButton contiendrait:

{ 
    className: 'mui-round-button'
}

Une combinaison des deux pourrait être récupérée en tant que comportement ClassStyleTheme, theme.RoundButton contiendrait les deux:

{ 
    className: 'mui-round-button',
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

Le fichier mui-theme.scss serait généré à partir du fichier muiTheme.js et refléterait dans SCSS les propriétés exactes du fichier JS. L'enveloppe de chameau des noms JS serait convertie en noms de classe plus standard:

mui-round-button {
    display: inline-block;
    border-radius: 20px;
    width: 40px;
    height: 40px;
}

Toute personnalisation CSS des composants MUI serait simplement des classes identiques chargées après le chargement du fichier mui-theme.scss, remplaçant ainsi les propriétés de mui-theme.

@oliviertassinari

Je pense que l'utilisation de quelque chose comme scss (+ modules css pour l'espacement de noms / hachage) présente de nombreux avantages. Est-ce quelque chose auquel vous vous opposez à 100%? Je suis probablement un peu biaisé car c'est ce que j'ai l'habitude d'utiliser au travail, mais beaucoup de gens sont dans le même bateau.

Mon principal problème avec la situation de style JS est que toutes les solutions sont toujours en cours de développement. Il n'y a pas beaucoup d'évaluations de performances dans le monde réel à examiner, les bibliothèques que nous examinons ne sont pas prouvées et j'ai l'impression que nous passons beaucoup de temps à essayer de comprendre comment faire correctement les styles dans JS. L'objectif principal de cette bibliothèque est d'implémenter les spécifications de conception matérielle et je ne peux pas m'empêcher de penser que cela nous gêne pour le moment. (nous devons absolument trier les problèmes d'impact sur les performances)

Je pense que nous avons des préoccupations différentes à ce sujet.

1. Où mettre les styles statiques (facile, un fichier css peut faire)
2. Comment changer certains styles en fonction de l'entrée (commutateur className)
3. Comment appliquer des styles dynamiques (les styles en ligne peuvent le faire)

Tout semble bon lorsque vous écrivez une application, personne en dehors de votre code n'a besoin de changer quoi que ce soit.

Mais avec les bibliothèques, les choses sont différentes, toutes les préoccupations ci-dessus sont présentes, plus les suivantes:

1. Comment permettre aux utilisateurs de personnaliser les styles statiques?
2. Comment implémenter le thème de manière à ce qu'il soit facile de basculer, de personnaliser et d'isoler (thème différent de sous-arbre différent)?
3. Comment éviter de polluer l'espace de noms global pour bien jouer avec les autres?
4. Comment les utilisateurs peuvent-ils remplacer les styles dynamiques intégrés?
5. transformateurs! (rtl, préfixeur, etc.)

Ce que nous avons en ce moment gère en quelque sorte toutes ces préoccupations avec ces mises en garde:

1. Performance!
2. Les composants profondément imbriqués sont difficiles à personnaliser, comme l' a dit somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
3. Nous ne pouvons pas utiliser la puissance de certaines fonctionnalités css.

Si nous changeons notre approche stylistique, nous devrons tout recommencer. Dans ce cas, nous devrions nous assurer de répondre à toutes ces questions avant de commencer la migration.

À mon humble avis, je pense que CSS et tout ce qui s'y compile ne font pas partie du futur. Je pense que nous sommes tous d'accord pour dire que les styles en ligne nous ont beaucoup facilité la vie. Honnêtement, la seule limitation que je vois avec les styles en ligne est :hover !

Nous pouvons résoudre ces problèmes en faisant un peu de conception.

1. mémoriser l'objet styles, pour les composants qui ont l'état, nous pouvons décomposer l'état et le mettre dans un composant plus petit afin que l'objet style qu'il contient puisse être mémorisé en fonction des accessoires passés qui sont l'état du composant supérieur. Ceci est facilement résoluble!
2. les briser! pourquoi avons-nous un ListItem avec BEAUCOUP de petites fonctionnalités intégrées? nous pouvons le décomposer et le rendre composable, alors nous n'avons pas à ajouter des monstruosités comme somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
3. meh! tout ce que nous obtenons des performances est de :hover Je pense que nous pouvons vivre avec cela jusqu'à ce que les navigateurs ou réagissent.

Ce que je veux dire, c'est que nous abordons déjà un grand nombre de préoccupations avec notre approche actuelle en matière de style. Il a des limites car nous ne suivons pas tous les modèles autour des styles en ligne. si nous commençons à décomposer nos composants et à les rendre beaucoup plus composables, nous n'avons pas vraiment à nous soucier de quoi que ce soit. take MeuItem J'ai pris cela et je l'ai rendu composable, vous voyez à quel point il est facile à utiliser et comment les performances peuvent être améliorées en utilisant le rendu pur!

Donc, au lieu de changer notre approche et de résoudre à nouveau tous ces problèmes, investissons du temps à améliorer ce que nous avons déjà. nous n'avons pas besoin de prendre en charge les requêtes multimédias, nous pouvons modifier nos composants d'une manière qui permet aux autres d'implémenter facilement une réactivité. Difficile à déboguer? si nous décomposons nos composants, les styles intégrés seront plus petits et plus faciles à lire. discutable cependant! Je veux dire, tout ce dont vous avez besoin est un point d'arrêt pour voir ce qui participe à Object.assign pour voir d'où viennent les styles.

C'est bien sûr ma propre opinion, je suis très ouvert à la discussion.

@alitaheri

Vous soulevez quelques points importants. Merci. Je me demande si une sorte de solution hybride est une possibilité. Il semble que peu importe l'angle que nous prenons, il y a un tas de problèmes 😆

J'ai le temps de travailler là-dessus la semaine prochaine - discutons et voyons si nous pouvons trouver une idée intelligente.

Je suis d'accord pour essayer de minimiser la quantité de changement et avoir à résoudre les problèmes déjà résolus. Il y a 2 objectifs importants ici dans mon esprit:

1. Performance
2. Expérience des développeurs (les bibliothèques de style JS aident beaucoup ici en permettant aux développeurs d'utiliser facilement des classes dans leurs applications)

Il faut y réfléchir davantage 😄 mais tant que nous parvenons à résoudre ces 2 points, je serai satisfait de notre solution.

Une autre note aléatoire - ce serait formidable si nous avions un moyen automatisé d'appliquer certaines conventions de code et certains modèles de conception pour inline / jsstyle / tout dans la bibliothèque.

Est-ce quelque chose auquel vous vous opposez à 100%?

@nathanmarks Je ne suis pas opposé à 100% à l'utilisation de SCSS (_Je l'utilise au travail_). Mais de mon point de vue, c'est une impasse .
L'un des principaux avantages de React est d'abstraire la spécificité de rendu des navigateurs: le DOM.
Autant que je sache, l'objectif à long terme de l'équipe React Core est de fournir une API pour écrire des composants multiplateformes. En fait, ils expérimentent actuellement dans cette direction. SCSS n'aidera pas.

Je suis entièrement d'accord avec @alitaheri. Nous pourrions commencer par ces deux étapes:

• Utilisez le modèle getStyles partout afin de pouvoir migrer plus facilement plus tard.
  Pourrons-nous utiliser un codemod? Qui sait.
• Décomposer chaque composant comme proposé par @alitaheri.

@oliviertassinari Je suis d'accord avec la conclusion sans issue - ce n'est pas l'avenir. Je l'ai évoqué en grande partie pour stimuler la conversation sur la façon de faire fonctionner les styles JS pour nous. Je savais que certaines personnes ici avaient de bonnes idées sur les problèmes 😄 J'aimerais que FB soit un peu plus loin avec leurs expériences!

Je pense en fait que le modèle getStyles() que nous utilisons actuellement a ses propres problèmes. @alitaheri et moi avons eu une très bonne discussion aujourd'hui sur ce qu'il faut faire pour améliorer notre configuration de style JS (y compris le thème!). Je répondrai demain avec plus d'informations une fois que j'aurai l'occasion de prendre quelques notes!

La semaine prochaine, je suis en vacances et je vais expérimenter une solution à nos problèmes actuels tout en gardant tous les styles basés sur JS.

Il suffit de lire cet article sur les leçons apprises à React Amsterdam (https://medium.com/@kitze/lessons-learned-at-react-amsterdam-51f2006c4a59#.o12h794or) et l'une des présentations portait sur les solutions de style dans React: http : //slides.com/kof/javascript-style-sheets#/ Une présentation opportune pour cette discussion.

Une exigence à laquelle je continue de réfléchir et que je n'ai pas vue explicitement énoncée (du moins que je me souviens) est la nécessité de prendre en charge le Web uniquement par rapport au Web et de réagir de manière native. Si l'intention est uniquement Web (c'est-à-dire que la réaction native n'est pas une exigence), des solutions qui tirent parti de ce que les navigateurs prennent déjà en charge de manière efficace et robuste et que les gens sont très familiers seraient une bonne chose. Si la prise en charge de react native est indispensable, cela ouvre un ensemble différent de besoins et d'exigences. Juste quelque chose à penser et à garder à l'esprit lors de l'évaluation des choix technologiques, des compromis, etc.

@hburrows

Merci d'avoir partagé cette présentation!

@alitaheri

Nous voudrons peut-être regarder la bibliothèque mentionnée dans cette présentation ( voici une démo ). Cela pourrait nous faire gagner beaucoup de travail. Je le regardais auparavant mais il y avait quelques choses que je n'aimais pas (comme l'exigence d'emballer chaque composant dans un HoC propriétaire). Cependant, il y a une discussion sur certains de ces événements ici . Il mentionne que la mise en œuvre de changements comme celui- ci permettrait une utilisation sans HoC. Je préfère cette méthode / conception pour l'écriture de la feuille (également vue dans aphrodite ).

Alternativement, nous pourrions toujours créer nos propres liaisons de réaction pour jss qui peuvent fonctionner avec mixout .

L'auteur de la lib a également dit ceci, ce qui correspond à mes propres réflexions sur la question 👍:

Cependant, vous devez comprendre que tout n'a pas de sens pour être des feuilles de style. Pour les modifications les plus dynamiques, vous devez utiliser des styles en ligne.

@nathanmarks L'implémentation est plutôt très petite et très facile à mélanger: grin:
https://github.com/jsstyles/react-jss/blob/master/src/index.js
Je pense que cette bibliothèque peut nous aider: +1:

@alitaheri Ouais je suis d'accord!

J'expérimente également des liaisons personnalisées pour jss - il y a quelques problèmes / limitations que je veux essayer de résoudre. (Un cependant peut nécessiter un travail sur la bibliothèque principale)

Il semble y avoir un sentiment dominant dans la communauté React selon lequel le style JavaScript est la meilleure solution. Ce sentiment est bon, je ne suis pas en désaccord avec ceux qui l'ont. Cependant, la façon dont le style JavaScript est implémenté est presque toujours indépendante du développeur CSS. L'implémentation favorise trop souvent style=/[element property]= sur className= et empêche le développeur CSS de faire son travail.

Comme je l'ai proposé dans un commentaire précédent, je pense que les deux pourraient bien vivre ensemble. Il faut simplement adopter une approche comportementale pour appliquer les propriétés de style. La bibliothèque doit prendre en charge l'application directe des propriétés de style à un élément, ou elle doit permettre l'approche indirecte de création d'un nom de classe comprenant ces propriétés de style. Une bibliothèque qui permet au développeur de choisir le comportement semble être une solution idéale.

Il y a de nombreuses raisons pour lesquelles les développeurs CSS ne veulent pas simplement abandonner leur approche. Recherchez «pourquoi utiliser le CSS» pour voir pourquoi les gens le trouvent avantageux. Vous trouverez parmi ses avantages l'abstraction des styles et un puissant langage de sélection. N'oublions pas l'énorme quantité de code qui existe aujourd'hui et qui profite aux utilisateurs CSS.

Encore une fois, ce n'est en aucun cas un commentaire pro CSS. Il y a ceux d'entre nous qui aimeraient utiliser CSS pour le style. Ce commentaire vise à encourager une approche de style neutre sur le plan architectural qui permet aux développeurs d'avoir le choix.

@rvbyron L'une des principales raisons pour lesquelles nous voulons changer notre approche actuelle est de faciliter la personnalisation des composants en utilisant également le CSS. l'utilisation d'une bibliothèque comme jss nous permettra d'utiliser les fonctionnalités css tout en profitant de js-styles. Et comme il transforme ces styles en css, ils peuvent être facilement remplacés par un nom de classe supplémentaire sans le truc affreux !important .

@alitaheri Super à entendre! J'ai vraiment hâte de voir material-ui intégrer une approche basée sur le nom de classe.

Encore une fois, fantastique à entendre sur l'approche className. Dans cet esprit, j'ai quelques questions sur la façon dont il pourrait être mis en œuvre:

• À votre avis, à quoi pourrait ressembler la convention de dénomination des noms de classe?
• Tous les noms de classes auront-ils un préfixe "mui-" ou autre?
• La classe sera-t-elle une notation tiretée du nom du composant?
• Un nom de classe sera-t-il appliqué à l'élément racine de chaque composant?

@rvbyron

Idéalement:

Préfixe personnalisable. Une sorte de notation Dash pour une meilleure expérience de développement et un suffixe haché qui peut également être défini sur une chaîne fixe (donc ne changera pas si les paramètres du thème sont modifiés) à l'aide d'un ID de thème personnalisé. Y compris une option de production moins verbeuse, voire une fonction de rappel à personnaliser. Et je suppose qu'une classe sur la racine est généralement toujours nécessaire de toute façon.

Je pense qu'il y a de nombreuses exigences énumérées et des suggestions proposées. Alors, y a-t-il quelque chose à retenir de toute cette discussion? Quelle est la prochaine ligne de conduite? Y a-t-il des travaux en cours sur l'implémentation de react-jss dans ce matériel-ui?

@rvbyron Oui, nous expérimentons quelques idées approximatives dans les coulisses. Mettra à jour ce problème lorsque nous aurons des idées plus concrètes.

À mon humble avis, je pense que CSS et tout ce qui s'y compile ne font pas partie du futur. Je pense que nous sommes tous d'accord pour dire que les styles en ligne nous ont beaucoup facilité la vie. Honnêtement, la seule limitation que je vois avec les styles en ligne est: hover!

Le problème est que: le survol est une partie très basique et très vitale des styles. Mis à part le futurisme, il pourrait être prudent d'éviter de s'engager prématurément dans une solution qui doit recourir à des astuces et à des solutions de contournement pour réimplémenter une fonctionnalité native.

@wtgtybhertgeghgtwtg nous travaillons à une solution qui utilise de vraies feuilles de style afin que des fonctionnalités telles que :hover soient prises en charge.

Étant donné que les points principaux ont été décidés (style JSS via className et l'élément racine classNames), existe-t-il une feuille de route et un calendrier pour la version material-ui v0.16.0?

@rvbyron Nous n'avons pas de calendrier promis, mais pour le moment, l'approche stylistique et les performances sont notre objectif principal pour la version v0.16.0 et sur quoi nous travaillons activement. Nous utiliserons probablement ce problème dans un proche avenir pour les commentaires de la communauté une fois que nous aurons décidé de la bonne direction dans quelques autres domaines en ce qui concerne les internes, l'API, la migration, etc.

@newoga Merci Neil! J'apprécie la mise à jour. En ce qui concerne les autres problèmes, je voudrais ajouter que le simple fait de passer à un système basé sur className peut être un changement visuellement révolutionnaire pour beaucoup et je suggérerais de limiter cette version à cela. D'autres changements en plus de cela pourraient vraiment entraver une migration. Cependant, je sais que votre équipe choisira le meilleur équilibre.

@newoga ici jss a été appelé comme le futur du système de style pour material-ui. Est-ce un plan suffisamment concret pour que d'autres puissent commencer à intégrer jss dans nos projets maintenant, en prévision de la version 16.0?

@sorahn pas encore

@sorahn Ce numéro est conçu pour obtenir des commentaires de la communauté sur ce qui reste un problème vraiment difficile à résoudre. Aucune décision officielle n'a été prise. À partir de maintenant, tout le monde ne devrait choisir et utiliser qu'une bibliothèque de styles ou une approche qu'il a jugée la meilleure pour lui et son projet.

Pour mémoire, l'objectif de ce changement de style n'est pas de migrer tout le monde vers une norme différente, mais de faciliter l'utilisation et le style des composants Material-UI, quelle que soit l'approche de style que vous utilisez.

tl; dr Non! Faites ce qui est le mieux pour vous, pas ce que les autres disent :)

@nathanmarks @newoga Merci pour la mise à jour!

Nous rencontrons les limites de la conception réactive + du rendu côté serveur avec tous les styles en ligne, nous étudions donc les alternatives. Pas d'opinions particulièrement fortes sur les modules css ou csx ou autre chose, mais nous aimons material-ui donc ce serait génial de suivre tout ce que vous allez faire :)

J'ai rencontré des requêtes médiatiques, j'ai lu ce fil (et d'autres). J'ai plongé dans certaines des solutions et articles potentiels.

J'aime beaucoup la solution JSS + CSX (du point de vue du développeur _joy_).

Avantages et performances JSS

Semblable à @sorahn , je serais heureux d'adopter une norme matérielle-ui, j'espère que @nathanmarks travaille dans ce sens valide cette approche. En outre, il semble que les deux développeurs CSX / JSS soient désireux d'aider et de promouvoir l'adoption de leurs bibliothèques.

@rosskevin Travailler dessus au moment où nous parlons - il y a des choses à considérer ici qui n'ont été couvertes dans aucune des solutions à ce jour.

Nos exigences sont beaucoup plus larges que ce que les solutions existantes sont capables de supporter en raison des limites de conception ou des opinions. C'est en grande partie parce que les solutions existantes ont été développées en pensant aux applications où vous avez un contrôle total sur la consommation de vos API de composants par rapport à une bibliothèque où vous avez un ensemble diversifié d'utilisateurs souhaitant styliser leurs composants avec différents outils.

@sorahn Question rapide - que faites-vous des préfixes de fournisseur avec rendu côté serveur? Rendez-vous simplement tous les préfixes sur le serveur? Ou passez-vous l'UA?

@nathanmarks Nous envoyons l'agent utilisateur au navigateur, mais personnellement, je n'aime pas me fier à cela. Pourquoi ne pas les mettre tous par défaut et permettre aux gens de les remplacer via des accessoires sur l'objet muiTheme, ou au contraire, n'en faire aucun par défaut et autoriser les gens à les activer.

muiTheme: {
  // other stuff...
  stylePrefixes: ['webkit', 'moz', 'ms']
}

@sorahn Vous pourrez faire ce que vous voulez, préfixe, pas préfixe, passer all , passer un UA, etc.

@nathanmarks Je viens de publier [email protected]. Changement le plus important - génération d'identifiant déterministe, voici un exemple de ssr avec react http://jsstyles.github.io/examples/index.html

Juste jeter mon $ .02 ici ... alors que j'aime vraiment l'idée des styles en ligne et que les aphrodites me plaisent, j'ai presque l'impression que ce serait plus facile si les styles étaient basés dans un format de bibliothèque en scss comme bootstrap 4.

Ce que je fais habituellement est de copier littéralement le fichier bootstrap.scss et le fichier _variables.scss lors de la création d'un fichier _mixins.scss ... avec cette copie sous ./lib/style, je mets à jour le fichier bootstrap.scss local pour référencer le fichier local variables et mixins, tout en utilisant le chemin vers les versions de node_modules de tout le reste ...

J'ai ensuite configuré ma configuration webpack pour intégrer ./lib/style au chemin de recherche de la configuration sassLoader.

De cette façon, je peux avoir un fichier main.scss qui charge bootstrap, etc ... Je peux à partir de là référencer des variables et / ou des mixins dans le reste de mon projet, et quand je construis / regroupe la sortie, les styles appropriés sont inclus.

L'inconvénient de cela, c'est qu'il prescrirait d'utiliser material-ui comme source (pas de pré-compilation) et webpack pour inclure scss dans les bundles. Cela dit, ce serait probablement le moyen le plus simple d'utiliser des variables, des classes et des mixins de style existants.

Encore une fois, j'aime vraiment l'idée du style JS, et j'aime ce qu'Aphrodite a à offrir ... Je travaillais sur quelque chose de similaire (j'allais l'appeler derma) en tant que bibliothèque de style pour les styles en ligne, mais Aphrodite fait déjà tout ce que je prévu et plus encore.

La solution de coiffage est-elle finalisée?

Y a-t-il des mises à jour à ce sujet?

Oui, la branche next utilise jss

Je viens de tomber sur ce projet et j'en étais extrêmement enthousiasmé car il avait l'air génial, la page d'exemple permettait de comprendre très facilement comment utiliser les composants et il semblait qu'il était largement utilisé; cependant, je suis très déçu par les montants en ligne et je suis heureux de voir que vous vous en éloignez. Une des choses que je voudrais souligner est que tout ce qui concerne la mise en page en dehors de ces composants doit être supprimé et laisser le style du composant parent gérer cela. Le composant de niveau le plus bas ne devrait pas avoir de marges ou de rembourrage de quelque manière que ce soit qui repousserait les éléments environnants ... d'autant plus qu'il est presque impossible de passer outre sans jouer avec les montants en ligne, ce qui signifie que je dois creuser et savoir comment faire cette. Je n'ai pas vraiment approfondi ce projet car je le trouve malheureusement inutilisable. J'ai certainement lu beaucoup de discussions sur le style en ligne et le style CSS. Bref, tu m'as perdu à TextField. Il y a une marge en haut de 14 pixels et en bas de 16 pixels. Cela ne me dérangerait pas trop d'écrire un style simple pour remplacer cela, mais c'est impossible à cause du style en ligne et il serait complètement fou pour moi d'avoir à créer un composant de niveau supérieur juste pour inverser cela comme en enveloppant votre composant avec un div et faire de la marge: -14px 0 -16px ou ajustez-le légèrement avec un calcul comme je le souhaite, mais avoir à corriger cela de quelque manière que ce soit ne devrait pas vraiment être nécessaire. Je préférerais que vous autorisiez un nom de classe à être passé comme accessoire comme vous le faites déjà afin que le style de mise en page puisse être appliqué au composant de la manière dont votre communauté souhaite le styliser. Quoi qu'il en soit, c'est mon 0,02 $.

Pour ajouter à cela, la création de composants de type de mise en page pour ceux-ci ou la création d'accessoires supplémentaires pour gérer les propriétés de la mise en page peut être idéale, comme l'utilisation d'un système de grille comme le font la fondation et le bootstrap. Par exemple, utilisez des accessoires tels que la taille, la gouttière, la largeur, les colonnes, etc., mais commencez sans style à l'extérieur de ce qui est visible avec le composant.

Je suis complètement avec @ jbsmith969

ce serait complètement fou pour moi d'avoir à créer un composant de niveau supérieur juste pour inverser cela, comme en enveloppant votre composant avec un div et en faisant une marge: -14px 0 -16px ou l'ajuster légèrement avec un calcul comme je le souhaite

@ jbsmith969 Je suis d'accord que les composants de bas niveau ne devraient pas avoir de logique de disposition. Cependant, créer un composant plus abstrait pour la spécificité de votre application ne semble pas du tout fou.
IMHO, c'est l'un des modèles les plus puissants que React permet (grâce aux propriétés d'isolation).

@oliviertassinari @ jbsmith969 C'est exactement ce que nous avons fait! Nous avons créé notre composant CustomTextField auquel je passe comme 2 paramètres à (nom du champ et couleur), et il fait juste un tout petit peu de logique autour de ceux-ci, puis rend un material-ui/TextField avec tout ce que nous vouloir.

Ce sont des composants tout en bas!

Donc, avec react, nous prenons notre html et le mettons dans notre js et c'est bien et dandy. Mais prendre notre css et le pousser dans notre html? Cela ne convient-il pas à quelqu'un d'autre?

Quel était l'avantage de sortir de la sass?

Appelez-moi à l'ancienne, mais qu'y a-t-il de si mal à garder notre js / html et notre css séparés?

Je cherche légitimement quelques réponses ici ...

Lié à https://github.com/callemall/material-ui/issues/3614#issuecomment -249095805, le style devient simplement des composants.

Je vois les classes CSS comme de nouveaux composants: (par exemple btn-danger -like de boostrap)

const DangerButton = ({ hoverColor, style, ...others }) => {
    return (
        <MUI.FlatButton
            hoverColor={hoverColor || Colors.pink100}
            style={{ color: Colors.black, ...style }}
            {...others}
        />
    );
};

Les transitions sont cependant pénibles.

(pour @ jbsmith969 , MUI suit la spécification Material Design. Si je ne veux pas suivre la spécification, je m'attendrais à faire une solution de contournement. Cependant, je conviens que MUI est difficile à pirater, mais c'est principalement à cause de bizarrerie incohérente accessoires de composants, pas parce que leurs styles sont en ligne)

@vizath right J'ai définitivement la même pensée. Mais quels sont les avantages de cette solution?

S'il y avait une solution qui fonctionnait au moins aussi bien que le CSS, j'envisagerais de lui donner une chance. Cependant, comme il n'y a pas actuellement de solution (que je connaisse) qui puisse le faire sans mise en garde, je ne vois pas vraiment l'apel.

Pourquoi ce dépôt essaie-t-il d'adopter ce qui semble être une idée de stade alpha pour une solution dans une base de code par ailleurs très utile? Je ne pense tout simplement pas que nous en soyons encore là avec le tec, et je ne pense pas non plus que ce soit le banc d'essai approprié pour ce tec.

@nathanmarks pouvez-vous nous conseiller sur la façon de remplacer les styles des composants à l'aide de JSS? J'utilise le dernier code dans next

EDIT: OK, seulement compris que ce n'est toujours pas entièrement mis en œuvre. Ma faute! 😬

Je n'ai pas encore trouvé de bon moyen d'éliminer le code mort dans les clés d'objet, et avec JSS, il est obligatoire d'utiliser des objets pour stocker les styles.

Exemple aléatoire dans un composant de la branche next (qui n'est pas terminé): https://github.com/callemall/material-ui/blob/b372f6223ec2528dbe02f100e4802334f88445b7/src/IconButton/IconButton.js#L36
Je ne trouve pas de moyen de trouver de manière fiable que les classes primary et accent ne sont pas utilisées.

Je n'aimais pas non plus la façon dont MUI gérait les styles en ligne auparavant, pour la même raison (lint aurait attrapé les variables non publiées si les styles étaient définis séparément, voir https://github.com/callemall/material-ui/blob/ 60a202fdc9645aa00f20c52e5152f168a1b0031b / src / IconButton / IconButton.js # L26).

Quel était l'avantage de sortir de la sass?

@gdaunton Cela dépend du côté que vous êtes de ne pas utiliser l'approche de style en ligne / sass.

Du point de vue de l'utilisateur , cela va apporter l'amélioration suivante:

• Méthode de rendu de réaction plus rapide, car nous allons nous appuyer sur des feuilles CSS générées en cache.
• Remplacement de style simplifié, car la priorité CSS est inférieure à celle du style en ligne et les utilisateurs peuvent utiliser les DevTools pour identifier la feuille à modifier.
• Première peinture plus rapide lors du rendu côté serveur.
  
  
  
  • Les utilisateurs pourront intégrer les feuilles CSS critiques, et uniquement celles utilisées dans la page. C'est quelque chose que vous NE POUVEZ PAS faire avec _Bootstrap_ car c'est un gros monolithe 🙈.
  
  
  • Les utilisateurs doivent pouvoir modifier les clés des noms de classe en production.
  
  
• Aucune dépendance de chaîne intégrée comme _scss-loader_ ou _Webpack_.

D'un point de vue contributeur / mainteneur , il va apporter les améliorations suivantes:

• Plus de linter CSS
• Plus de CSS pré-processeur
• Pas de syntaxe CSS à apprendre
• Un langage beaucoup plus puissant pour styliser le composant: JavaScript
• Ouvrez la possibilité d'abstraire le moteur de style. Par exemple, en utilisant réagir avec les styles

Pourquoi ce repo essaie-t-il d'adopter ce qui semble être une idée de stade alpha

Cela dépend de ce que vous entendez par idée de stade alpha.
Nous sommes loin d'être les seuls à avoir utilisé cette approche. Par exemple, AirBnB, Khan Academy, ReactNative.

fonctionnait au moins aussi bien que le CSS

CSS a été conçu dès le début pour styliser les documents , pas les composants .
C'est un changement majeur dans notre industrie.

De mon point de vue, ça craint pour les composants de style.
Les personnes à l'origine de la spécification Web sont bien conscientes de ce problème et essaient de le résoudre avec le style à portée locale de _Web Components_.
Avez-vous remarqué tous ces nouveaux projets depuis le lancement de React autour de l'amélioration du CSS et de l'écriture d'un style basé sur des composants?

Oui, la branche suivante utilise jss

@nathanmarks où puis-je me

Je l' ai trouvé:

@bramick semble qu'il ne s'agit pas de next car cela fonctionne à partir de 0.15.0

Ok, donc je rate ce qu'il y a de nouveau ... Quelqu'un?

@bramick next n'est pas encore entièrement documenté (mais il a un site de documentation). Pour l'instant, vous devrez lire la source et vous pouvez référencer le code source du site de documentation pour voir comment cela fonctionne. Réalisez simplement que certains d'entre eux peuvent encore être une cible mouvante.

@oliviertassinari Wow! Merci pour la réponse approfondie.

Je ne peux pas dire que je suis entièrement d'accord, mais vous avez résolu avec défi quelques questions que j'avais.

Je suis d'accord, nous devrions (et allons) évoluer vers un monde où nos styles sont basés sur des composants, et css n'est pas génial pour cela. Cependant, (à mon avis), il reste encore quelques rides à aplanir avant que nous ne devrions l'adopter à grande échelle.

Je suis curieux cependant, est-ce que quelqu'un a regardé pour voir s'il y avait une différence de performance entre cela et le CSS standard? J'ai l'impression que le CSS peut encore avoir un avantage sur javascript; après le chargement, il doit encore générer et injecter ses styles.

@gdaunton en savoir plus sur les performances jss sur https://github.com/cssinjs/jss/blob/master/docs/performance.md

Il s'agit d'un css standard tel que rendu, ajouté à la page, mais créé dans le composant. J'utilise la branche next et cela fonctionne assez bien.

@newoga pouvez-vous m'envoyer un lien vers ce dont vous parlez?

@bramick OMG! C'est vraiment simple, n'est-ce pas? Par exemple, pour Button dans next regardez ici .

Je comprends l'intérêt de mettre du CSS dans le fichier JavaScript, après le succès de JSX, mais je ne suis pas sûr que ce soit une bonne idée de faire de même avec tout le CSS d'une application. Je sais que JSS a de bons cas d'utilisation, par exemple lorsqu'il s'agit de styles dynamiques super complexes.

Ma plus grande préoccupation est que les informations de style finiront par encombrer la définition du composant . Le CSS exprimé avec des objets JavaScript est beaucoup plus verbeux et plus difficile à organiser . Par exemple, dans le composant Button référencé dans l'article précédent, près de la moitié du code est des informations de style. Il n'y a plus de séparation des préoccupations . Je sais que vous pouvez déplacer le code de style dans un fichier séparé, mais il ne sert à rien de l'avoir dans JavaScript en premier lieu.

Pour les développeurs, le plus gros inconvénient est qu'ils perdent toutes les informations intelli sense pour les propriétés CSS et leurs valeurs. En fait, j'aime toute cette belle structure de code et cette expressivité qu'un préprocesseur CSS peut vous donner, s'il est utilisé correctement.

Cela ne me dérange pas d'ajouter de la complexité à mes projets, si cela apporte plus de valeur. Donc je n'ai jamais fait attention au linter CSS supplémentaire, au pré-processeur, au chargeur et à la syntaxe supplémentaire que je devais apprendre. J'essaye aussi de rester ouvert sur JSS, c'est juste qu'après le premier regard ça ne m'a pas convaincu.

Ma plus grande préoccupation est que les informations de style finiront par encombrer la définition du composant.

Cela dépend entièrement de vous, cela dépend de la façon dont vous organisez votre code, si vous vous en tenez à certaines règles, rien de mal ne se passe (en parlant d'une expérience de production de 2 ans).

Le CSS exprimé avec des objets JavaScript est beaucoup plus verbeux et plus difficile à organiser.

Il est en fait moins détaillé car vous avez un niveau de réutilisation de code plus élevé et moins de répétitions.

Pour les développeurs, le plus gros inconvénient est qu'ils perdent toutes les informations intelli sense pour les propriétés CSS et leurs valeurs.

Je pense que le but ici est de donner aux utilisateurs de material-ui le choix d'utiliser ce qu'ils veulent pour le style. La saisie semi-automatique pour CSS est un argument que j'entends souvent. Cela vient principalement de personnes qui n'utilisaient pas beaucoup de cssinj et de la peur de perdre certaines commodités auxquelles ils avaient l'habitude.

Cela ne me dérange pas d'ajouter de la complexité à mes projets, si cela apporte plus de valeur.

Je pense que le but est de réduire la complexité et de rendre la base de code plus cohérente et facile à utiliser et à comprendre, mais tous les scénarios complexes sont couverts en même temps.

Ma plus grande préoccupation est que les informations de style finiront par encombrer la définition du composant.

Dans notre projet, nous avons extrait les informations de style des composants dans des fichiers séparés et les avons chargés avec webpack. Le principal avantage est que tout est bien organisé et que le webpack peut regrouper le code par composant, de sorte que la division du code du code js ET des informations de style est possible.

Une séparation des préoccupations est également donnée, lorsque vous séparez la logique pour produire vos règles de style. Un exemple est que nous avons introduit des fonctions de fabrique de styles qui produisent des stlying un peu comme des mixins dans des préprocesseurs css bien connus.
Mon point est que vous gagnez beaucoup plus de flexibilité pour modéliser vos propres flux de travail spécifiques et vous adapter au mieux aux besoins du projet et de l'équipe.

vérifiez ceci https://styled-components.com/

Il est assez tard dans le jeu pour changer de technologie, mais je suis d'accord que les composants stylisés sont très prometteurs. Gère SSR, requêtes multimédias, syntaxe assez sympa, etc. Comparé à JSS, il gère également le préfixage automatique et le thème.

Autant que je sache, il utilise postcss à l'intérieur, ce qui ne donnera pas des performances acceptables lorsqu'il est utilisé au moment de l'exécution, car il s'agit d'un analyseur css complet avec beaucoup de gestion des cas marginaux et de plugins. Je pourrais imaginer pré-traiter cela en JSS JSON, mais pour être honnête, je ne vois pas beaucoup d'intérêt à utiliser le langage CSS et à le mélanger avec des variables JS et des appels de fonction plutôt que d'utiliser simplement JS tout en bas.

Juste pour mentionner, la version actuelle des composants stylisés est de 250 Ko, déjà minifiée . Pour être honnête, c'est parce qu'ils regroupent React et co, mais malgré tout, même l'analyseur PostCSS a à lui seul 13 ko (non réduit, peut-être 2 ko ~), ce qui est déjà presque la taille de JSS ou Fela.

C'est bien pour le prototypage rapide et simple du composant (de présentation), mais je ne vois aucun avantage / fonctionnalité que d'autres solutions ne peuvent pas fournir.

Je suis d'accord, je l'ai essayé dans une bibliothèque que je développe et c'était beaucoup trop lourd à publier. Je suis sûr qu'ils feront des progrès avec cela, mais il semble que le travail JSS ici soit presque terminé et offre la plupart des mêmes avantages.

J'ai récemment utilisé react-toolbox , ils utilisent des modules CSS pour la thématisation qui reposent essentiellement sur sassLoader webpack. Pour moi, cela a très bien fonctionné. Cela vaut peut-être la peine d'enquêter.

Hé, je dois seconder l'opinion de @mgcrea , le support de la thématisation de React -

Je ne pense pas que quiconque devrait jamais s'attendre à ce que le bon vieux style CSS soit un citoyen de première classe dans Material UI, c'est la raison react-toolbox laquelle

Du moins, c'est mon impression après avoir lu de nombreux problèmes et articles sur ce sujet. Je me souviens vaguement de choses telles que l'équipe s'efforce d'améliorer la compatibilité React Native et de nombreux commentaires sur le style des cas de bord qui sont simplement beaucoup plus faciles à résoudre avec JSS.

Cependant, cette information est perdue au cours de nombreuses discussions. Parce que c'est un sujet tellement controversé, je pense que ce serait d'une valeur incroyable si l'on pouvait avoir une page Wiki sur les objectifs et la philosophie du projet (écrite par les principaux mainteneurs) avec une remarque forte sur les raisons pour lesquelles le style Javascript est si ancré dans le cadre.

J'aime beaucoup Material UI car c'est le cadre de style de matériau le plus actif et le plus raffiné de React. Cependant, le JSS tout au long me cause beaucoup de maux de tête lorsque je veux garder un style unifié avec des composants tiers.

Pour moi, j'apprécie la façon dont Material-UI fait le style par opposition à quelque chose comme react-toolbox, et voici pourquoi: dans l'un de nos projets, nous avons la possibilité pour l'utilisateur de sélectionner des thèmes dynamiques:

Étant donné que l'utilisateur peut sélectionner une paire de couleurs que nous ne pouvons pas déterminer à l'avance, quel que soit le schéma de thème que nous utilisons, il doit être très dynamique. Avec, les modifications du thème peuvent se produire en direct, car tous les styles sont générés en ligne: il ne me reste plus qu'à lui donner des couleurs primaires / accentuées.

Dans react-toolbox et. al., cela semble être plus une corvée de ce que je peux voir.

@jrop ouais dans ce cas très particulier, vous avez besoin de JSS dynamique, mais pour de nombreuses applications, ce n'est pas une exigence importante et l'histoire actuelle de la personnalisation (sans même parler des tests d'interface utilisateur) material-ui n'est tout simplement pas acceptable. Nous construisons une application hautement visuelle et conçue qui ne peut pas simplement utiliser le look material-ui par défaut, car nous avons principalement besoin / voulons les parties comportementales de celle-ci.

@DominikGuzei vous pouvez personnaliser la branche next utilisant jss. Ce n'est _pas_ ce que vous voyez sur la version actuelle.

Les amis, j'ai l'impression que nous battons un cheval mort ici. La branche next a choisi un chemin différent (beaucoup amélioré) avec le thème et permet des remplacements. Il n'utilise plus de styles en ligne et offre la flexibilité que j'ai vue demandée. Pour d'autres qui veulent plus de personnalisation, ils peuvent utiliser un HOC sur les composants next et écrire leurs propres feuilles de style.

@nathanmarks , puisque cette décision a été prise (pour autant que je

si l'on pouvait avoir une page Wiki sur les objectifs et la philosophie du projet (écrite par les principaux responsables) avec une remarque forte sur la raison pour laquelle le style Javascript est si ancré dans le cadre.

@fgarcia J'ai fait une présentation lors d'un événement local à Paris plus tôt cette semaine concernant l' évolution de l'approche stylistique utilisée par Material-UI. Vous pourriez être intéressé par les diapositives et les _notes_: Un voyage vers un meilleur style . Je me concentre sur les défis, les problèmes et les solutions.

l'utilisateur pour sélectionner des thèmes dynamiques

L'aspect de génération de style statique des modules CSS a de nombreuses conséquences.
L'injection de style au moment de l'exécution est moins rentable mais nous permet de:

• Nous donne plus de flexibilité avec la mise en œuvre du style. Par exemple, le CircularProgress a un thickness fixe lié à la façon dont l'animation d'image clé CSS est implémentée. Avec le style dynamique, nous pouvons ajouter une propriété d'épaisseur afin que les utilisateurs puissent modifier la valeur de manière dynamique. ⚠️ pour ne pas être abusé.
• Sur une application à grande échelle, il permet d'injecter uniquement les styles nécessaires pour le composant affiché à l'écran. Réduire la quantité de travail nécessaire au navigateur pour démarrer la page. Par conséquent, un temps plus rapide pour la première peinture après l'interaction. Par exemple, intégrer CSS critique avec SSR.
• Permettez aux utilisateurs d'utiliser un thème dynamique et une variante de composants. Par exemple, changer la couleur d'un bouton avec toutes les variations de couleur nécessaires.

@oliviertassinari C'est génial à entendre. J'ai peut-être un point de vue non standard sur les modules CSS, mais je ne pense pas qu'ils en valent la peine. J'étais ravi d'entendre parler de JSS via material-ui pour cette raison. Cela semble beaucoup plus conforme à la philosophie de JavaScript que les modules CSS.

@oliviertassinari merci pour le résumé des avantages. C'est vraiment intéressant quand on regarde ces aspects. L'inconvénient de JSS et de son écosystème (également postcss) pour le moment est que tout ce qui est à la pointe de la technologie et que vous ne pouvez pas vous fier à la chaîne d'outils et à la base de connaissances bien établies, comme avec de simples modules css + SASS. Mais c'est le prix que vous payez pour l'innovation, cela dépend simplement si vous avez certaines exigences / êtes prêt à payer le prix des bogues et du chemin le moins documenté.

JSS a été créé avant les modules css. Les modules CSS sont devenus plus rapidement populaires car ils ont résolu un problème pour une majorité d'utilisateurs sans changer la syntaxe trop radicalement.

Cela étant dit, vous utilisez react, qui est aussi une sorte de "nouvelle" technologie. Si vous voulez SASS, vous devriez peut-être aussi choisir vanilajs ou backbonejs)

@kof React est une histoire très différente car elle est utilisée par des centaines de milliers de développeurs et est gérée par Facebook (elle ne disparaîtra pas du jour au lendemain), donc elle pourrait être "nouvelle" mais très solide (pas rencontré de nombreux problèmes avec elle jusqu'à présent).

SASS est l'un des préprocesseurs css les plus établis et peut être utilisé dans n'importe quel projet - il est très solide et apporte beaucoup de valeur à la table. Donc, je ne choisirais quelque chose comme JSS que si c'est absolument nécessaire (par exemple: à cause de thèmes dynamiques) mais je n'aime pas jeter des années d'expérience / cadres / base de connaissances, etc. dans un projet de logiciel commercial avec plusieurs développeurs. Donc, j'envisagerais même de ne construire que l'aspect du thème dynamique dans JSS et le reste avec sass / css-modules.

Je comprends cette façon de penser, mais je la considère aussi comme contre-productive et je lui reproche de ralentir l'innovation et l'industrie.

Pourquoi tu ne supportes pas les deux? Des styles écrits en JavaScript ET des styles écrits dans des modules css? Si je regarde https://github.com/callemall/material-ui/blob/next/src/Button/Button.js par exemple, il serait assez facile d'utiliser des noms de classe transmis par un accessoire ( https://github.com/javivelasco/react-css-themr) au lieu d'utiliser:

const classes = this.context.styleManager.render(styleSheet);

N'est-ce pas?

Il ne semble pas que la discussion sur l'utilisation de JSS ou CSS trouve une fin (encore?). Pour moi, cela ressemble à une chose cinquante / cinquante pour le moment.

En ce qui concerne SASS, react-toolbox s'en éloigne actuellement

Le style dans tous les JS, et dans React en particulier, est évidemment encore dans un état d'évolution rapide. Donc, quoi que vous fassiez, j'essaierais d'éviter d'être avisé - tout simplement bien avec un large éventail d'utilisations actuelles.

Envisagez d'ajouter simplement un accessoire * className partout où il y a un accessoire de style *. Période.

Divulgation complète: je suis un utilisateur heureux d'Aphrodite.

L'ajout d'un className exigera toujours des hacks !important car les styles en ligne (à partir style propriété

@ligaz Bien sûr, vous avez raison. Aphrodite ajoute !important à tout par défaut, donc peut-être que ma réflexion sur un «large éventail d'utilisations» est mal biaisée.

@ligaz @estaub - next est déjà codé _without_ style et permet aux utilisateurs des composants de passer outre en fournissant className (et plusieurs noms de classe aux différentes parties des composants complexes) .

La configuration du paradigme de style sur la branche next par les responsables utilise JSS. C'est un plaisir à utiliser et facile à remplacer sur une base individuelle ou thématique.

Ce cheval est mort. Arrêtons de le battre. @oliviertassinari Je vous suggère de fermer et de verrouiller ce problème avec une déclaration de direction sur next .

Salut @rosskevin - pouvez-vous me montrer des exemples de la façon dont cela fonctionne ensuite?

Je suis actuellement à la recherche de cadres pour un nouveau projet, j'aimerais utiliser Material UI mais nous aurions besoin des modifications que vous avez mentionnées ci-dessous. J'ai ajouté la branche suivante à un projet de test et ajouté un composant simple et je vois un inspecteur plein de styles en ligne, donc je suppose que je fais quelque chose de mal?

Tout autre détail serait vraiment utile!

Merci

@giuseppepaul next n'est pas publié sur npm car il est pré-alpha et n'est pas encore terminé. Vous pouvez cloner https://github.com/callemall/material-ui.git#next et exécuter docs/site pour voir qu'il n'y a plus de styles en ligne. Il a également un nombre raisonnable de démos.

Je publie ma propre version privée de next (afin que je puisse contrôler les mises à jour) et je l'utilise dans une application de production qui sera bientôt disponible.

Ce cheval est mort. Arrêtons de le battre. @oliviertassinari Je vous suggère de fermer et de verrouiller ce problème avec une déclaration de direction sur le prochain.

Ce cheval n'est pas complètement mort. Mais certainement dans une situation difficile 🔫.
Je suis d'accord, fermons ce problème.

Un grand merci à @nathanmarks pour son travail acharné sur cette histoire 👏!
J'ai rassemblé plus d'informations sur la route à suivre avec le # 5718.

Bonjour,
IconButton ont une propriété CSS3 transition pour l'effet d'entraînement. Dans l'interaction complexe de la documentation de Card @next , vous avez ajouté un transition à la transformation pour ajouter une transition lorsque l'icône s'inverse.
Si je fais la même chose sur mon application, une transition (ondulation ou réversion) remplace l'autre (un élément ne peut pas avoir deux propriétés sinon l'une remplace l'autre).
Cependant, votre icône en chevron a deux transitions appliqués avec succès. Parce que d'une certaine manière, vous fusionnez les transitions fournies par IconButton et celle définie dans votre code. Comment y parvenir?
Certains autres trucs sont obscurs pour moi et je ne trouve pas de documentation connexe. theme a beaucoup de méthodes / propriétés comme breakpoints (non utilisé ici) transitions (utilisé ici). Existe-t-il déjà une documentation sur la propriété theme de ce que MuiThemeProvider.createDefaultContext() retourne car cela semble utile, en particulier parce qu'il est largement utilisé dans votre code.
this.context.styleManager.render(styleSheet) ? Quoi ?
Vous utilisez également jss-theme-reactor dont je ne comprends toujours pas le point par rapport à react-jss .

@NitroBAY Ce fil est terminé. Veuillez poser votre question sur le bon canal.Si vous remarquez un bogue ou souhaitez que la documentation soit améliorée, ouvrez un problème. Sinon, vous pouvez utiliser StackOverflow de gitter.im.