Material-ui: [RFC] Solution de style v5 💅

Juste pour quelques corrections:

La communauté React, dans son ensemble, a voté contre l'utilisation de JSS à grande échelle.

Je suggérerais plutôt que la communauté React n'a pas voté _for_ JSS. Peut-être n'était-ce pas «commercialisé» aussi bien que d'autres solutions?

Nous n'avons pas misé sur le bon cheval.

Nous avons parié sur le seul cheval - c'était une course à un cheval. Aucune des autres solutions disponibles à l'époque ne coche toutes les cases.

L'émotion sonne bien! J'adore obtenir le support TS, par exemple, la saisie semi-automatique et tous les avantages de la saisie - avec CSS-in-JS - lors de la création de l'interface utilisateur ou de la création de composants de style, est-ce toujours possible?

Le dernier morceau m'a eu! J'adorerais aider en faisant cela derrière un drapeau bêta ou en développant certaines fonctionnalités:

Toutes les compositions utilisant l'émotion (que ce soit au moment du rendu ou de la composition au moment de la définition) aboutissent à une seule classe sur l'élément.
Les composants stylisés ne fonctionnent PAS de cette manière en ce qui concerne la composition au moment du rendu (la composition au moment de la définition est combinée en une seule classe).

J'ai également noté que l'objet de thème va rester le même, le - à mon avis - le meilleur moyen absolu de thème une application! Je n'ai rien d'autre à dire: étonné:

Merci pour l'excellent travail sur M-UI. J'adore l'orientation du projet.

Passer à un style plus standardisé est la voie à suivre. Je sais que l'équipe et la communauté régleront les problèmes, et la v5 - d'après le son - sera encore plus géniale! :fusée:

En tant que personne ayant utilisé à la fois des composants stylisés et des émotions, je peux confirmer que la transition entre eux est facile et sans douleur.

+ l'émotion est plus conviviale

Parler en tant que mainteneur d'Emotion - cela sonne bien 🚀

Nous devrions également être en mesure de publier bientôt un nouveau majeur qui ne sera pas une révolution, juste quelques nettoyages, des améliorations globales, des crochets sous le capot et des améliorations des types TS (meilleure inférence et performances).

Oh, et analyseur réécrit! qui élimine certains bogues de bord dans Emotion et Styled-Components (comme actuellement, ils utilisent tous les deux le même analyseur). C'est à la fois plus petit et plus rapide.

Qu'en est-il des changements de rupture, quelle option introduit plus de changements de rupture (le cas échéant)?

Vous ne savez pas si cela fait une différence, mais les benchmarks ont-ils été réalisés avec les plugins babel d'émotion et / ou de composant de style? Ils aident à optimiser davantage les choses.

J'ai cru comprendre que MUI avait précédemment indiqué qu'il allait avec le style, c'est donc une surprise. Je pense que l'émotion est une excellente bibliothèque, mais avec plus de gens qui utilisent actuellement le style, il est important que vous trouviez des moyens de leur donner de bonnes options s'ils ne veulent pas migrer vers l'émotion.

@ ee0pdt Emotion est très, très semblable au style. Je pense que cela fait partie du choix global d'Emotion par rapport aux composants stylisés. Il y a des avantages évidents et la dette migratoire est faible ou nulle.

Et il y a toute une section sur la prise en charge des deux en donnant le choix aux développeurs. Cela pourrait être une voie à suivre, mais encore une fois, la normalisation nous aiderait probablement davantage à l'avenir. La simultanéité complète et l'absence de composants wrapper sont pour moi un facteur décisif. Je comprends que d'autres pourraient vouloir quelque chose de stylé, et cela devrait être pris en compte. Je préfère pousser vers la standardisation

Pourquoi le styletron-react a-t-il été exclu? Il laisse de côté toute une métrique qui n'a pas été prise en compte, à savoir la consommation de mémoire. Le moteur styletron par défaut (et fela) est atomique. Bien qu'un peu plus lent, cela économise beaucoup de mémoire. Ayant vu beaucoup de pages de réaction ne rien faire et aller> 1 Go après un certain temps, c'est un peu inquiétant. Le navigateur se fige après cela.

Avec un framework atomique, les performances s'améliorent globalement au fil du temps, à travers les composants, car chaque "classe" atomique est mise en cache. Probablement pas non plus reflété dans le test.

Heureux avec l'un ou l'autre tant qu'il prend en charge SSR

Je viens de retirer mon vote du problème des composants stylisés d'origine: sweat_smile: - j'ai d'abord appris à connaître les émotions à travers un livre d'histoires, mais It will mean that all components styles need to be created using the styled API, which means for developers they will always have wrapper components if they need to re-style. m'a fait changer.

Merci à tous pour les commentaires rapides. Voici les réponses à certains des commentaires / questions.

Qu'en est-il des changements de rupture, quelle option introduit plus de changements de rupture (le cas échéant)?

@ sag1v en utilisant styled-components vs emotion n'introduit pas de changements plus ou moins importants que nous devrons gérer. Les changements de rupture globaux concerneraient l'apparence des remplacements à l'intérieur du thème:

// previosly
root: {
  contained: {
    '&$disabled': { // <-- this part will need to be transformed
      color: 'red',
    },
  },
  containedPrimary: {
    color: 'blue',
  },
}

// after
root: {
  contained: {
     '&.Mui-disabled': {
      color: 'red',
    },
  },
}

Cependant, comme la syntaxe des styles entre emotion & styled-components est identique, cela ne fera aucune différence.

Vous ne savez pas si cela fait une différence, mais les benchmarks ont-ils été réalisés avec les plugins babel d'émotion et / ou de composant de style? Ils aident à optimiser davantage les choses.

@ hc-codersatlas non, mais les perfs sont de toute façon entre les premiers, donc je ne pense pas que cela ferait une différence. Bon appel dur!

Pourquoi le styletron-react a-t-il été exclu? Il laisse de côté toute une métrique qui n'a pas été prise en compte, à savoir la consommation de mémoire. Le moteur styletron par défaut (et fela) est atomique. Bien qu'un peu plus lent, cela économise beaucoup de mémoire. Ayant vu beaucoup de pages de réaction ne rien faire et aller> 1 Go après un certain temps, c'est un peu inquiétant. Le navigateur se fige après cela.

Avec un framework atomique, les performances s'améliorent globalement au fil du temps, à travers les composants, car chaque "classe" atomique est mise en cache. Probablement pas non plus reflété dans le test.

Mes commentaires sur la raison styletron-react laquelle https://www.npmtrends.com/styletron-react-vs-@emotion/core -vs-styled-components il y a plus de 2000000 téléchargements au cours des 6 derniers mois, le styletron est d'environ 15000.

De plus, le css atomique peut causer des problèmes avec les remplacements, car chaque nom de classe ne contient qu'une seule règle de style.

J'ai une question si nous décidons d'utiliser l'émotion que nous voulons ajouter ci-dessous le code par-dessus tous les fichiers?
/ ** @jsx jsx * /
Ceci est le pragma JSX, par défaut le pragma JSX est React.createElement

Vous devez l'ajouter si vous utilisez la propriété css dans Emotion. Pour l'API styled ainsi que l'API className standard, vous n'en avez pas besoin.

Il est possible d'ignorer l'ajout du pragma JSX, mais cela nécessite une configuration supplémentaire de Babel et le support de l'outillage est moins bon - par exemple, TS n'est pas en mesure de vérifier le type de votre accessoire CSS aussi précisément que lors de l'utilisation du pragma JSX. Plus d'informations peuvent être trouvées ici: https://github.com/emotion-js/emotion/pull/1941/files#diff -9abe25e5d2b00958d4b9849f5f20c139R5

@mnajdova merci. J'espérais juste que l'utilisation de la mémoire soit couverte plus que la garantie du styletron en particulier. Quant aux téléchargements ou à la communauté - "seulement" Uber utilise le styletron :) donc pas de soucis. Voté pour l'émotion en premier lieu.

Ce serait cool s'il y avait un plugin babel ou similaire qui peut transformer les styles statiques en véritables classes css. Il existe déjà une bibliothèque similaire appelée compiled . De manière réaliste, la plupart des styles sont statiques.

Pour être utile, Fela aura besoin d'un ensemble de plugins comme fela-plugin-rtl , fela-plugin-prefixer qui rendront les performances encore pires (https://github.com/microsoft/fluentui/pull/12289) 🐢 Et puis vous vous retrouverez probablement avec Emotion (https://github.com/microsoft/fluentui/pull/13547) car parfois il peut être deux fois plus rapide que Fela 📦

Ma seule préoccupation est de devoir utiliser css thingy d'Emotion. C'est un gros drapeau rouge basé sur mon expérience. J'ai dû supprimer une telle chose d'une grande base de code et ce n'était pas amusant. Pourquoi? Parce que c'est une abstraction qui apporte plus de problèmes que celle qui résout sur le long terme.

La plupart du temps, nous essayons d'utiliser la fonction styled , mais nous sommes plutôt satisfaits de la fonction makeStyles pour générer certaines classes dans certains cas.

Espérons qu'il n'y a pas de changement de rupture pour ces deux API et que je ne suis pas obligé d'utiliser la macro css .

Ma seule préoccupation est de devoir utiliser le truc CSS d'Emotion.

@yordis Vous ne serez certainement pas obligé d'utiliser le prop css . Je soupçonne qu'il y aura un certain degré de changement pour les utilisations de makeStyles et withStyles . Espérons que la quantité de changement nécessaire peut être principalement limitée à un codemod sur les importations. Je ne pense pas que l'approche utilisée dans makeStyles ou withStyles sera pratique pour prendre en charge l'utilisation de l'émotion, donc je m'attendrais à ce que toute prise en charge continue de ces API se fasse via un package séparé (de sorte que " @ material-ui / core "n'a plus de dépendance JSS) qui ne recevrait probablement qu'une maintenance minimale après la sortie de la v5 (les détails sur ce qui arrive à makeStyles et withStyles ne sont pas cloués Pourtant, ce n'est donc que ma spéculation sur les implications d'aller de l'avant avec l'émotion).

👍 le choix d'utiliser Emotion. Éviter l'API styled de styled-components est l'une des raisons pour lesquelles mon équipe a choisi Emotion (qui prend également en charge une API styled similaire en plus de l'accessoire css ). Nous utilisons actuellement Emotion pour la personnalisation du style Material UI et cela fonctionne plutôt bien. Un support intégré ne serait que la cerise sur le gâteau.

Concernant ces faits:

De nombreux développeurs utilisent des composants stylisés pour remplacer les styles de Material-UI. Les utilisateurs finaux se retrouvent avec deux bibliothèques CSS-in-JS dans leur bundle

Prise en charge du mode simultané
styled-components: Partiel

Si les composants stylisés avaient un support complet pour le mode simultané, serait-ce un choix plus judicieux, étant donné que la plupart des développeurs remplacent MUI avec des composants stylisés (à l'exclusion de JSS)? Le fait que l'émotion soit plus petite en taille de paquet est sans objet si 2 solutions css-in-js doivent être incluses. Et je suppose que la plupart des applications pratiques de MUI impliquent de remplacer ses styles.

Là où mon équipe et moi utilisons Emotion comme principal moyen de styliser les composants, je suis tombé sur des inefficacités présentes dans la bibliothèque d'émotions. Et je me demande ce que vous pensez de ces inefficacités expliquées ci-dessous.

Considérez ci-dessous Emotion StyledComponent;

const StyledComponent = styled.div`
  ${({color}) => color && `color: ${color}`};
  display: flex;
  justify-content: center;
  align-items: center;
  background: teal;
  font-size: 20px;
  padding-top: 8px;
  padding-bottom: 8px;
  margin-top: 12px;
  margin-bottom: 12px;
  border: 1px solid grey;
`

Lorsque les accessoires de couleur changent, une nouvelle classe css est générée avec tous les accessoires css ( display: flex, justify-content, ..., border: 1px soild grey ) copiés. Ce qui aboutirait à des classes css avec exactement les mêmes accessoires css pour chaque accessoire de couleur, voir ci-dessous;

Une autre inefficacité que nous avons trouvée est lorsqu'un nouveau composant est dérivé de ci-dessus StyledComponent il crée une nouvelle classe avec tous les accessoires css copiés à partir de la base StyledComponent . Considérez ci-dessous;

const DerivedComponent = styled(StyledComponent)`
  font-family: monospace;
`

Il crée une autre classe css qui ajoute uniquement font-family: monospace à la classe css ci-dessus générée à partir de StyledComponent . Autrement dit, il crée un css qui a tous les accessoires copiés de StyledComponent comme on peut le voir ci-dessous;

Maintenant, si ci-dessus StyledComponent et DerivedComponent sont utilisés ensemble, nous avons (initialement) deux classes css qui ont des props css en double, (ne différant que par font-family). Comme on peut le voir ci-dessous;

Comme vous pouvez l'imaginer, un certain nombre de classes css qui ont des accessoires css en double les unes des autres peuvent se développer assez rapidement.

J'ai trouvé qu'avec Emotion, comme les styles de composants sont composés ensemble, nous nous retrouvons avec des classes css avec de nombreux accessoires css en double.

Je ne suis pas sûr que ce double des accessoires css dans chaque classe css ait un impact notable sur les applications, mais je me demande si cela est pris en compte lors du choix d'utiliser l'émotion.

Je ne remets pas en question les performances d'Emotion dans la création et l'application de CSSStyle au moment de l'exécution. L'émotion est l'une des méthodes d'application les plus rapides des styles CSS, comme en témoignent les tests de performance.
Je suis juste préoccupé par le CSSstyle résultant est gonflé. Et comme Emotion peut être SSR (ed), ce qui signifie que les styles sont incorporés en HTML, nous pourrions simplement obtenir un fichier HTML inutilement gonflé (avec des balises de style css). Ce qui entraîne à son tour beaucoup plus de balises à analyser avec des accessoires CSS inutiles par les navigateurs.

Si les composants stylisés avaient un support complet pour le mode simultané, serait-ce un choix plus judicieux, étant donné que la plupart des développeurs remplacent MUI avec des composants stylisés (à l'exclusion de JSS)? Le fait que l'émotion soit plus petite en taille de paquet est sans objet si 2 solutions css-in-js doivent être incluses. Et je suppose que la plupart des applications pratiques de MUI impliquent de remplacer ses styles.

@petermikitsh les raisons pour lesquelles nous avons conclu sur l'émotion sont en fait les quatre points de la conclusion

• Un petit coût de migration entre les composants stylisés et l'émotion
  Les développeurs qui utilisent déjà des composants stylisés devraient pouvoir utiliser l'émotion presque sans effort.
• Il existe différentes manières d'ajouter des remplacements autres que les composants wrapper
  La prise en charge de cx + css depuis Emotion peut être bénéfique pour les développeurs de l'utiliser comme alternative pour ajouter des remplacements de style s'ils ne veulent pas créer de composants wrapper.
• Le mode simultané est certainement pris en charge 👍
• Comment la spécificité est gérée

En ayant le premier point à l'esprit, si les développeurs veulent vraiment éviter d'avoir deux solutions css-in-js dans le bundle, le coût de migration est vraiment faible pour passer à emotion + il prend en charge différentes API autres que styled .

@ ko-toss merci d'avoir écrit ceci, ce sont tous de bons points. Le fait que l'émotion génère un nom de classe avec tous les styles en fait le meilleur moteur pour résoudre les remplacements. Le problème que nous pouvons avoir avec plusieurs classNames générés est que la dernière classe écrite l'emportera, ce qui peut devenir problématique à l'avenir.

Sur un autre projet, j'utilisais un css atomique, où la consommation de mémoire est bien meilleure car toutes les règles css ne sont écrites qu'une seule fois, mais faire des remplacements prévisibles est assez difficile, car chaque nom de classe est une règle atomique, et encore une fois celle qui gagne, dépend de l'ordre dans lequel ils sont écrits, si vous ne décidez pas de traiter au préalable tous les styles et de les fusionner correctement, ce qui peut avoir un impact sur les performances à la fin.

D'un autre côté, je pense qu'en utilisant n'importe quelle solution css-in-js, les gens ne créeront pas simplement une combinaison infinie de styles au hasard, ils sont toujours assez structurés en fonction de la valeur des accessoires.

Cependant, encore une fois, ce sont de bons points, que nous garderons à l'esprit, merci beaucoup de les partager 👍

• autre?

qu'en est-il de la compatibilité des idées [stylex] (comme [style9])

• autre?

style9 ou tout autre moteur CSS compatible avec stylex idea

Cela semble nécessiter une configuration du temps de construction qui découragerait de nombreuses personnes de l'utiliser, en particulier les débutants.

(c'est plutôt FYI, l'émotion est un bon choix)

https://github.com/cristianbote/goober (1kB, perf un peu pire que l'émotion)

Je n'ai pas encore d'expérience avec ça mais je veux l'essayer un jour.

@cztomsik Similaire à https://github.com/kuldeepkeshwar/filbert-js mais ne prend pas en charge la syntaxe JavaScript (uniquement la chaîne de modèle CSS)

Voici quelques tests effectués avec Google Lighthouse sur le temps d'interaction:

https://jantimon.github.io/css-framework-performance/

Pour info, j'ai fait un benchmark détaillé des composants stylés v5, emotion v10 et emotion v11, avec / sans plugin babel, avec l'API vanilla, l'API des accessoires css et l'API stylée. J'espère que cela aidera la discussion!

https://github.com/simnalamburt/css-in-js-benchmark

Avez-vous envisagé la nouvelle vague de bibliothèques css-in-js qui reposent fortement sur le support atomic css et dactylographié?

• https://github.com/modulz/stitches
• https://github.com/kripod/otion

Avez-vous envisagé la nouvelle vague de bibliothèques css-in-js qui reposent fortement sur le support atomic css et dactylographié?

• https://github.com/modulz/stitches

• https://github.com/kripod/otion

Ce n'est pas sur la référence, mais actuellement, l'otion est 2 à 4 fois plus lente que l'émotion. Je pense que otion a en effet un potentiel assez important et pense qu'il y a une place pour l'optimisation, mais otion n'est pas encore vraiment prête pour la production.

Cependant, je n'ai pas encore testé les points de suture. 😃

Qu'en est-il d'une véritable bibliothèque à exécution nulle? Je n'ai vu personne parler de linaria .

Je suis tombé sur la linaria à un moment donné et je l'aime vraiment. Mon seul souci est que les styles d'accessoires dynamiques dépendent uniquement des variables css, et il n'y a pas de support pour IE 11 basé sur https://github.com/callstack/linaria/issues/445 Également comparé à styled-components et emotion la communauté est beaucoup plus petite en ce moment.

@TheHolyWaffle
Linaria est géniale.
Si vous l'avez configuré correctement, je pense que c'est le meilleur des deux css-in-js (en termes d'expérience de développement) et css pur (ne peut pas battre les performances css pures). Il optimise même (déduplète) et réutilise les règles css.
Mais linaria nécessite une étape de construction et de regroupement, ce qui serait difficile pour les débutants.

J'aimerais voir les ports pour d'autres bibliothèques css-in-js avec une surface API similaire, par exemple filbert-js / goober

@kuldeepkeshwar Nous vous informerons une fois que nous aurons examiné les adaptateurs de l'API stylisée :)

Comment https://compiledcssinjs.com/ s'intègre-t-il dans tout cela? Cela semble être une approche incroyablement intéressante; Compiled exécute également des RFC pour le projet, ce qui s'avère idéal pour l'open source et la collaboration. _clin d'oeil clin d'oeil_

Je pense que l'avenir est très, très prometteur pour le style du Web, et j'espère que Material-UI fera partie intégrante de la solution incontournable pour styliser n'importe quelle application.

L'explication du fonctionnement de Compiled m'est arrivée:

Ce type de transformation nous permet de livrer votre composant à n'importe quel consommateur sans qu'il ait besoin de configurer / paramétrer son outillage. Importez et partez. C'est puissant, et plus important encore, le même que le CSS actuel dans les bibliothèques JS fonctionne - avec un seul hic.

_CSS ne peut pas être généré lors de l'exécution._

Cette seule contrainte nous ouvre de nombreuses portes. Optimisations du temps de construction. Garanties d'exécution. Les goulots d'étranglement de performance ont disparu.

Sur une note différente, j'aimerais souligner que la popularité ne signifie pas grand-chose pour un bon projet. J'adore MUI et le travail qui y est consacré jusqu'à présent; Je pense aussi que c'est fantastique qu'il soit devenu un produit haut de gamme.
Mais choisir un _nom_ «populaire» pour des raisons de popularité n'est pas un argument raisonnable.
J'ai vu la popularité référencée à plusieurs reprises, et je n'aime pas vraiment le fait que x personnes utilisent la technologie x - MUI est (dans mes livres) axé sur la performance, le DX et d'autres choses, mais pas sur la popularité.

MUI n'a pas toujours eu 60k étoiles, il les a obtenus parce qu'il a choisi la meilleure technologie (ou proche de), pas parce qu'il a choisi une technologie populaire.

Si le choix basé sur un vote populaire vise à être un projet plus accessible, ce sont des préoccupations commerciales, pas des améliorations de performances possibles. Un projet vit avec ou sans utilisateurs. Il meurt avec de mauvais choix. Je pense qu'il y a tellement de dictons à ce sujet et lire "ce n'est pas assez populaire, donc c'est un mauvais choix" sonne beaucoup de cloches.

Les gens utilisent un bon produit parce qu'il est bon, pas parce qu'il utilise une technologie populaire; MUI était une niche une fois, mais est devenu célèbre même s'il avait CSS-in-JS, qui n'a pas remporté le vote populaire btw. Il a juste des propriétés étonnantes et a fait les bons choix qui n'étaient pas basés sur la communauté actuelle, mais sur le DX et les performances réels.

Cela étant noté, je suis moi-même du côté du vote populaire; donc si quelque chose, je me sabote aussi. Je n'ai aucun gain personnel à avoir à choisir un produit moins populaire, je suis d'avis que la popularité ne doit pas être prise en compte _du tout_ quand on parle de révolutions et de changements. Veuillez reconsidérer certaines de ces options en fonction de ce qu'elles sont réellement, et non de ce que les gens pensent qu'elles sont en fonction de la popularité actuelle de l'option.

Pour finir, je suis reconnaissant de chaque pensée et de tout le temps consacré à MUI. J'ai fait des solutions étonnantes (malheureusement privées) en suivant toutes les normes, etc. au cours des deux dernières années, ce qui aurait pris des mois ou des années à faire seul! Je ne peux pas décrire suffisamment mon appréciation pour qu'elle transparaisse sur le papier 🙇‍♂️ 🙏 🙇‍♂️

Je suis curieux de savoir si Compilé est même une option et comment cela fonctionnerait avec des adaptateurs et autres. Je pense que l'approche compilée:

Compiled compile votre CSS dans JS au moment de la construction en analysant statiquement votre code, puis en le transformant en composants compilés. Tout ce dont nous avons besoin pour utiliser le composant est inclus avec lui dans le bundle JavaScript.

est un chemin à considérer, étant donné la contrainte de compilation 'css at runtime'.

Je dis ceci en tant que mainteneur d'Emotion - Compilé est génial. Ou plutôt - c'est peut-être dans le futur, c'est un truc très excitant mais c'est encore assez tôt dans l'expérimentation. Je doute fortement que MUI puisse l'accepter à ce stade.

Corrigez-moi si je me trompe mais compilé implique d'avoir une configuration ce qui signifie qu'il serait obligatoire d'avoir un fichier de configuration pour MUI même sans utiliser de styles personnalisés.

Je détesterais être obligé de créer une configuration juste pour utiliser MUI. Sur une note latérale: ne serait-ce pas difficile à utiliser dans des bootstrappers avisés comme Create React App?

@Andarist Je suis entièrement d'accord. Je suggérerais de démarrer une collaboration ou au moins d'envisager de participer au développement de la bibliothèque. Je me demande où cela pourrait mener à l'avenir! : eyes: Je pense que quelque chose comme compilé - comme vous le dites - dans le futur sera génial. Ce serait génial d'avoir plus de grands esprits se réunir pour faire quelque chose de remarquable.

@shilangyu Je ne suis pas sûr de ce que vous sous-entendez, car il me manque peut-être quelque chose. Je dirai donc simplement que la page d'accueil de compiled a ceci à dire à ce sujet:

Migrez vers une réalité sans configuration

Les API que nous aimons sont toutes là pour la balade - accessoires CSS et noms de classes aussi! Nos consommateurs n'ont même pas besoin de changer la façon dont ils consomment nos composants, poursuivant l'histoire de zéro config dont ils n'ont pas besoin pour configurer leur bundler, ni de configurer des éléments spécifiques pour le rendu côté serveur. Cela fonctionne juste.

Juste le commencement

Avec zéro configuration prête à l'emploi aujourd'hui, nous n'oublions pas à quoi pourrait ressembler demain. Avec la possibilité d'extraction CSS facultative, la transformation du CSS en une forme atomique et même la possibilité d'utiliser les données CSS pour l'analyse dans notre base de code, nous pensons à un avenir passionnant.

@MathiasKandelborg
J'ai parcouru https://compiledcssinjs.com/ . N'est-il pas toujours en cours d'exécution css-in-js?
Il crée des classes css au moment de la construction mais il applique ce style (crée une balise de style avec les classes css générées au moment de la construction) avec la balise <CC>...</CC> au moment de l'exécution.
Si c'est aussi rapide que d'utiliser simplement du css pur, c'est vraiment l'avenir (car il utilise des variables css). Merci d'avoir partagé
Je me demande à quel point il est plus rapide que Emotion.

Qu'en est-il d'une véritable bibliothèque à exécution nulle? Je n'ai vu personne parler de linaria.

Ce que nous n'avons pas inclus dans les exigences, c'est que toute solution doit être sans configuration du point de vue des consommateurs Material-UI. Si j'ai compris les solutions à exécution nulle, elles génèrent du CSS au moment de la compilation. Ne dois-je pas configurer mon bundler pour l'inclure correctement?

Ainsi, même si le temps d'exécution nul est probablement la solution la plus rapide, elle nécessite également une attention particulière. Avoir une solution sans configuration qui peut être configurée pour fonctionner avec un temps d'exécution nul serait idéal, je suppose.

Ainsi, même si le temps d'exécution nul est probablement la solution la plus rapide, elle nécessite également une attention particulière. Avoir une solution sans configuration qui peut être configurée pour fonctionner avec un temps d'exécution nul serait idéal, je suppose.

Je ne peux pas vraiment dire sur l'état actuel de Compiled mais j'en ai parlé plusieurs fois avec le responsable et c'est grosso modo le plan - l'idée est de maintenir le support pour les API Emotion & Styled Components, donc l'optimisation du code écrit devrait simplement être une question de modifier les importations et inclure un plugin de transformation ou un chargeur de pack Web. Bien sûr, il ne gérera pas tout le code qui peut être éventuellement écrit (JS est sauvage), mais il devrait être capable de gérer du code écrit de manière raisonnable. S'il ne parvient pas à compiler quelque chose, le fichier. Il lancera simplement - en forçant quelqu'un à abandonner son utilisation ou en réécrivant une partie particulière du code pour faciliter l'analyse statique.

Donc, pour résumer, si vous optez pour 0config Emotion (ou Styled Components), il devrait être possible d'adapter Compiled comme une optimisation optionnelle à l'avenir (si le projet parvient à tenir ses promesses)

@ ko-toss Je pense qu'il se compile dans le composant stylisé au moment de la construction. Lors de l'exécution, les styles du composant sont ensuite déplacés à leur juste place.

Comme on dit sur la page Web:

Tout ce dont nous avons besoin pour utiliser le composant est inclus avec lui dans le bundle JavaScript.

Nous prenons votre code initial dans toute sa splendeur:

import { styled } from '@compiled/css-in-js';

export const ColoredText = styled.span`
  color: #ff5630;
`;

Et puis transformez-le en un composant compilé:

...
...

Ce qui, au moment de l'exécution, déplacera les styles vers la tête du document.

Ce type de transformation nous permet de livrer votre composant à n'importe quel consommateur, sans qu'il ait besoin de configurer / paramétrer son outillage. Importez et partez. Ceci est puissant et, plus important encore, exactement le même que le CSS actuel dans les bibliothèques JS - avec une prise.

Le CSS ne peut pas être généré au moment de l'exécution.

Avoir une solution sans configuration qui peut être configurée pour fonctionner avec un temps d'exécution nul serait idéal, je suppose.

Je pense que vous frappez le clou sur la tête. Il serait utopique de faire soudainement ce rêve avec tendresse .

Il y a quelques idées à explorer et peut-être une collaboration à avoir. Certains codes et concepts me sont un peu étrangers, je ne suis donc pas en mesure d'entrer dans de nombreux détails. Voici quelques-unes des choses qui me passionnent:

• Analyse statique - c'est une grande. Imaginez simplement obtenir les données sur la façon dont vous utilisez une solution de style, obtenir des recommandations basées sur la règle X, la convention ou la spécification, et être montré où vous pouvez optimiser
• Zero config - même si je donnerais la priorité à plus de liberté en faveur de la paresse (installation d'un plugin pour x bundler)
• CSS-in-JSS en CSS pur, extrayant essentiellement les styles au moment de la compilation pour les inclure statiquement, pas besoin d'un runtime.

En ce qui concerne le support IE11, que pensez-vous des statistiques? Je suis sûr que c'est une chose parfaitement viable à faire. Edge est désormais basé sur le chrome, et la plupart des entreprises devraient opter pour le changement lorsque MS arrête enfin la

Ce serait bien d'avoir la possibilité de ne pas prendre en charge IE11. Ce n'est plus la norme de l'industrie et sera obsolète. C'est une question de temps, et le support par défaut de choses étonnantes comme MUI retarde probablement le changement.

Ce serait bien d'avoir la possibilité de ne pas prendre en charge IE11.

Voir https://github.com/mui-org/material-ui/issues/14420 pour cela.

Nous ne prévoyons pas d'abandonner complètement la prise en charge d'IE. La version par défaut ne ciblera probablement pas IE 11 dans la v5 mais nous ne pouvons pas choisir une solution qui ne fonctionnera pas du tout dans IE 11. Ou plutôt ce devrait être une solution que nous pouvons échanger au moment de la construction et produire la même chose production.

Ceci me rend heureux.

y a-t-il un mod de code pour convertir le jss existant en style / émotion je me demande?

Bonjour à tous. Je profite de l'occasion pour m'intéresser à cette discussion.

Dans la version actuelle, Material UI fait un usage intensif de withStyles HOC sans aucun style dynamique (le style étant une fonction qui dépend des accessoires), qui utilise en interne makeStyles . Les performances de makeStyles (sans accessoires dynamiques) sont assez remarquables et Material UI pourrait même être plus rapide s'il l'utilisait directement, au lieu de withStyles , ce qui crée un wrapper inutile.

J'ai créé un benchmark à partir de ce benchmark , et je l'ai déployé sur Vercel, afin que tout le code soit compilé avec les indicateurs de production activés. Le benchmark rend les cartes en utilisant différents CSS dans les bibliothèques JSS. Voici les liens:

Pour 100 cartes :

• makeStyles : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=mui-make-styles&cards=100
• emotion : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=emotion-styled&cards=100
• styled-components : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=styled-components&cards=100

Pour 500 cartes :

• makeStyles : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=mui-make-styles&cards=500
• emotion : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=emotion-styled&cards=500
• styled-components : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=styled-components&cards=500

Pour 2500 cartes :

• makeStyles : https://csb-5z6e2-fqtfkzcrk.vercel.app/?cases=mui-make-styles&cards=2500
• emotion : https://csb-5z6e2-fqtfkzcrk.vercel.app/?cases=emotion-styled&cards=2500
• styled-components : https://csb-5z6e2-fqtfkzcrk.vercel.app/?cases=styled-components&cards=2500

Dans l'ensemble, les performances de emotion et styled-components sont très similaires. Cependant, makeStyles semble globalement 6-8x plus rapide pour les mises à jour.

La différence est suffisamment importante, surtout lorsque nous effectuons un rendu sur des appareils à faible consommation, tels que nos téléphones ... et il y a beaucoup de téléphones de merde là-bas.

Tout cela pour dire que je suis inquiet de la migration du matériel et de l'utilisation de emotion par défaut, ce qui réduira les performances de (ce n'est pas vrai, cela dépend du composant; plus il est complexe, moins il y aura de différence).

Quelques questions et matière à réflexion:

• Le DX vaut-il vraiment le compromis UX? Même le DX est discutable car beaucoup préfèrent makeStyles
• Le problème avec makeStyles doit être lié aux styles dynamiques qui semblent pouvoir être résolus en implémentant un identifiant de cache déterministe. Actuellement, chaque instance de composant obtient son propre identifiant pour les accessoires dynamiques, même si les accessoires et les styles de sortie sont identiques, ce qui entraîne une surcharge d'exécution, de nombreuses balises de style dans la tête et une diminution des performances SSR. Cela semble réparable en utilisant une stratégie de hachage pour les styles dynamiques, tout comme de nombreux autres CSS dans les bibliothèques JS le font. En relation: https://github.com/mui-org/material-ui/pull/16858
• Y a-t-il place à l'amélioration sur emotion et styled-components pour se rapprocher, ou même être meilleur que makeStyles ?
• Material UI prendra-t-il en charge un adaptateur de moteur JSS officiel afin que les développeurs puissent le choisir pour plus de performances?

Je peux vivre avec une petite perte de performance.

Pas une perte de performance de 300%, pas à n'importe quel prix. 😅

@satazor merci d'avoir exploré cela. Nous avons fait un test de performance lourd avant de commencer cet effort, voir PR https://github.com/mui-org/material-ui/pull/22173 pour plus de détails (nous l'avons fait sur le composant ListItem) et la différence de performance était à la plupart 10% pour le rendu des instances x1000, en mode production .

https://deploy-preview-22173--material-ui.netlify.app/performance/list-raw/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-mui/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-styled/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-styled-wrapper/

• Copié de https://github.com/mui-org/material-ui/pull/22173#issuecomment -673486269

Sur cette base, nous avons décidé d'ignorer cette différence, en raison des avantages que nous en tirerions (accessoires dynamiques prêts à l'emploi, API stylée déjà utilisée par un grand pourcentage des développeurs, etc.) - le résumé complet peut être trouvé dans le Description PR :))

Je ne sais pas ce qui se passe sur vos benchmarks, mais 3-5x me semble trop, cela me fait me demander pourquoi quelqu'un utiliserait emotion / styled-compoenents si c'était le cas .. Nous pouvons essayer pour voir où est la différence entre les deux benchmarks, au cas où il nous manquerait quelque chose. De plus, faire des benchmarks sur un vrai composant MUI serait beaucoup mieux à mon avis, donc nous obtiendrions des chiffres plus réalistes, alors faites-moi savoir si vous voulez explorer plus de ce côté. Le PR que j'ai lié est un bon point de départ.

Merci pour la réponse @mnajdova. Vous avez raison, tester sur un composant Mui serait plus réaliste. Ce qui se passe probablement, c'est que le code Mui pour les composants List est le facteur de lenteur prédominant et que la différence entre eux (~ 30 ms) est la différence de temps de rendu réelle associée aux styles. Je vais prendre le code de ce PR et l'ajouter au benchmark, pour voir les résultats.

Cela importera-t-il à la fin? Probablement pas, mais cela dépend de l'application. La différence de performance entre les composants Mui actuels et ceux stylisés augmentera à mesure que le code de rendu lui-même sera plus simple. Par exemple, je m'attends à voir des différences accrues sur les composants Icône ou Typographie, mais une diminution des différences pour les cartes. Cela dépend donc vraiment de l'application et de la quantité de composants de chaque type que l'application utilise.

ce qui réduira les performances de rendu de l'interface utilisateur matérielle et des sites qui l'utilisent d'un facteur 3-5x.

Vous avez créé une référence qui a ce facteur. Il ne s'ensuit pas que chaque composant affichera cette diminution. Veuillez éviter de sauter aux conclusions car ces informations trompeuses se propagent très facilement à partir d'un problème aussi visible.

En utilisant l'extension devtools, j'ai vu 140 ms pour un montage avec émotion contre 120 ms pour un montage avec makeStyles.

Vous avez créé une référence qui a ce facteur. Il ne s'ensuit pas que chaque composant affichera cette diminution. Veuillez éviter de sauter aux conclusions car ces informations trompeuses se propagent très facilement à partir d'un problème aussi visible.

Vous avez raison, voir mon commentaire précédent.

Vous avez créé une référence qui a ce facteur. Il ne s'ensuit pas que chaque composant affichera cette diminution. Veuillez éviter de sauter aux conclusions car ces informations trompeuses se propagent très facilement à partir d'un problème aussi visible.

En utilisant l'extension devtools, j'ai vu 140 ms pour un montage avec émotion contre 120 ms pour un montage avec makeStyles.

J'ai mis à jour le benchmark pour utiliser actualDuration au lieu de baseDuration , nous devrions donc maintenant voir les valeurs plus en ligne avec ce qui est affiché dans le profileur devtools. Le baseDuration mesure le temps sans mémorisation, tandis que actualDuration est le contraire. Veuillez noter que ce changement n'affecte que les performances de rendu, et maintenant je vois makeStyles 6-8x plus rapide pour les rendus, ce qui signifie qu'il a une meilleure mise en cache / mémorisation? Cependant, je ne comprends pas les valeurs que vous voyez. Pouvez-vous essayer avec les liens mis à jour?

@satazor Je ne pense pas que vos cas de test soient équivalents. Nous devrions être bons.

Quelques changements que vous pouvez essayer de comprendre et qui réduiront la différence de performances:

• Le montage de composants de réaction a un coût, en particulier lors du rendu d'un grand nombre d'entre eux. makeStyles utilise div directement tandis que emotion / sc crée de nouveaux composants. Dans notre tableau de référence, j'ai constaté que chaque composant d'addition ajoute le temps de rendu de base, donc si 3 niveaux de composants => x3 (ou pourquoi <MenuItem> est presque x10 plus lent qu'un <li> ).
• Votre démo avec makeStyles crée une seule feuille de style, contrairement à emotion / sc. Essayez d'utiliser une seule feuille de style avec des sélecteurs CSS pour cibler les éléments dans chaque conteneur de carte. Ou faites le contraire, décomposez la feuille de style makeStyles principale en plusieurs, une par élément.

En effet, @oliviertassinari. Il semble que les performances à venir avec les composants émotionnels / stylisés soient davantage dans le facteur 1,5x-2x max, même pour des composants simples, tels que Typography , que j'ai implémentés ici: https://codesandbox.io/ s / css-in-js-comparaison-fourchue-lr3sr? file = / src / components / EmotionTypography.js.

Vérifiez la version de production et le benchmark sur: https://csb-lr3sr-7lp24bj5l.vercel.app/

makeStyles est 1,5 à 2 fois plus rapide sur le montage et 3 à 4 fois plus rapide sur les rerenders. C'est potentiellement quelque chose à surveiller, mais je suppose que l'écart sera beaucoup plus petit pour les composants plus complexes.

Donc, en conclusion, je ne suis plus si inquiet de la performance et j'ai hâte de voir à quoi ressemblera cet effort.

@mnajdova Voici la version de production pour le test List: https://csb-lr3sr-3zi42510w.vercel.app/?components=1000 , copié du PR que vous avez mentionné. Lien Codesandbox: https://codesandbox.io/s/css-in-js-comparison-forked-6s4nl

makeStyles semble 1,7x plus rapide au montage et 2,2x plus rapide au rendu. Je n'obtiens pas la différence de 10% que vous voyez. Est-ce que je fais quelque chose de mal?

@satazor Intéressant, merci de l'avoir rassemblé. J'ai utilisé ce benchmark avec # 22435 pour comparer les performances de

import Slider from '@material-ui/core/Slider';

vs (émotion).

import SliderStyled from '@material-ui/lab/SliderStyled';

vs (composants stylisés).

import SliderStyled from '@material-ui/lab/SliderStyled';

À ce stade, il est difficile de dire pourquoi c'est plus lent. Le goulot d'étranglement n'est peut-être pas sur les styles. Et sachez que je l'ai exécuté en mode dev ⚠️!

J'ai ajouté deux nouvelles pages pour avoir un aperçu des performances de la version émotion WIP du Slider:

• https://deploy-preview-22435--material-ui.netlify.app/performance/slider-emotion/
• https://deploy-preview-22435--material-ui.netlify.app/performance/slider-jss/

Une fois construites pour la production, les statistiques semblent être similaires à https://github.com/mui-org/material-ui/issues/22342#issuecomment -697540546, c'est environ x1.6 plus lent (mais CSS est entièrement dynamique). A noter que vous pouvez jouer avec la version émotion WIP avec:

• émotion : https://codesandbox.io/s/headless-shadow-fn41t?file=/package.json

• styled-components : https://codesandbox.io/s/preact-material-ui-test-forked-lum1y?file=/src/index.tsx @mnajdova Pour sc, j'ai dû utiliser le colis, je ne pouvais pas utiliser Modèle de l'ARC.

Notez également que nous savons que nous pourrions rendre la version actuelle de JSS x1.1 plus rapide en utilisant makeStyles au lieu de withStyles: # 15023.

@oliviertassinari en mode prod, les choses deviennent un peu plus rapides, mais je suppose que les différences restent là. Vous pouvez cliquer sur déployer> vercel sur le bac à sable de code pour déployer rapidement avec les indicateurs de construction de production.

En regardant comment makeStyles est implémenté, je vois comment c'est plus rapide lorsque vous utilisez simplement des styles statiques :

1. Sur chaque montage, attach est appelé.
2. S'il s'agit de la première instance de ce type de composant, stylesCreator.create est appelé, qui à son tour appelle fn spécifié dans makeStyles(fn) .
3. Sur toutes les autres instances, stylesCreator.create est ignoré car le nombre de références est> 0.

Pour les rediffuseurs:

1. Sur chaque rendu, attach est appelé.
2. Ensuite, stylesCreator.create est ignoré car le nombre de références est> 0, donc aucun travail n'est effectué.

Veuillez noter que si des styles dynamiques sont en jeu, les feuilles auraient été mises à jour ici , à chaque montage et rendu.

Au contraire, styled-components et emotion semblent exécuter nos fonctions de style sur chaque instance de composant, ce qui entraîne plus de cycles de processeur et de contre-pression de la mémoire. Je pensais qu'ils pourraient en quelque sorte faire un cache multi-mémorisation basé sur une combinaison d'accessoires, mais cela supposerait que les fonctions de style soient pures, ce qui pourrait ne pas être le cas, considérez:

     const someContext = useContext(FooContext);

    return <div css={ { paddingTop: someContext.padding(1) } }>;

Si mes hypothèses sont justes, il sera très difficile d'atteindre le niveau de performance de makeStyles pour la génération de styles statiques, car la façon dont cela fonctionne et la façon dont l'API est conçue permet des optimisations que styled ou css API ne peut pas.

Je vois quelques directions possibles que nous pourrions explorer:

• Dans la description du numéro initial, nous n'avons évalué les performances qu'avec le support dynamique de Material-UI. Nous pourrions ajouter une entrée pour le cas statique (ce qu'utilise la v4). Nous pourrions également avoir un cas pour react-jss static & dynamic. Cela devrait nous aider à comprendre la portée des options de moteur de style disponibles.
• Nous pouvons rechercher où se trouve le goulot d'étranglement. Nous pourrions imaginer avoir un adaptateur pour jss, comme nous l'avons fait pour les composants stylisés, et voir si les performances sont meilleures. Cela devrait être bien pire avec la version dynamique de JSS, mais nous pourrions le comparer avec la version statique. Peut-être que cela vient de l'abstraction sans style.
• On pourrait considérer le ralentissement comme un prix qui vaut la peine d'être dépensé pour débloquer des styles dynamiques et sans style. Que si vous souhaitez afficher une longue liste, vous utiliserez la virtualisation ou en vous appuyant sur des sélecteurs CSS imbriqués.
  L'émotion et les composants stylisés se sont avérés être suffisamment flexibles et rapides par l'industrie, tout comme React.

Si d'une manière ou d' emotion autre useCss hook comme il a été demandé dans https://github.com/emotion-js/emotion/issues/1321 et https://github.com/emotion- js / emotion / issues / 1853 , nous pourrions conserver makeStyles API et par conséquent, les avantages du "CSS statique". Cependant, nous continuerions à utiliser du CSS statique partout, pour améliorer les performances, ce qui n'est pas si «propre» mais c'est ce que nous faisons déjà dans la v4.

En fait, avec l'API ClassNames , je pense que nous pourrions faire un portage de withStyles dès maintenant qui conserverait les avantages de la performance CSS statique et la bonne performance du CSS dynamique que l'émotion a. Si const css = useCss() existait, alors il serait aussi simple de créer un port API useStyles .

Les principaux avantages de garder l'API withStyles + makeStyles qui utilise l'émotion sous le capot sont:

• La migration que le matériel doit faire est pratiquement nulle, nous aurions juste besoin de faire le portage de ces 2 fonctions.
• Les utilisateurs qui utilisent déjà withStyles et makeStyles dehors de l'interface utilisateur matérielle n'ont pas besoin de migrer du tout. Ils bénéficieraient gratuitement de performances améliorées pour le CSS dynamique.
• Aucune logique supplémentaire n'est nécessaire pour conserver l'API CSS classes +. Avec styled nous aurions besoin de créer les className globaux
• Dans cette stratégie, useCss est notre fonction d'adaptateur pour CSS dans les solutions JS, au lieu de styled .
• Pour prendre en charge d'autres CSS dans les solutions JS, ils devraient fournir un hook useCss ou similaire. Idéalement, nous pourrions faire un alias webpack / babel pour les changer, tout comme styled .

Nous avons exploré plus en détail le problème des performances sur https://twitter.com/olivtassinari/status/1309247827839680512. Je pense que nous pouvons avancer tel quel. Pour les équipes qui se soucient profondément de la performance, elles peuvent opter pour les composants sans style, ils offrent de meilleures performances. Pour les autres, comme la plupart de l'industrie, l'émotion et les composants stylisés sont assez bons.

• natif: 7,71 ms
• v5 sans style: 20,89 ms
• v4: 29,93 ms
• v5: 37,37 ms
• antd: 53,48 ms
• chakra: 64.67ms

https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js…

Désolé de vous déranger ici si tard dans la discussion mais je suis un peu surpris que vous ne regardiez pas de près

Leur liste répondait exactement à vos exigences:

• Serveur et client de travaux
• Support CSS complet, pas de compromis en termes de puissance
• Taille d'exécution de seulement 3 Ko (gzippé, à partir de 12 Ko)
• Isolation complète: sélecteurs, animations, images clés
• Préfixe de fournisseur CSS intégré
• Transpilation très rapide, minimale et efficace (voir ci-dessous)
• Injection CSS d'exécution haute performance sans rendu de serveur
• À l'épreuve du temps: équivalent au "Shadow CSS" rendu par le serveur
• Prise en charge des cartes sources
• Prise en charge des styles et des thèmes dynamiques
• Prétraitement CSS via des plugins

Je ferais attention au fait qu'il s'agit presque d'une API standard CSS shadow . Ainsi, en supprimant l'attribut jsx vous êtes prêt à passer à l'avenir aux composants Web qui fonctionnent déjà dans les navigateurs normaux BTW.

Oui, je sais que ce n'est peut-être pas le plus populaire.
Mais je veux juste souligner que Flash était très populaire il y a quelques années.
Mais il a séché à la fin, n'étant pas conforme aux normes Web, et nous avons maintenant des SVG.
Pour mémoire, la norme SVG était présente depuis longtemps lorsque Flash dominait l'industrie.
Je considère simplement les événements historiques comme de bonnes leçons et j'essaierais de repérer le schéma selon lequel la popularité est le dernier indicateur de la pérennité et de la pérennité.

@mifrej J'ai personnellement eu une mauvaise expérience avec: https://github.com/vercel/styled-jsx/issues/142.

Nous avons exploré plus en détail le problème des performances sur https://twitter.com/olivtassinari/status/1309247827839680512. Je pense que nous pouvons avancer tel quel. Pour les équipes qui se soucient profondément de la performance, elles peuvent opter pour les composants sans style, ils offrent de meilleures performances. Pour les autres, comme la plupart de l'industrie, l'émotion et les composants stylisés sont assez bons.

• natif: 7,71 ms
• v5 sans style: 20,89 ms
• v4: 29,93 ms
• v5: 37,37 ms
• antd: 53,48 ms
• chakra: 64.67ms

https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js…

Avez-vous essayé les plugins babel pour les composants émotionnels / stylisés? Cela a-t-il fait une différence dans les horaires?

Que signifierait un changement par rapport à JSS pour l'accessoire classes disponible sur les composants MUI existants? À quoi ressemblerait une migration v5 pour les utilisateurs existants qui exploitent largement cet accessoire?

Nous envisageons que les gens utilisent à la place la syntaxe suivante: https://next.material-ui.com/components/slider-styled/#unstyled -slider les classes sont essentiellement remplacées par les sélecteurs de classe disponibles pour chaque emplacement du composant. Vous pouvez également jeter un œil sur l'exemple de personnalisation: https://next.material-ui.com/components/slider-styled/#customized -sliders

Comme avantage, vous pouvez simplement utiliser les accessoires et appliquer des styles dynamiques basés sur eux.

Nous envisageons que les gens utilisent à la place la syntaxe suivante: https://next.material-ui.com/components/slider-styled/#unstyled -slider les classes sont essentiellement remplacées par les sélecteurs de classe disponibles pour chaque emplacement du composant. Vous pouvez également jeter un œil sur l'exemple de personnalisation: https://next.material-ui.com/components/slider-styled/#customized -sliders

Comme avantage, vous pouvez simplement utiliser les accessoires et appliquer des styles dynamiques basés sur eux.

J'adore cette API! Un changement très bienvenu, et il semble vraiment bien jouer avec les moteurs de style.

Avant v5 , si je me souviens bien, le compilateur JSS modifierait ces noms de classe et vous ne pouviez pas les cibler de manière fiable? Mais maintenant, il semble qu'ils seront exposés à des fins de ciblage? 🙌 En outre, il y avait un problème de priorité CSS. Et ces préoccupations sont résolues avec cette nouvelle approche? Merci d'avoir travaillé sur ce refactor!

@ConAntonakos exactement ces classes peuvent être ciblées à la fois pour les versions non stylisées et stylisées des composants. L'ordre dans lequel le style est invoqué garantit que les nouveaux styles l'emporteront, bien sûr si la spécificité est la même :)

Avant la v5, si je me souviens bien, le compilateur JSS modifiait ces noms de classe et vous ne pouviez pas les cibler de manière fiable?

Vous pouvez déjà les cibler dans la v4.

les classes sont essentiellement remplacées par les sélecteurs de classe disponibles pour chaque emplacement du composant.

Sont-ils «essentiellement» remplacés ou réellement remplacés? Je pensais que nous avions décidé de conserver une partie de l'ancienne API pour réduire le nombre de changements de rupture.

Je pensais que nous avions décidé de conserver une partie de l'ancienne API pour réduire le nombre de changements de rupture.

Nous avons décidé de conserver la même API pour les remplacements theme.components.overrides - définis dans le thème fonctionnent de la même manière.

Pour les remplacements d'instances, nous avons maintenant l'approche styled avec les sélecteurs de classe, c'est pourquoi la propriété classes n'est plus prise en charge. Les développeurs peuvent faire de même de manière plus flexible maintenant.

Les développeurs peuvent faire de même de manière plus flexible maintenant.

Cela semble être un problème mineur, car il existe une alternative, mais le coût de la migration est énorme. À quoi ressemble le plan de migration?

Les développeurs peuvent toujours utiliser les remplacements de thème, s'ils déplacent simplement les remplacements d'instance vers un ThemeProvider imbriqué, ils n'auraient pas du tout besoin de changer les styles définis, car la structure entre ces deux est la même (ce n'est pas parfait , mais s'ils veulent une mise à niveau incrémentielle, c'est une voie à suivre)

Par contre, nous pouvons toujours supporter facilement les prop classes, mais dans ce cas nous ne pouvons pas garantir si la combinaison classes + styled est utilisée sur le même composant que l'on devrait gagner. Doit-on rétroporter le support des classes au moins sur la version stylisée des composants?

J'ai peut-être manqué cela tout au long de ce fil - une autre question liée à ma question classes . Quelle sorte de garanties de «justesse» pourrait-il y avoir?

Par exemple, j'ai édité l'exemple du curseur:

const StyledSlider = styled(SliderUnstyled)`
  & .MuiSlider-raill {
    display: block;
    position: absolute;
    width: 100%;
    height: 2px;
    border-radius: 1px;
    background-color: currentColor;
    opacity: 0.38;
  }
)

Vous remarquerez que j'ai accidentellement mal orthographié MuiSlider-rail . Auparavant, avec classes il y aurait quelque chose comme classes.rail , et si je mal orthographiais la propriété, j'obtiendrais un avertissement d'exécution que classes.raill n'existe pas dans la feuille de style. Je crois que le thème avait le même comportement?

Les avantages de l'API classes auxquels je peux penser:

1. Edge contre les sélecteurs CSS globaux qui fuient entre les enfants: par exemple In .css-e7ylz8 .MuiTreeItem-group . Vous n'avez aucune garantie que le composant n'applique pas le style sur un composant enfant (pas l'effet que vous attendiez, une surprise!). Probablement OK pour nos composants car nous ferons attention.
2. Faites de la gestion des portails une évidence: https://material-ui.com/guides/interoperability/#portals. Pour styliser l'info-bulle, nous devrons styliser le composant popper, pas la racine comme nous l'avons fait avec le curseur.
3. La syntaxe $styleRule avertit si la règle de style n'est pas définie.
4. Autorise la personnalisation des noms de classe utilisés. La solution actuelle est d'utiliser le prop componentsProps . Nous fusionnons les noms de classe.

Il existe un monde alternatif où nous pourrions:

une. Permet de résoudre 1. et 3. avec des sélecteurs de composants stylisés .
b. Exposez l'API classes pour une compatibilité descendante.
c. Afin d'obtenir un fichier. et B. fonctionnant, nous aurions besoin d'aplatir la façon dont les styles du composant sont écrits en interne. x composant stylisé au lieu d'une racine stylisée. Mais ⚠️ avec l'implication de la perf.

Avons-nous vraiment besoin de faire cela?

J'ai regardé l'historique de la propriété classes de jQuery UI. J'ai pu trouver deux problèmes: https://bugs.jqueryui.com/ticket/7053 , https://bugs.jqueryui.com/ticket/8928 et le commit initial: https://github.com/jquery/jquery- ui / commit / c192d4086d9bbaf09d5f870857af30c60a427e22.

Nous envisageons que les gens utilisent à la place la syntaxe suivante: https://next.material-ui.com/components/slider-styled/#unstyled -slider les classes sont essentiellement remplacées par les sélecteurs de classe disponibles pour chaque emplacement du composant. Vous pouvez également jeter un œil sur l'exemple de personnalisation: https://next.material-ui.com/components/slider-styled/#customized -sliders

Comme avantage, vous pouvez simplement utiliser les accessoires et appliquer des styles dynamiques basés sur eux.

Wow, c'est la meilleure chose qui soit.
Les composants sans style ou sans tête seront la meilleure chose pour la personnalisation (l'un des critiques à propos de mui, je pense).
Ce n'est pas une petite chose à réparer imo, mais un plus pour MUI.

PS: je me souviens avoir eu du mal à personnaliser certains composants dans le passé
PS2: Avez-vous jeté un œil sur https://github.com/modulz/stitches ?

Vous remarquerez que j'ai accidentellement mal orthographié MuiSlider-rail. Auparavant, avec les classes, il y avait quelque chose comme classes.rail, et si je mal orthographiais la propriété, j'obtiendrais un avertissement d'exécution indiquant que classes.raill n'existe pas dans la feuille de style. Je crois que le thème avait le même comportement?

@ianschmitz en plus de l'option @oliviertassinari suggérée pour l'utilisation des sélecteurs de composants stylisés, nous avons une autre option, qui est d'exposer les constantes pour les classes que nous exposons. Peut-être quelque chose comme:

import { sliderClasses } from '@material-ui/core/Slider';

const StyledSlider = styled(SliderUnstyled)`
  & .${sliderClasses.rail} {
    display: block;
    position: absolute;
    width: 100%;
    height: 2px;
    border-radius: 1px;
    background-color: currentColor;
    opacity: 0.38;
  }
)

Ce n'est pas la même chose que l'avertissement d'exécution classes.rail , mais devrait aider à éviter de mal orthographier les classes.

@mnajdova Nous pourrions également envisager un plugin eslint.

En ce qui concerne le support sur le prop classes - pour que nous puissions le faire de manière fiable, nous devrons créer des composants pour chaque partie (slot) du composant principal. Par exemple, pour le Slider , nous aurions besoin de créer des composants pour le rail, la voie, la marque, l'étiquette de marque, le pouce et l'étiquette de valeur. Cela nous permettra de spécifier les styles directement sur ces composants, au lieu d'utiliser des classes pour augmenter la spécificité. Ces changements peuvent être trouvés sur ce PR - https://github.com/mui-org/material-ui/pull/22893

Avec ces changements, nous avons créé un codeandbox, qui peut comparer les performances de ce nouveau composant Slider mis à jour par rapport à la v4, style natif, sans style, ainsi que deux autres bibliothèques concurrentes - https://codesandbox.io/s/ comparaison-de-curseur-avec-plusieurs-composants-2tytc? file = / package.json

Si nous comparons ces performances avec la performance d'avoir un seul composant et d'utiliser les sélecteurs de classes pour les parties de celui-ci - https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js nous remarquerons que l'ajout de composants par slot a une dégradation de 20% des performances 😢

Versions de production:

• Un composant - https://csb-jziv6-99lfgp8e6.vercel.app/
• Composant par emplacement - https://csb-2tytc-pz2xlac86.vercel.app/

Pour être honnête, je ne sais pas à ce stade s'il vaut mieux ajouter cette compatibilité descendante ou non.

S'agit-il de cas d'utilisation réels pour le support du classes ou est-ce juste pour faciliter la mise à niveau?
Sommes-nous d'accord avec une dégradation des performances de 20% uniquement pour faciliter le chemin de migration?
Y a-t-il une alternative que nous ne pouvons pas voir, qui nous aiderait à faire les deux sans payer le coût des performances?

@ianschmitz @ eps1lon @oliviertassinari et autres :) y a-t-il des réflexions à ce sujet?

Tant que nous pouvons définir et utiliser des thèmes et des styles avec TypeScript, cela ne me dérangerait pas de passer du temps à migrer par rapport à perdre 20% de performances

Je suis généralement curieux, et pardonnez-moi si je ne comprends pas la conception sous-jacente, mais classes était une API pour JSS? Si la conception de l'API passe de JSS à des composants stylisés, est-il judicieux de continuer à prendre en charge classes ?

S'agit-il de cas d'utilisation réels pour le support de classes ou est-ce juste pour faciliter la mise à niveau?
Sommes-nous d'accord avec une dégradation des performances de 20% uniquement pour faciliter le chemin de migration?
Y a-t-il une alternative que nous ne pouvons pas voir, qui nous aiderait à faire les deux sans payer le coût des performances?

Toutes mes excuses si j'ai manqué quelque chose avec l'API proposée, mais IMO, le cas d'utilisation que je vois le plus souvent au sein de notre organisation est l'abstraction du système de style sous-jacent utilisé par MUI. Oui, je suppose que classes est en quelque sorte une "API pour JSS" comme @ConAntonakos l'a mentionné, mais pour le consommateur, cela n'avait pas d'importance. En tant que consommateur, je pourrais utiliser la technologie CSS de préférence (y a-t-il des limitations aujourd'hui avec classes ?). Nous avons un certain nombre de produits utilisant une variété de:

• Fichiers CSS vanille
• SCSS
• JSS

selon les besoins et les préférences de ces équipes.

L'exportation des noms de classe aide si vous utilisez une certaine saveur de CSS-in-JS, mais que pensent ceux qui ne le sont pas?

RÉ. 20% de perf, je suis d'accord que ce n'est probablement pas un compromis acceptable. À la fin de la journée, vous devriez faire ce qu'il y a de mieux pour la majorité de la communauté. Offrant juste mes pensées 😄

Un souhait que je n'ai jamais eu, c'est que Material-ui soit compatible React-Native. De nombreux projets sont multi-plateformes de nos jours et avoir une solution de style unifiée offre de nombreux avantages pour les composants multi-plateformes. Nous avons fini par rouler le nôtre en utilisant material-ui sur le côté web et React-native-paper du côté natif et en standardisant sur l'API material-ui. Je serais intéressé de savoir si cette nouvelle solution de style rendra possible l'utilisation de (certains / tous) composants d'interface utilisateur matérielle sur react-native? Toute référence de fenêtre dans les composants serait évidemment un bloqueur, mais le style lui-même prend également en charge le natif, n'est-ce pas?

@mschipperheyn react -native n'est pour l'instant pas un objectif. C'est + 5% du potentiel d'utilisation (1 mois de croissance) et + 50% d'effort supplémentaire (une estimation). Le coût d'opportunité est vraiment élevé sans aucune direction évidente sur la façon de le monétiser (en dehors du modèle d'Ionic). De plus, sachez que le flutter semble avoir capturé une grande partie du public qui réagit aux cibles natives.

Maintenant que la v5 est en version alpha, existe-t-il une solution à ce problème? En particulier, la solution de style est-elle toujours basée sur JSS? Nous avons constaté des problèmes de performances importants liés à JSS, et nous attendons donc avec impatience une nouvelle solution.

@zzzev Ce n'est pas un problème en soi. C'est un fil RFC (Request for Comments).

Je me demande de quels problèmes de performances substantiels vous parlez et comment le fait de passer de JSS pourrait améliorer cela. Parce que d'après moi, si vous avez des problèmes de performances, ce ne sont probablement pas les styles mais la manière dont ils sont implémentés, c'est-à-dire que le même résultat pourrait être obtenu en écrivant les styles d'une autre manière, en utilisant moins de puissance de traitement.

À tout le moins, je ne parviens pas à comprendre comment le passage de JSS à Emotion (qui est montré dans ce fil de discussion pour avoir une certaine dégradation des performances) améliorerait quoi que ce soit.

Je crois comprendre que l'émotion affectera légèrement les performances des styles statiques et de bien meilleures performances de styles dynamiques - mais peut-être que ce n'est pas tout à fait vrai? Il y a beaucoup de nombres différents dans ce fil et il est difficile de se réconcilier en une seule image de la performance (et évidemment cela dépend beaucoup de la situation d'un individu).

Quand vous dites que nous devrions écrire les styles d'une manière différente, voulez-vous dire éviter les styles dynamiques? Ou y a-t-il d'autres bonnes pratiques que nous devrions envisager?

@zzzev Correct sur la première partie, pas tout à fait sur la seconde (sauf si vous comptez passer de non pris en charge à pris en charge comme un gain de performance infini 🙂).

L'émotion permet la prise en charge des styles dynamiques, au prix de performances modérément plus lentes pour l'électricité statique.

Je suis confus; n'y a-t-il pas des styles dynamiques dans les makeStyles actuels / v4? par exemple ce modèle

Je suis confus; n'y a-t-il pas des styles dynamiques dans les makeStyles actuels / v4? par exemple ce modèle

Il y a mais il y a un gros problème de performance connu. Mon équipe reste loin ATM

Je déteste juste le style des composants
jss est bon mais il y a quelques problèmes de débogage, de performances et encore des bogues non résolus tels que imbriqués comme &:after

c'est ma compilation de paquets pour react-native et react-native-web
https://www.npmjs.com/package/@material-native-ui/theme -provider

Je voudrais quelque chose comme ça (ça s'accumule sur RN et RNW)

Y a-t-il donc une conclusion sur la solution de style recommandée à utiliser avec Material UI v5? Il semble qu'il y ait une intention de s'éloigner de JSS sur lequel @material-ui/styles est actuellement construit. Ou @material-ui/styles sera refactorisé pour s'appuyer sur d'autres solutions de style comme styled-components place?

Y a-t-il donc une conclusion sur la solution de style recommandée à utiliser avec Material UI v5? Il semble qu'il y ait une intention de s'éloigner de JSS sur lequel @ material-ui / styles est actuellement construit. Ou @ material-ui / styles sera-t-il remanié pour s'appuyer sur d'autres solutions de style comme les composants stylisés?

@ matthewkwong2 nous n'adopterions pas le package @material-ui/styles pour le nouveau moteur stylé, il continuera à supporter jss. Dans la v5, il sera isolé du reste de la base de code et nous prévoyons de le supprimer dans la v6, afin de faciliter la transition vers le nouveau moteur de style.

Pour la v5, nous aurons de nouvelles pratiques de battement concernant la solution de style, comme le sx prop et l'utilitaire styled , nous travaillons toujours sur la documentation autour de cela.

De plus, les remplacements de thèmes et les variantes seront toujours pris en charge dans la v5.

Pour la v5, nous aurons de nouvelles pratiques de battement concernant la solution de style, comme le prop sx et l'utilitaire de style, nous travaillons toujours sur la documentation autour de cela.
De plus, les remplacements de thèmes et les variantes seront toujours pris en charge dans la v5.

Donc, si je comprends bien, pour le style des composants individuels, il est encouragé d'utiliser sx ou styled au lieu de makeStyles .

Mais qu'en est-il du thème (ie createMuiTheme )? Je crois que cette partie est également construite sur JSS, non? Quelle serait la manière recommandée de créer un thème (c'est-à-dire avec l'objectif principal de définir des styles globaux) maintenant?

Nous conservons toujours la même structure pour créer le thème, nous nous attendons simplement à ce que les valeurs des remplacements de composants et des variantes suivent la syntaxe des composants émotionnels / stylisés. Il n'y a aucun changement dans la façon dont le thème est créé, l'API est exactement la même, le même contexte de thème est également réutilisé pour le nouveau moteur de style. Est-ce que cela a du sens @ matthewkwong2 ?

@mschipperheyn react -native n'est pour l'instant pas un objectif. C'est + 5% du potentiel d'utilisation (1 mois de croissance) et + 50% d'effort supplémentaire (une estimation). Le coût d'opportunité est vraiment élevé. De plus, sachez que le flutter semble avoir capturé une grande partie du public qui réagit aux cibles natives.

Je ne veux pas nous emmener sur une trop grande tangente, mais j'aimerais revenir sur certaines de ces justifications.

• Dans le passé, lors de la création d'applications RN, l'une des choses les plus difficiles à gérer était la conception de matériaux. En fait, c'était un problème suffisamment important pour pouvoir décider de se donner la peine de créer une application mobile. J'entends que c'est un peu mieux avec une nouvelle bibliothèque prometteuse. Mais je doute que ce soit aussi prometteur que si MUI était dans le mix. Peut-être que c'est juste moi, mais je pourrais voir un MUI multiplateforme augmenter l'utilisation de RN. Je sais que ce n'est qu'une petite fraction de l'utilisation de react-dom, mais le web est énorme et react-dom domine les frameworks web modernes . Même si l'utilisation de React-Native est relativement petite, cela peut toujours être un bon nombre de personnes en tant qu'absolu qui l'utiliseraient. Un sondage auprès des utilisateurs actuels de MUI serait probablement une meilleure métrique que les statistiques npm.
• Je sais que je suis hors de propos, mais je n'achète pas tout à fait Flutter qui reprend React Native. Cette comparaison de trafic n'est pas vraiment un excellent moyen de comparer. Il est affecté par tant de facteurs de confusion (Flutter est plus récent, donc plus de gens connaissent déjà RN et n'ont pas besoin de référencer la documentation; La documentation de Flutter pourrait être plus utile pour re-référencer en augmentant son trafic; Une partie du trafic de lecture de documents de RN pourrait également être en cours à Expo à la place). Cette comparaison quelque peu erronée de
• JSS était l'un des plus gros problèmes (en fait peut - être

le passage à l'émotion a probablement éliminé 2/3 de la difficulté à faire fonctionner MUI en RN

Nous avons hâte de voir votre POC 😄

Nous avons hâte de voir votre POC 😄

J'adorerais jouer avec si j'ai une chance. Mais les gens ne prennent généralement pas la peine de créer des POC pour des choses pour lesquelles les responsables montrent un désintérêt. Il ne sert à rien de construire quelque chose quand l'atmosphère actuelle est qu'il finira probablement par être abandonné. C'est pourquoi je veux éviter de rejeter la valeur de RN ou la valeur de RN comme une possibilité pour l'avenir.

Deux questions:

1. Pouvez-vous utiliser la nouvelle solution de coiffage sans HOC? Pour ma part, j'adore l'API React hook que MUI a actuellement ... Je ne sais pas si la syntaxe stylisée est également un HOC sous le capot, mais cela battrait les efforts (un peu partout dans les bibliothèques React) pour s'éloigner des HOC.
2. La plupart des composants seront-ils toujours pris en charge par la plupart des composants classes (cela donnerait une flexibilité totale dans la solution de style que les utilisateurs peuvent utiliser)?

le fast-refresh est activé par défaut dans create-react-app v4 . devrions-nous ajouter la prise en charge de l'actualisation rapide comme nouvelle exigence?

Essayer ça avec Gatsby. Quand je fais import { Link } from '@material-ui/core' j'ai:

Can't resolve '@emotion/core' in 'node_modules/@material-ui/styled-engine'
File: node_modules/@material-ui/styled-engine/index.js

Can't resolve '@emotion/styled' in '/node_modules/@material-ui/styled-engine'
File: node_modules/@material-ui/styled-engine/index.js

Une fois changé en import Link from '@material-ui/core/Link' problème disparu.

Si j'installe @emotion/styled @emotion/core j'ai:

Impossible de résoudre «@ emotion / react» dans «/ node_modules / @ emotion / styled / dist»

Ensuite, j'installe @emotion/react .

Une erreur d'exécution survient.

Error: The `@emotion/core` package has been renamed to `@emotion/react`. Please import it like this `import { jsx } from '@emotion/react'`.
./node_modules/@emotion/core/dist/emotion-core.cjs.dev.js
node_modules/@emotion/core/dist/emotion-core.cjs.dev.js:3

Versions de package impliquées:

    "@emotion/core": "^11.0.0",
    "@emotion/react": "^11.0.0",
    "@emotion/styled": "^11.0.0",
    "@material-ui/core": "^5.0.0-alpha.15",
    "@material-ui/lab": "^5.0.0-alpha.15",

Installer les versions v10 des packages Emotion

Oh 11 est la "dernière" version maintenant, donc je pense que je dois mettre à jour ou documenter cela

Oh 11 est la "dernière" version maintenant, donc je pense que je dois mettre à jour ou documenter cela

Nous l'avons documenté via des plages de versions dans peerDependencies . Nous ne l'avons pas mentionné explicitement dans les instructions d'installation car nous prévoyons de le mettre à jour prochainement vers la v11.

Rappel amical qu'il s'agit d'un alpha et d'une émotion 11 vieux de quelques jours. En tant que premier adoptant, vous devez vous attendre à des aspérités.

Bonjour à tous, je suis nouveau ici, et je cherchais des solutions css matérielles-ui et suis venu à ce problème.
Juste en donnant mes 2 cents à ce sujet, j'aimerais suggérer Linaria https://github.com/callstack/linaria.
C'est une bibliothèque d'exécution zéro, avec une extraction css et des variables CSS comme accessoires React.

J'espère que cela aide sur cette RFC 😄.