Material-ui: [RFC] Migrer vers des composants de style

@kybarg Merci d'avoir ouvert ce problème ! Le CSS-in-JSS est un domaine mouvant, les choix que nous avons faits dans le passé peuvent ne plus être valides à mesure que les problèmes et les solutions changent.

Pourquoi pas des composants stylés dans le passé ?

Nous avons comparé les différentes solutions de style disponibles avant de sélectionner JSS.

Nous n'avons pas choisi de composants de style pour les raisons suivantes :

• Coût du prélèvement. css-in-js-perf-tests est une bonne ressource, les composants de style utilisent glamour en interne.
  
  
  
  • 126 ko décompressés sur 22 ko pour JSS
  
  
  • Le temps de la première peinture est plus lent. Comparez le temps de première peinture sur les démos équivalentes de https://github.com/MicheleBertoli/css-in-js , JSS fonctionne 40% mieux.
  
  
• L'exposition de className et de la puissance du sélecteur profond CSS permet une implémentation performante. Par exemple avec le <Grid /> : #6010.
• Aucune simultanéité de rendu côté serveur possible. Il s'appuie sur un singleton pour collecter les styles tandis que JSS instancie une nouvelle instance pour collecter les styles à chaque requête. La cuisson à la vapeur est vraiment limitée.

En fait, les composants stylés n'étaient même pas une chose (existante) lorsque @nathanmarks a commencé à s'éloigner du style en ligne.

Le tableau comparatif

Prend en charge le CSS global

Avec https://github.com/cssinjs/jss-global , vous pouvez écrire des choses comme

const styles = {
  '<strong i="35">@global</strong> body': {
    color: 'green'
  }
}

Facile à remplacer

Comment n'est-ce pas facile ? Côté Material-UI nous avons une table d'ordre d'injection prédéfinie. Sur le terrain de l'utilisateur, ils peuvent utiliser des aphrodisiaques qui implémentent une excellente API de remplacement d'aphrodite.

Aucun composant d'emballage

Nous n'avons aucun composant wrapper du côté Material-UI. Nous aurions pu utiliser withStyles mais nous ne le faisons pas pour des raisons de performances. Nous exposons ce composant d'ordre supérieur aux utilisateurs pour résumer l'implémentation du contexte.

Thématisation

Nous utilisons jss-theme-reactor en interne. JSS expose une API de bas niveau qui le rend possible.

Prise en charge de ReactNative

C'est un bon point, l'API react-with-styles est assez intéressante. C'est quelque chose que nous pourrions améliorer !

L'avenir

À l'avenir, je pense que la voie la plus prometteuse est d'avoir une API permettant de changer l'implémentation du style. Cela nous apporterait deux avantages :

• Material-UI est moins couplé à une solution de style
• Les utilisateurs utilisant styled-components / aphrodite/... de leur côté peuvent économiser l' overhead JSS utilisé en interne.

react-toolbox suit ce chemin . Ma seule préoccupation serait avec les frais généraux qu'il ajoute. Je veux dire, est-ce que ça vaut le coup ?

J'ajoute @kof et @mxstbr à la boucle.

@kybarg En fait, je ne suis pas sûr de bien comprendre ce que vous suggérez.
Nous n'utilisons pas react-jss comme le suggère votre question.

Quand vous dites nous, parlez-vous des utilisateurs ou de Material-UI ?

Mes points sont :

• styled-components est une bibliothèque de niveau beaucoup plus élevé que le noyau JSS, vous pouvez certainement l'utiliser dans votre couche d'application.
• Le tableau de comparaison ci-dessus concerne react-jss, pas JSS core et est une opinion subjective de Max. Ce n'est en partie pas vrai et en partie juste un regard d'une perspective spécifique que nous ne voyons pas dans le tableau.
• Nous travaillons sur le rendu dynamique des règles pour un style dynamique plus efficace, jss-theme-reactor fait déjà le travail en ce moment, c'est juste une question d'optimisation, ce qui n'est probablement pas très pertinent pour MUI.
• Ce que MUI utilise en interne devrait être totalement hors de propos pour l'utilisateur final. Tout ce qu'un utilisateur doit faire devrait être possible sans même savoir ce que MUI utilise en interne ou du moins sa syntaxe cssinjs plus ou moins régulière pour la thématisation.
• Nous devons obtenir les cas d'utilisation que MUI ne prend pas en charge pour le moment et les résoudre. Je suis toujours heureux d'aider le processus d'intégration et disponible sur gitter.
• Qu'est-ce que le support réactif natif de toute façon? N'est-ce pas juste un sous-ensemble de la plate-forme Web ? Si c'est le cas, cela devrait fonctionner, sinon faites-moi savoir ce que JSS doit être capable de faire pour prendre en charge react-native, voici le problème .

Ce tableau est en effet très subjectif et basé sur ma propre expérience. FWIW, styled-components fonctionne avec n'importe quelle bibliothèque de composants tiers :

import { Button } from 'material-ui'

const MyButton = styled(Button)`
  // Only these styles will be overridden
  background: red;
`

Cela fonctionne tant que les composants attachent le prop className en interne à un nœud DOM :

const MaterialUIButton = (props) => {
  /* ... */
  // As long as props.className is attached, the above usage will work
  return <button className={`bla ${props.className}`} />
}

Qu'est-ce que le support réactif natif de toute façon? N'est-ce pas juste un sous-ensemble de la plate-forme Web ?

Non, ce n'est pas si simple 😉 Ajouter du support à JSS ne devrait pas être difficile, car tout ce que vous avez à faire est de passer l'objet de style à StyleSheet.create() . Cela nécessite un peu plus d'efforts du côté styled-components pour que les chaînes CSS fonctionnent.

Je parle à @javivelasco depuis un moment maintenant et j'adore où il veut en venir avec react-toolbox . Son implémentation est incroyable, et j'aimerais voir toutes les bibliothèques de composants tiers l'adopter. Envoyez-lui un ping pour qu'il puisse partager ses idées ici !

Aucune simultanéité de rendu côté serveur possible. Il s'appuie sur un singleton pour collecter les styles tandis que JSS instancie une nouvelle instance pour collecter les styles à chaque requête. La cuisson à la vapeur est vraiment limitée.

Totalement sans rapport, pensez-vous commenter dans ce numéro avec vos idées pour une API qui permettrait que cela soit le cas ? Nous n'avons pas décidé de ce que nous allons faire, donc votre contribution serait très appréciée.

Salut, je me suis renseigné à ce sujet dans gitter. Juste pour avoir l'avis des autres, je le posterai ici aussi :

Je sais que material-ui _next_ est fortement investi dans une solution jss personnalisée.
Quelqu'un a-t-il découvert un avantage sérieux à utiliser jss par rapport aux composants stylés?

Bien que jss soit bon car il permet plusieurs modèles comme les décorateurs (injectstyles) et les plugins, je pense que l'approche directe des composants stylés est beaucoup plus propre car il n'y a pas besoin de décorateurs, de configuration personnalisée et de plugins car il n'en a pas besoin.

Dans styled-comp, chaque composant est déjà stylisé, il n'est donc pas nécessaire de passer des styles. et vous passez des accessoires qui peuvent être évalués pour produire un style différent
pas de configuration (createJss)
pas de plugins (préfixe)
pas de DSL JSON

Quelqu'un doit verrouiller ce fil.

@rainice jss n'a pas de décorateurs, un HOC est un détail d'implémentation de react-jss et n'est pas utilisé ici.

Pourquoi cela devrait-il être verrouillé ? C'est une discussion sensée OMI

Parce que le contenu basé sur l'utilisateur final ici (pas les responsables de la bibliothèque) est très superficiel et cela est compréhensible car ils n'ont pas lu une seule ligne de code derrière ce qu'ils utilisent.

Étant donné que le choix de la solution de style a été longuement discuté , que la justification de la décision a été documentée et que le travail de développement vers la prochaine version majeure est en cours , ce n'est pas un problème utile, je vais donc le fermer.

J'espère que les gens sont suffisamment mûrs pour ne pas continuer à publier sur un fil fermé, mais nous pouvons le verrouiller si le besoin s'en fait sentir.

J'aurais aimé pouvoir faire avancer ce fil avec une solution de style moins couplée !
Cependant, je pense que notre priorité, pour l'instant, devrait être de terminer la migration/l'amélioration globale des composants.

@mxstbr merci pour les composants stylés

Cela fonctionne tant que les composants attachent le prop className en interne à un nœud DOM

cela pourrait valoir la peine d'être souligné quelque part dans votre guide d'utilisation lors de la sortie de mui:next . Ce commentaire vient de me sauver.

Les styles Flex pour IE10 ne fonctionnent pas avec jss mais fonctionnent avec des composants stylés comme un charme

@yhaiovyi Material-UI ne prend pas en charge IE10.

Préfixe de fournisseur evtl. Sera bientôt corrigé pour jss, cela ne signifie pas que cela résoudra tous les problèmes si mui n'a jamais été testé sur IE10

Quoi qu'il en soit, je n'ai trouvé aucun autre problème que CSS Flex avec IE10 jusqu'à présent

Il semble que nous ayons 3 façons (cela pourrait être plus facile, mais tout n'est pas fait de fleurs) de remplacer les styles d'interface utilisateur de matériau par des composants stylés. Voici mon Gist .

Vous pouvez également obtenir une API de composants stylés comme avec quelques lignes de code : https://material-ui-next.com/customization/css-in-js/#styled -components-api-15-lines-

Vous pouvez également utiliser styled-jss , par exemple : https://codesandbox.io/s/32mvjyjyxq

le seul inconvénient avec JSS en général est le manque d'auto-complétion dans les éditeurs de code, comme dit ici aussi , mais les avantages sont là, l'analyse css en js comme dans les composants stylés est un peu une surcharge

edit: je viens de remarquer le problème référencé juste au-dessus, intéressant

Ce qui est ennuyeux, c'est le contexte de Mui et withStyles HOC ne semblent pas bien jouer avec le core react-jss et styled-jss ThemeProvider https://codesandbox.io/s/32mvjyjyxq (j'ai essayé de mettre un Typography mais ça ne marche pas, éditez: nvm, toujours en train de jouer avec)

Je me demande si plus tard (post v1 je suppose), cela ne vaudrait pas la peine de simplifier src/styles/withStyles et la double couche MuiThemeProvider + JSSProvider, et d'avoir quelque chose d'un peu plus simple comme la façon dont react-jss et styled-jss ont

Totalement pour ça !

Le 13 mars 2018 à 13h55, "Cyril Auburtin" [email protected] a écrit :

Ce qui est ennuyeux, c'est le contexte de Mui et avecStyles HOC ne semblent pas jouer
bien avec le core react-jss et styled-jss ThemeProvider
https://codesandbox.io/s/32mvjyjyxq

Je me demande si plus tard (post v1 je suppose) ça ne vaudrait pas la peine de simplifier
src/styles/withStyles et MuiThemeProvider + JSSProvider double couche

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mui-org/material-ui/issues/6115#issuecomment-372655385 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AADOWAbwLOnRoypx9ANCZnKyalZyD0M9ks5td8HNgaJpZM4L-GwD
.

analyser css en js comme dans les composants de style est un peu une surcharge

Tout comme l'analyse des objets en CSS est :wink: L'analyse des chaînes est à peu près à la même vitesse, honnêtement, cela n'a pas d'importance. https://github.com/A-gambit/CSS-IN-JS-Benchmarks/blob/master/RESULT.md

Solution | Utilisez CSS | Utiliser les styles en ligne | Temps de montage (ms) | Temps de rendu (ms)
:--- | :--- | :--- | :--- | :---
...
composants stylisés | + | - | 182 | 146,84
styled-components-decouple-cell | + | - | 213,53 | 152,39
...
réagir-jss | + | - | 198,97 | 297,74

@mxstbr un analyseur css complet écrit en js au moment de l'exécution a définitivement un prix. Cette référence ne mesure pas son coût.

un analyseur css complet écrit en js au moment de l'exécution a définitivement un prix.

Bien sûr, mais pas plus qu'un analyseur CSS complet qui gère les objets plutôt que les chaînes. De plus, les analyseurs CSS qui fonctionnent sur des chaînes CSS réelles ont été optimisés et explorés depuis longtemps, beaucoup moins avec ceux qui gèrent des objets. :rougir:

Je serais curieux de savoir comment comparer les bootstraps CSS en tant qu'objet avec votre analyseur vs bootstraps CSS avec stylis, notre analyseur, mais je suis à peu près certain que la différence sera au mieux négligeable.

Je serais curieux de savoir comment comparer les bootstraps CSS en tant qu'objet avec votre analyseur vs bootstraps CSS avec stylis, notre analyseur, mais je suis à peu près certain que la différence sera au mieux négligeable.

Oui, ce serait une référence appropriée, j'ai testé un peu, travailler avec des objets est beaucoup plus rapide, comme 10 à 20 fois plus rapide.

Mais encore une fois, cela dépend des plugins jss que vous incluez, nous avons beaucoup de plugins de sucre syntaxique.

Aussi. peu importe si nous passons tous à l'ISTF.

J'ai testé un peu, travailler avec des objets est beaucoup plus rapide, comme 10 à 20 fois plus rapide.

Bien sûr, mais 10 ms (c'est le temps qu'il faut au stylet pour analyser l'intégralité de la feuille de style bootstrap) contre 1 ms d'analyse de l'intégralité du CSS d'une application n'aura pas d'importance dans le grand schéma des choses, vous savez ? Cela ne fera ni ne détruira l'application de quiconque.

Quoi qu'il en soit, arrêtons d'ennuyer les gens dans ce problème avec plus de notifications que nécessaire.

D'ailleurs. ce benchmark semble être plus précis: http://necolas.github.io/react-native-web/benchmarks/ Je ne suis pas sûr qu'il ne repose pas sur un cache après la première analyse.

@mxstbr Bien que ce problème soit maintenant verrouillé, un peu de saine concurrence est bonne pour tout le monde. Revenez à tout moment - vous pouvez nous trouver dans le chat gitter si un problème n'est pas le lieu de discussion approprié.

Ce problème date de plus d'un an. Les gars, s'il vous plaît, arrêtez de commenter. Nous pouvons déplacer la discussion vers une nouvelle. Beaucoup de choses ont changé depuis le début de la discussion.

Mais essayons d'éviter les problèmes de verrouillage. Nous devons continuer à recueillir autant de commentaires que possible pour prendre de meilleures décisions.

Je pense que le problème de verrouillage en tant qu'outil pour communiquer clairement cela est bien, personne n'a été offensé par cela et la liberté d'expression n'a pas été prise. Dans ce cas c'est vraiment bien.

Je rouvre pour recueillir plus de commentaires, je suis curieux de savoir si c'est quelque chose qui intéresse toujours les gens :

Nous avons une enquête en cours auprès des développeurs, nous allons utiliser les résultats pour mettre à jour notre ROADMAP.
Nous avons les exigences suivantes avec la solution de styles :

1. Taille du paquet . Nous voulons que les gens puissent utiliser un seul composant sans avoir à payer 20 Ko gzippés pour cela. Par classement :
   
   
   
   1. emotion est le meilleur candidat dans ce sens : 10kB gzippé . Cependant, il est utilisé par peu de personnes. Si vous regardez les statistiques de téléchargement, 80 % proviennent du livre de contes ?
   
   
   2. styled-components pèse environ 16 Ko gzippé . Son avantage vient du nombre de personnes qui l'utilisent. Peut-être 20 % des utilisateurs de React ?
   
   
   3. JSS avec un poids d'enveloppe de réaction d'environ 15 Ko compressé. Si vous regardez les statistiques de téléchargement, une grande partie de l'utilisation provient de Material-UI.
   
   
2. Performances . Nous voulons que les gens ne puissent pas personnaliser nos composants. Ils doivent être aussi rapides que possible. Le benchmark que j'ai pu faire donne le classement suivant :
   
   
   
   1. émotion
   
   
   2. js
   
   
   3. composants de style
   
   
3. API de personnalisation . Personnaliser une variante devrait être facile, personnaliser un élément imbriqué devrait être facile, ajouter une nouvelle variante devrait être facile. À l'heure actuelle, nous avons une API classes , une API theme.overrides et la possibilité d'avoir des noms de classe déterministes globaux.
4. Interopérabilité . Utiliser !important n'est pas une solution.
5. Prise en charge RTL

Je n'ai mentionné que les composants de style, l'émotion et le JSS, mais ce sont des alternatives différentes : linaria, SASS, etc.

Je pense qu'il pourrait être utile d'ajouter les deux problèmes suivants car ils pourraient aider à décider quand vous auriez le temps de travailler sur la bibliothèque CSS-in-JS utilisée par Material-UI :

• https://github.com/mui-org/material-ui/issues/15660
• https://github.com/cssinjs/jss/issues/1102
  En bref, ces deux problèmes couvrent l'incohérence de JSS affectant l'expérience de développement.

@o-alexandrov Est-ce que JSS suit la même stratégie que les composants stylés ? Je ne comprends pas votre point. Pourriez-vous préciser? Quelle est la différence? Comment est-ce mieux ou vaut-il?

@oliviertassinari
Dans le message précédent, je ne dis rien à propos styled-components , sauf que je salue l'idée d'évaluer l'utilisation de styled-components ou de toute autre bibliothèque CSS-in-JS qui aurait l'équilibre parfait entre :

• expérience de développement (familiarité et flexibilité, autres contributions, utilisation réelle par les développeurs, etc.)
• performance

Les liens vers les deux questions ci-dessus ne traitent que de l' aspect négatif actuel du travail avec JSS.
J'ai oublié où j'ai vu ce qui suit, mais je me souviens que vous avez fait valoir que pour pouvoir prendre des décisions, nous devrions d'abord ajouter tous les types de repères afin que les décisions puissent être évaluées plus facilement.

Personnellement, j'aime :

• styled -components sur jss pour une adoption communautaire beaucoup plus large.
  Je pense que l'adoption par la communauté est l'aspect clé que Material UI devrait prendre en compte.

@o-alexandrov Ok, dans ce cas, je marque votre premier commentaire comme hors sujet. Dans la v5, nous voulons isoler les composants principaux de la solution de style. Je souhaite que nous puissions fournir une version nue, JSS, émotion, linaria et composants stylés (par défaut) des composants. C'est la vision. Maintenant, la mise en œuvre va être difficile !

Taille du paquet

styled-components s'est avéré être en train d'améliorer 12.3kB dans @5.0.0-beta.8

API de personnalisation

S'ils introduisent https://github.com/styled-components/styled-components/pull/2625 dans un package ou un package externe, je pense que la parité API avec Mui car il manque une API de composants non stylés dont nous pourrions parfois avoir besoin , en particulier dans les systèmes hérités, mais je ne pense pas que vous auriez souvent besoin de cette API dans Mui lui-même.

En dehors de cela,

Je ne suis pas sûr des informations que vous aimeriez recueillir car, d'après mon expérience personnelle, styled-components offre les fonctionnalités dont nous avons besoin.

Interopérabilité.

Qu'est-ce que c'est pour vous dans ce contexte ? Vous pouvez remplacer les choses dans styled-components comme n'importe quel autre cadre pour autant que je sache.

Prise en charge RTL

N'est-ce pas basé sur la façon dont nous codons les composants ? Qu'est-ce que styled-components ou n'importe quelle bibliothèque CSS-in-JS a exactement à offrir pour cela ?

Mes pensées

Vitesse

Auparavant, il était plus lent que d'autres solutions, mais le support et les efforts incroyables des contributeurs l'ont rendu au point où il devient encore plus rapide que JSS.

Taille

v5 devient encore plus maigre comme je l'ai dit 12.3kB de 16.2kB qui représentent leurs efforts sur ce sujet.

Familiarité

Les gens connaissent l'API car c'est la plus populaire, en fait, la plupart des gens appellent styled-components en référence à l'API plutôt qu'au package réel lorsque nous avons utilisé l'API styled(...) ... , pour la plupart.

Réagir natif

Cela pèse autant pour Mui est le Web, mais les gens continueront à adopter styled-components cause de cela.

Équipe de base

Strong Core team, à ce jour 81 numéros et 14 PR ouverts, ce sont de bons chiffres pour le nombre de personnes qui utilisent le package.

De plus, des gens comme @mxstbr utilisent réellement le package dans spectrum , il a donc une expérience réelle de l'utilisation du package, c'est incroyable, cela signifie qu'il sait réellement ce que l'on ressent en utilisant le package.

L'a pris

Eh bien, ça ne pourrait pas être mieux https://www.styled-components.com/docs/tooling

Pour les auteurs d'interface utilisateur

À ce jour, l'adoption de styled-components pour les composants Design System a beaucoup augmenté ; Atlassian, GitHub, Orbit et bien d'autres.

C'est bon pour Mui puisque vous ne serez pas seul, donc les gens font probablement déjà face à des situations potentielles que vous pourriez rencontrer et ils ont compris comment y faire face.

TL;DR

Je soutiens styled-components .

J'aime JSS parce que la syntaxe d'objet pour CSS est devenue plus facile pour moi, parfois je suis paresseux et je passe même ces styles en style inline style={{styles.dialogTitle}} , c'est facile à refactoriser plus tard

Et il peut être utilisé de différentes manières, avec un wrapper d'élément comme styled-components https://material-ui.com/styles/basics/#styled -components-api

@caub https://www.styled-components.com/docs/advanced#style -objects

J'aime beaucoup les composants stylés, mais j'ai découvert récemment qu'ils introduisaient un certain nombre de problèmes qui rendaient difficile le fonctionnement cohérent de l'agitation des arbres. Je sais que l'équipe material-ui vient de faire beaucoup de travail pour que le tree-shaking fonctionne pleinement pour cette bibliothèque, et évidemment toute régression à ce sujet doit être évitée.

Heureusement, la plupart de ses problèmes d'arborescence sont résolus en utilisant babel-plugin-styled-components et en définissant pure: true (voir https://www.styled-components.com/docs/tooling#dead-code-elimination ). Mais il reste encore quelques problèmes. Par exemple:
https://github.com/styled-components/babel-plugin-styled-components/issues/245

Une autre est que l'utilisation d'une fonction d'assistance externe à l'intérieur de vos styles peut interrompre l'arborescence (à moins que vous ne configuriez terser/uglify pour ignorer cette fonction spécifique), par exemple :

const Button = styled.button`
  font-size: ${externalHelperFunction()};
`

Je pense qu'il devrait être possible de résoudre tous ces problèmes pour que le secouage des arbres fonctionne correctement, mais cela peut certainement être délicat et ne fonctionne pas simplement de manière idéale dans l'état actuel des choses. En fait, je pense toujours que passer aux composants stylés pourrait être une bonne idée, mais seulement si ces problèmes peuvent être résolus.

@mbrowne Je n'ai pu reproduire aucun problème avec les composants arborescents et stylisés. Le problème n'inclut pas d'exemple reproductible, j'ai donc essayé de le reproduire avec

// components.js
import React from "react";
import styled from "styled-components/macro";

const Wrapper = styled.div`
  color: blue;
`;

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

MyComponent.displayName = "FancyName";

export function OtherComponent() {
  return "only";
}

// App.js
import React from 'react';
import { OtherComponent } from "./components";

/* code */

avec un create-react-app par défaut. MyComponent n'apparaîtra pas dans le lot de production.

Est-ce quelque chose avec seulement rollup qui a des problèmes ? J'apprécierais un exemple reproductible pour comprendre le problème.

@ eps1lon Je pense que le problème apparaît lors de la définition de la propriété statique sur le composant stylé, pouvez-vous essayer cela ?

const Wrapper = styled.div`
  color: blue;
`;

Wrapper.displayName = "FancyName";

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

@mxstbr Ouais, bien que dans les deux cas, les composants stylés soient regroupés. Alors que le paramètre displayName sur MyComponent n'incluait pas MyComponent dans le bundle, il inclut toujours styled-components . Il supprime essentiellement tout ce qui est fait à MyComponent , c'est pourquoi je pensais à l'origine qu'il secouait correctement les arbres (juste recherché pour FancyName .

Mais cela inclut toujours styled-components . Même si vous considérez qu'un appel styled a des effets secondaires, je considérerais

import React from "react";
import styled from "styled-components";

export function Wrapper() {
  // nonsense
  return styled.div``;
}

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

sans effet secondaire lors de l'importation { OtherComponent } mais les composants stylés apparaîtront toujours dans le bundle (c'est même sans la macro). Donc, soit c'est un bug, soit il me manque quelque chose de gros. Même

// Wrapper.js
import React from "react";
import styled from "styled-components";

export default function Wrapper() {
  // side-effect free module even if styled has side-effects
  const Component = styled.div``;
  return <Component />;
}

// components.js
// commenting this out removes styled-components from the bundle
export { default as Wrapper } from "./Wrapper";

export function OtherComponent() {
  return "only";
}

// index.js
import React from 'react';
import ReactDOM from 'react-dom';
import { OtherComponent } from "./components";
import * as serviceWorker from './serviceWorker';

ReactDOM.render(<OtherComponent />, document.getElementById('root'));

// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();

comprendra styled-components (https://github.com/eps1lon/styled-components-shake).

Peut-être un bogue dans les scripts de réaction, le pack Web ou les composants stylés. Dans tous les cas, le débogage de ces problèmes est incroyablement difficile sans reproduction.

C'est logique, merci d'avoir enquêté là-dessus.

Pour ce cas d'utilisation, je ne pense pas qu'il importe que styled-components soit inclus dans le bundle (puisque tous les composants doivent l'utiliser), mais plutôt si les composants que vous n'utilisez pas sont inclus, ce qui n'est pas le cas on dirait que c'est le cas, donc c'est bien, non ?

@mxstbr Cela pourrait être une préoccupation importante, nous avons quelques composants sans style et génériques (Modal, Popper, TextareaAutosize, useMediaQueries, etc.), disons que quelqu'un utilise

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

avec le SASS. Nous nous attendons à une augmentation gzippée de +5 Ko (à ce jour), et non de +20 Ko gzippée.

Cependant, en supposant que nous poussions @material-ui/unstyled vers l'avant, en pratique, cela pourrait ne faire aucune différence car les gens pourraient utiliser ce package.

@ eps1lon Désolé, je pensais que le problème avec les propriétés statiques serait plus facile à reproduire pour les autres car il semblait affecter tous nos composants ... il s'avère qu'il y a beaucoup de choses différentes qui déclenchent le problème, mais au moins dans quelques cas simples ça marche.

J'ai créé une démo reproductible ici:
https://github.com/mbrowne/CRA-error-template/tree/styled-components-tree-shaking
git clone --single-branch --branch styled-components-tree-shaking [email protected]:mbrowne/CRA-error-template.git

Notez que seul l'arborescence Composant1 secoue correctement.

La bonne nouvelle est que je pense que ces problèmes peuvent tous être résolus, et @mxstbr semble très engagé ici. Je vais bientôt travailler sur un PR qui abordera au moins le problème des accessoires statiques (j'ai déjà un POC fonctionnel utilisant un plugin Babel séparé que j'ai écrit).

J'ai ouvert un PR dans des composants de style babel-plugin pour résoudre les problèmes de tremblement d'arbre. Si quelqu'un ici veut aider à le tester, j'imagine que @mxstbr l'apprécierait (et moi aussi bien sûr):
https://github.com/styled-components/babel-plugin-styled-components/pull/248

Bonjour à tous, où se trouve ce ticket actuellement ? Je serais plus qu'heureux de m'impliquer et d'écrire des composants stylés pour MUI si c'est effectivement la direction que prend le projet dans la v5

Je suppose que nous ne voulons pas le faire en une seule fois (je doute que nous le voulions). Nous devrions soit commencer par faire en sorte que les composants stylés lisent le thème à partir de jss, soit que jss lise le thème à partir des composants stylés. L'objectif devrait être que nous puissions migrer les styles par composant.

Cela devrait probablement se produire sur une autre branche. Bien que nous ne voulions pas tout changer sur master en une seule fois, nous devrions probablement le publier avec un seul changement (dans la v5). Sinon, cela devient encore plus déroutant.

La suppression du commentaire a été demandée.

Hé les gars, je suis prêt à contribuer aussi... une branche séparée semble être une chose sensée à faire pour nous... faisons ça... !

@caprica-Six Merci pour l'énergie mais une nouvelle branche n'est pas nécessaire. Nous devrions être en mesure de fournir une version des composants stylés au fur et à mesure (+ jss et émotion) (instable pendant la v4), et de faire avancer l'histoire non stylée en même temps. J'ai un POC que je dois soumettre. Les composants stylisés (v5 beta) + accessoires dynamiques sont un peu plus lents que ce que nous avons avec JSS et les styles statiques, mais cela devrait toujours être acceptable.

@oliviertassinari est-ce qu'il y a un endroit où on peut s'impliquer là-dedans ? J'attendais en quelque sorte qu'un mainteneur me pointe dans la bonne direction avant de me lancer dans quoi que ce soit

Pourquoi ne préférez-vous pas l'émotion aux composants stylés ? Il semble que la raison en soit que "[l'émotion] est utilisée par peu de gens. Si vous regardez les statistiques de téléchargement, 80 % proviennent du livre d'histoires ?", mais c'est faux. Il est plus utilisé que les composants stylés ( comparaison ) et je ne vois pas pourquoi 80% des téléchargements proviennent de storybook. Il se développe clairement beaucoup plus rapidement que le livre de contes.

Je pose cette question parce que j'en avais marre d'utiliser des composants de style (à cause de plusieurs problèmes que je rencontrais) et que je cherchais une alternative, et j'ai découvert Emotion. Je l'ai testé et n'ai trouvé que des avantages par rapport aux composants stylés.

Il est plus léger, plus rapide et a plus de fonctionnalités : transfert de propriété, TypeScript prêt à l'emploi (et parfaitement pris en charge par rapport aux composants de style), Next.js SSR prêt à l'emploi (sans avoir à écraser le _app. js et _document.js, ce qui m'a pris une heure à gérer la première fois)

Et en plus, il est plus utilisé que les composants stylés et a clairement une dynamique.

@lcswillems Je pense qu'il faut aussi favoriser l'émotion pour les gens qui la préfèrent. Mais je ne pense pas que cela devrait être la valeur par défaut.

• "plus léger": Pas précis : https://bundlephobia.com/[email protected] (12,2 ko) vs https://bundlephobia.com/result?p=@emotion/ styled + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (13,1 ko sans tenir compte des dépendances partagées)
• "Next.js SSR prêt à l'emploi": je pense que c'est un problème important, inlining

Merci de votre réponse et de me corriger.

• "plus léger": tu as raison
• "Next.js SSR out-of-the-box": Je comprends maintenant pourquoi ils peuvent faire du SSR out-of-the-box et pourquoi leur façon de le faire n'est pas la bonne.
• "plus utilisé que les composants stylés": je ne suis pas sûr que ce soit fiable. Mais ma source n'est peut-être pas fiable non plus.
• "faster" : je n'ai vu que des benchmarks obsolètes, donc non, je n'en ai pas.

Le principal problème auquel je suis confronté est le transfert/filtrage des accessoires : https://github.com/styled-components/styled-components/issues/439 . Cela m'arrive très souvent et c'est pénible de faire le filtrage manuellement à chaque fois.

Mais avec vos remarques, l'émotion semble être une moins bonne alternative.

"lighter": Pas précis : https://bundlephobia.com/[email protected] (12,2 ko) vs https://bundlephobia.com/result?p=@emotion/ stylé + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (13,1 ko sans prendre

Dans le cas d'Emotion, vous n'utiliserez probablement pas le package @emotion/styled au profit de css props + @jsx pragma. De plus, vous n'aurez peut-être pas besoin du package emotion-theming , le ThemeContext est déjà inclus dans @emotion/core . C'est donc 12,2 Ko contre 6,5 Ko.

inlining

Simple curiosité : que signifient ces mises à jour pour les utilisateurs de la bibliothèque @material-ui/styles pour les composants non MUI ? Dans mon entreprise, nous l'utilisons comme base pour une grande bibliothèque de composants internes, l'ayant délibérément choisie sur styled-components , et nous en sommes très satisfaits.

Je pensais juste que je vérifierais à l'avance s'il y avait une sorte de dépréciation prévue pour le package @material-ui/styles , afin que je puisse planifier en conséquence.

Quoi qu'il en soit, merci pour tout ce que vous continuez à fournir !

@nickjohnson-dev La migration vers react-jss devrait être simple. Cela fonctionnerait-il pour votre organisation ?

@oliviertassinari Je pense que c'est probable. Tant que nous pouvons garder l'API publique des composants eux-mêmes essentiellement les mêmes ( classes remplacements locaux basés sur prop, remplacements globaux possibles dans le thème), je ne pense pas que ce soit un problème de modifier les détails d'implémentation.

Prévoyez-vous qu'il existe une documentation officielle pour la migration de @material-ui/styles vers les autres options de style après que MUI soit plus découplé ? À première vue, je ne vois aucune fonctionnalité manquante dans react-jss que nous exploitons dans @material-ui/styles , mais je ne sais pas s'il me manque quelque chose de spécial que fait le package MUI Dans les coulisses.

@nickjohnson-dev Nous ferons de notre mieux.

Si je comprends bien, le problème suivant se produira.
Nous avons le réutilisable ComponentA . Nous fabriquons le ComponentB qui utilise ComponentA .

const ComponentA = ({className}) => (
  <div className={className}>
    <div className='inner' />
  </div>
);

const ComponentB = ({ className, classNameInner }) => (
  <div className={className}>
    <div className='inner'>
      <ComponentA className={classNameInner} />
    </div>
  </div>
)

const StyledComponentB = styled(ComponentB)`
     ???
`;

Remarquez comment ComponentA et ComponentB ont l'élément avec le même className='inner' . Comment allons-nous cibler l'élément .inner sur ComponentB uniquement ?

Salut @oliviertassinari , merci d'avoir partagé toute la réflexion derrière le style de la prochaine version de Material UI.

Et merci aussi pour Material UI. En ce moment, je construis un système de conception dessus.

En ce qui concerne l'adoption styled-components , il semble que ce soit une décision prise, et le travail vers cet objectif a déjà commencé.

Cependant, je partage certaines des observations faites par @croraf et @lcswillems

Quelque chose de génial dans le style actuel de Material UI est la propriété classes .

C'est une idée simple qui aide beaucoup à la personnalisation du style et à la maintenabilité, car la saisie de classes fait partie de l'interface publique. Par exemple, si j'ai besoin de personnaliser quelque chose et que j'utilise un sélecteur comme & .Component-root , rien ne garantit que Component maintiendra cette classe CSS à travers les versions. En ayant au moins <Component classes={{root: ....}} /> , je peux obtenir une erreur de vérification de type (si vous utilisez TypeScript) à propos du changement d'interface.

En tant qu'auteur de composants, je peux décider de documenter des classes publiques (et prises en charge) et de laisser les autres non documentées.

J'ai utilisé style-components pendant environ 2 ans. C'est vrai que c'est populaire et ça a beaucoup évolué. Mais, dans les exemples de documentation MUI, je vois le même problème que @croad mentionne : utiliser un sélecteur descendant & .inner est très fragile car vous pouvez propager les styles aux sous-composants (et d'après ma propre expérience, je peux dire ce n'est pas une affaire de coin... ça m'est arrivé quelques fois). Deux solutions possibles sont :

• Utilisez &.inner puis utilisez ${props.className}.inner partout. Je l'ai fait plusieurs fois, et c'est pénible à écrire.
• Utilisez > .inner mais cela dépend de la structure du composant. Ajoutez quelques div supplémentaires au milieu et ça casse.

Est vrai que JSS n'est pas populaire. Je l'apprends à cause de MUI. Mais après avoir travaillé si longtemps avec styled-components , j'ai trouvé l'approche des styles MUI rafraîchissante et plus facile à travailler (au bout d'un moment, avoir le Styled HOC partout ajoute beaucoup de travail supplémentaire et j'ai commencé à les détester HOC... du moins c'est mon expérience personnelle). L'émotion correspond plus ou moins à l'approche actuelle. Et après avoir lu vos commentaires et certains des problèmes de performances JSS dans certains cas, j'évalue l'utilisation d'Emotion pour le système de conception.

Cependant, je vous vois tellement convaincu par styled-components que j'aimerais voir plus d'exemples sur la façon de résoudre la personnalisation du style à l'aide d'accessoires classes . Ceux disponibles dans les documents MUI actuels partagent les problèmes que j'ai mentionnés ci-dessus.

Il existe d'autres façons d'utiliser styled-components avec le prop classes ? Qu'en pensez-vous ?

JSS est assez bon et est très pratique à utiliser. Y a-t-il une raison sérieuse de déménager ?

Personnellement, je pense que le composant stylé est une sorte de retour en arrière et JSS a été la principale raison pour laquelle j'ai commencé à utiliser cette bibliothèque pour être honnête.

@powerfulj Pourquoi préférez-vous JSS aux composants stylisés ? J'ai dû choisir entre les deux et les composants de style me semblaient meilleurs.

@lcswillems
Je l'aime parce que je pense qu'il n'introduit pas de nouveau composant, et à la place, vous opérez simplement sur les propriétés. Si vous avez vraiment besoin d'un nouveau composant réutilisable stylisé, vous pouvez facilement le créer avec la solution JSS.

De plus, il est plus rapide de convertir le style en ligne en style JSS, ce qui est pratique pour moi car j'utilise habituellement les styles en ligne lors de l'implémentation, puis je le convertis en JSS s'il devient plus gros et réutilisé.

Le côté négatif est que si vous avez du CSS (comme dans les outils de développement du navigateur) et que vous devez le convertir en JSS, vous devez passer plus de temps à ajuster la syntaxe. Avec le composant de style, cela va plus vite.

Juste pour partager ma découverte concernant ce problème.
J'ai essayé de migrer une démo vers des composants stylés comme requis par # 16947. Le problème vient du thème par défaut. makeStyles accepte les options où defaultTheme peut être passé. Il y a makeStyles wrapper qui fournira defaultTheme . Ensuite, useStyles hook vérifiera si ThemeProvider fournit le thème, et si ce n'est pas le cas, injectera defaultTheme .

Il semble qu'il n'y ait pas une telle fonctionnalité dans les composants de style. En l'absence de ThemeProvider defaultTheme ne peut être injecté qu'avec la méthode .attrs . Nous pouvons créer quelque chose de similaire à makeStyles wrapper

import styledWithoutDefault from 'styled-components';
import defaultTheme from './defaultTheme';

const styled = Component => {
  return styledWithoutDefault(Component).attrs({ theme: defaultTheme });
};

export default styled;

Mais la méthode .attrs écrasera simplement le thème fourni par ThemeProvider cas échéant. Et je ne sais actuellement pas comment résoudre ce problème.

Un autre problème est que makeStyles utilise le préréglage jss-plugin-default-unit et semble que les composants stylés ne le sont pas. Ainsi, les composants de style ne sont pas ajoutés px à la valeur de retour de la fonction spacing() .
La solution possible au dernier problème consiste à utiliser Styled-JSS et non les composants stylés.

Je suis heureux d'avoir ici vos idées/suggestions.

@fyodore82 .attrs fonctionne comme une fonction (voir https://www.styled-components.com/docs/api#attrs), donc cela fera :

```js
.attrs(({ theme = defaultTheme, ...props }) => ({ ...props, theme }))
````

@croraf

Je l'aime parce que je pense qu'il n'introduit pas de nouveau composant, et à la place, vous opérez simplement sur les propriétés

Je pense que vous avez raté une très bonne chose de Styled-components : le css prop . Il vous permet d'ajouter du CSS à un composant sans avoir à en créer un nouveau.

De plus, il est plus rapide de convertir le style en ligne en style JSS, ce qui est pratique pour moi car j'utilise habituellement les styles en ligne lors de l'implémentation, puis je le convertis en JSS s'il devient plus gros et réutilisé.

Avec le prop CSS, notez qu'un composant avec le prop CSS n'a pas d'attribut style , il est déjà converti en un composant stylé et a donc un class . Si le CSS grossit et est réutilisé, vous pouvez également créer un nouveau composant.

Le côté négatif est que si vous avez du CSS (comme dans les outils de développement du navigateur) et que vous devez le convertir en JSS, vous devez passer plus de temps à ajuster la syntaxe. Avec le composant de style, cela va plus vite.

Je suis d'accord. C'est la principale raison pour laquelle je ne l'ai pas utilisé. La plupart des CSS écrits en ligne sont écrits en CSS, pas en JSS. Donc, si vous souhaitez utiliser du code de StackOverflow, vous devez d'abord le convertir en JSS, ce qui est très pénible.

Autres arguments supplémentaires qui m'ont fait utiliser Styled-components :

• C'est plus pénible d'écrire en JSS : il faut ajouter des guillemets, il n'y a pas de coloration syntaxique (ou je n'en ai pas trouvé).
• C'est plus difficile à comprendre pour les nouveaux arrivants. Tout le monde connaît CSS donc tout le monde peut facilement lire du code avec des composants stylisés, ce qui n'est pas le cas avec JSS (la syntaxe JSS est généralement un peu bizarre et en particulier pour les pseudo sélecteurs et les requêtes multimédias).
• Le code est beaucoup moins lisible. Pour illustrer ce point, j'ai réécrit cet exemple de composant Card avec des composants stylisés pour montrer à quel point cela peut être plus clair avec eux.

Version JSS :

import React from 'react';
import { makeStyles, useTheme } from '@material-ui/core/styles';
import Card from '@material-ui/core/Card';
import CardContent from '@material-ui/core/CardContent';
import CardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import PlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

const useStyles = makeStyles(theme => ({
  card: {
    display: 'flex',
  },
  details: {
    display: 'flex',
    flexDirection: 'column',
  },
  content: {
    flex: '1 0 auto',
  },
  cover: {
    width: 151,
  },
  controls: {
    display: 'flex',
    alignItems: 'center',
    paddingLeft: theme.spacing(1),
    paddingBottom: theme.spacing(1),
  },
  playIcon: {
    height: 38,
    width: 38,
  },
}));

export default function MediaControlCard() {
  const classes = useStyles();
  const theme = useTheme();

  return (
    <Card className={classes.card}>
      <div className={classes.details}>
        <CardContent className={classes.content}>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <div className={classes.controls}>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon className={classes.playIcon} />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </div>
      </div>
      <CardMedia
        className={classes.cover}
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

Version composants stylés :

import React from 'react';
import styled from 'styled-components';
import { useTheme } from '@material-ui/core';
import MuiCard from '@material-ui/core/Card';
import MuiCardContent from '@material-ui/core/CardContent';
import MuiCardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import MuiPlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

export default function MediaControlCard() {
  const theme = useTheme();

  return (
    <Card>
      <Details>
        <CardContent>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <Controls>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </Controls>
      </Details>
      <CardMedia
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

const Controls = styled.div`
  display: flex;
  align-items: center;
  padding-left: ${props => props.theme.spacing(1)}px;
  padding-bottom: ${props => props.theme.spacing(1)}px;
`

const PlayArrowIcon = styled(MuiPlayArrowIcon)`
  height: 38px;
  width: 38px;
`

Enfin, je n'ai trouvé aucun avantage à utiliser JSS.

La propriété css est très agréable et résout essentiellement les inconvénients que j'ai mentionnés. (les copies forment des composants stylés :D )

Concernant la comparaison des deux exemples je la trouve peu lisible et elle double le nombre de composants.

@lcswillems

Ne plaidez pas pour une solution ou l'autre, reprenez simplement quelques-uns de vos points :

si vous souhaitez utiliser du code de StackOverflow, vous devez d'abord le convertir en JSS, ce qui est très pénible

Il existe une extension VSCode pour convertir CSS en CSS-in-JS, bien qu'elle ne fonctionne pas toujours parfaitement. Quoi qu'il en soit, je n'appellerais pas cela douloureux.

vous n'avez pas de coloration syntaxique

Je ne comprends pas très bien cet argument. C'est juste un objet JS, donc la coloration syntaxique de n'importe quel éditeur fonctionne :

(mais peut-être cherchez-vous quelque chose de plus spécifique ?)

Concernant la comparaison des deux exemples je ne la trouve pas beaucoup plus lisible. Bien que l'absence d'accessoires className soit sans doute plus propre, il n'est pas évident d'après le bloc de code JSX principal si les composants font référence à des composants natifs MUI ou à des composants restylés sans avoir à faire référence aux composants styled() . Dans un composant plus grand, ceux-ci pourraient être très éloignés.

Les invocations styled() sont (pour moi) moins lisibles que l'objet JSS (bien que j'imagine que vous vous y habituez).

@powerfulj Pourquoi préférez-vous JSS aux composants stylisés ? J'ai dû choisir entre les deux et les composants de style me semblaient meilleurs.

Parce que je suis moi-même un développeur Typescript et que je préfère tout construire en objet Typescript. Surtout je déteste les cordes.

Bien que nous devions transférer le code CSS vers le code JSS en raison de la différence, je préfère toujours lire le code JSS car la structure ressemble au CSS traditionnel (orienté classe), je passerais plus de temps à lire le code de composant stylé car il est plus long et peut être ici et là.

Je pense que les gens ont réclamé ce changement uniquement parce qu'ils ont de l'expérience dans le composant Styled dans le passé. Cela me donne l'impression "pourquoi ne choisissons-nous pas une bibliothèque que nous connaissons mais sans avantage évident?".

De mon point de vue, c'est comme si JSS était juste pratique, nous pouvons organiser l'objet en utilisant toutes les méthodes Javascript comme

{
... partagéJSS1,
... partagéJSS2,
peu importe
}

Nous avons également des thèmes dynamiques transparents intégrés aux types et nous avons obtenu toutes les indications de type des types className et css.

Pour les nouveaux développeurs, en particulier les développeurs Typescript aimeraient tout simplement JSS.

Pour votre information, il est possible de faire de l'imbrication dans des composants de style si vous ne voulez pas toujours un composant séparé pour tout. C'est généralement déconseillé, car l'utilisation de composants séparés avec des noms significatifs est considérée comme plus propre et plus lisible selon la philosophie des composants stylés, mais les docs disent que c'est bien si "utilisé avec parcimonie". Et bien sûr, pour tous ceux qui ne partagent pas cette philosophie, ils sont libres de faire plus d'imbrication. Comme exemple de ce que je veux dire par imbrication :

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

Voir https://www.styled-components.com/docs/faqs#can -i-nest-rules pour plus de détails.

Les discussions sur les préférences de style de codage peuvent se poursuivre indéfiniment.

Après avoir utilisé styled-components pendant un certain temps, j'aime davantage l'approche JSS, car :

• Lorsque les styles s'allongent, je les déplace généralement dans un fichier séparé.
  J'ai aussi fait ça avec styled-components , et je trouve que useStyles / makeStyles est plus facile à écrire, à lire et à maintenir. Par exemple. import useStyles from './MyComp.styles' vs import {XStyled, YStyled,...} from './MyComp.styles' ... maintenir ces variations de ...Styled avec leurs typages dans TS est ennuyeux.
• J'ai tendance à faire les choses de manière progressive : je commence d'abord par un brouillon en utilisant des divs et des classes, puis je les refactorise en composants. Lorsque j'utilise styled-components , je le fais en utilisant des classes internes (comme dans l'exemple de @mbrowne), mais cela nécessite plus de travail de refactorisation. J'ai trouvé l'approche useStyles beaucoup plus confortable pour travailler avec ce flux de travail.
• Les littéraux de modèle sont bons pour coller du code CSS, mais terribles lorsque vous devez utiliser des variables de thème/prop. Le problème de coller du code est facile à résoudre avec un plugin, mais l'édition avec des variables et des fonctions à l'intérieur du littéral du modèle n'est pas tellement.

Mais ce sont mes préférences personnelles, les vôtres peuvent être différentes.

Ma plus grande question ouverte concerne le changement d'utilisation classes .

Les exemples d'utilisation de className et des classes internes ont des problèmes (voir mon commentaire précédent). Le prop css dans styled-components n'est pas une option pour résoudre ces problèmes. Contrairement à la fonction css dans Emotion, la prop css repose sur le fait d'être attachée à un composant (ce qui signifie que vous ne pouvez pas l'utiliser dans un style de code useStyle/makeStyles/classes ).

L'association de styles à un composant n'est pas une décision de conception mineure. Pour moi, c'est le bon et le mauvais de JSS. Les composants stylisés et Emotion s'appuient sur les plugins Babel et interagissent avec React pour gérer la mise en cache et la génération de noms de classe pour SSR. La bonne partie de JSS, c'est qu'il n'a pas besoin de plugin Babel. La mauvaise partie est que SSR dans JSS nécessite plus de travail, et j'ai vu des bogues signalés dans ce domaine.

De retour à MUI, j'ai l'impression qu'adopter des composants de style signifie utiliser className et les classes internes comme le seul moyen de personnaliser les styles. Le style devient plus cohérent d'un framework à l'autre : vous pouvez utiliser styled ou css prop, tant que le composant utilise le className que vous êtes bon.

Mais pour moi, supprimer l'accessoire classes est un pas en arrière. Cet accessoire aide à documenter et à taper les personnalisations de style de vérification. Il est peut-être possible de trouver un terrain d'entente, comme l'utilisation de composants stylés mais en gardant le support pour classes (sans avoir besoin du hack de classe interne). Je n'ai rien trouvé dans l'API des composants de style qui aide dans ce cas. C'est pourquoi il peut être bon d'évaluer quels sont les problèmes techniques de JSS. Parce que si la popularité est le principal problème, l'émotion devient également populaire (voir https://2019.stateofcss.com/technologies/css-in-js/#tools-section-overview), et cela peut être facile comme moyen de réécrire makeStyles .

@dfernandez-asapp vous avez fait d'excellents points en répondant simplement à une petite partie de ce fwiw @styled-components prend en charge l'utilisation d'un objet similaire à jss au lieu d'une chaîne https://www.styled-components.com/docs/advanced# style -objets

Bien que ce soit assez décevant, les composants stylés ont supprimé le support de tapuscrit de première classe et sont globalement d'accord avec vous que cela semble être un pas en arrière dans les autres façons que vous avez décrites

Pour votre information, il est possible de faire de l'imbrication dans des composants de style si vous ne voulez pas toujours un composant séparé pour tout. C'est généralement déconseillé, car l'utilisation de composants séparés avec des noms significatifs est considérée comme plus propre et plus lisible selon la philosophie des composants stylés, mais les docs disent que c'est bien si "utilisé avec parcimonie". Et bien sûr, pour tous ceux qui ne partagent pas cette philosophie, ils sont libres de faire plus d'imbrication. Comme exemple de ce que je veux dire par imbrication :

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

Voir https://www.styled-components.com/docs/faqs#can -i-nest-rules pour plus de détails.

Un support de type pour cela? Ou faut-il mettre de la ficelle partout ?

Je ne comprends pas pourquoi il y a tant de battage médiatique pour les composants stylés. Cela ressemble à un pas en arrière pour être honnête. Les propriétés CSS typées de JSS avec TypeScript sont beaucoup plus pratiques et faciles à entretenir, en plus de la vérification de la syntaxe dans le cadre de JS - tout éditeur moderne/configuré vous dira si vous faites une faute de frappe et vous aidera même avec la saisie semi-automatique si vous le souhaitez.

edit : il est tapé, voir la réponse de South-Paw ci-dessous.

@martinjlowm a l'air d'avoir des frappes pour moi?

Voir : https://styled-components.com/docs/advanced#style-objects

Vous dites que vous ne comprenez pas le battage médiatique... mais je ne reçois pas non plus toute la haine qu'il suscite. 🤷‍♂

Les composants d'émotion et de style sont de vastes améliorations par rapport aux objets de style CSS IMO

@martinjlowm a l'air d'avoir des frappes pour moi?

...

Voir : https://styled-components.com/docs/advanced#style-objects

Vous dites que vous ne comprenez pas le battage médiatique... mais je ne reçois pas non plus toute la haine qu'il suscite. 🤷‍♂

Les composants d'émotion et de style sont de vastes améliorations par rapport aux objets de style CSS IMO

Je vois! Je ne savais pas qu'il supportait des objets comme ça. Ma préoccupation était liée au CSS dans les chaînes de modèle - mais si les objets sont une option, alors je n'ai rien contre !

Évidemment, JSS n'est pas parfait non plus, je sais - les feuilles réutilisables générées par le serveur seraient une fonctionnalité mortelle - les composants stylisés le supportent-ils d'une manière ou d'une autre? Est-ce que quelqu'un sait?

En ce moment, il semble stupide de devoir supprimer les feuilles de style générées par le serveur et de forcer le client à restituer tous les styles :(

@martinjlowm a l'air d'avoir des frappes pour moi?
...
Voir : https://styled-components.com/docs/advanced#style-objects
Vous dites que vous ne comprenez pas le battage médiatique... mais je ne reçois pas non plus toute la haine qu'il suscite. 🤷‍♂
Les composants d'émotion et de style sont de vastes améliorations par rapport aux objets de style CSS IMO

Je vois! Je ne savais pas qu'il supportait des objets comme ça. Ma préoccupation était liée au CSS dans les chaînes de modèle - mais si les objets sont une option, alors je n'ai rien contre !

Évidemment, JSS n'est pas parfait non plus, je sais - les feuilles réutilisables générées par le serveur seraient une fonctionnalité mortelle - les composants stylisés le supportent-ils d'une manière ou d'une autre? Est-ce que quelqu'un sait?

En ce moment, il semble stupide de devoir supprimer les feuilles de style générées par le serveur et de forcer le client à restituer tous les styles :(

J'aimerais également préciser que les littéraux de modèle balisés peuvent également être saisis. TypeScript les marquera correctement comme étant invalides et le service de langage fournira les suggestions de saisie semi-automatique, etc.

@Patte-Sud

Les composants d'émotion et de style sont de vastes améliorations par rapport aux objets de style CSS IMO

Je ne comprends toujours pas pourquoi un développeur React serait intéressé par cela. Si vous voulez mettre votre CSS dans des chaînes de modèle, pourquoi n'utilisez-vous pas simplement Angular et mettez également votre code HTML dans des chaînes de modèle ? La force de React est que les éléments JSX ne sont en réalité que des objets JS que vous avez une tonne de puissance pour examiner et transformer, et il en va de même pour JSS.

Tout ce qui motive le CSS dans le mouvement JS est le fait que JS est largement supérieur au CSS pour faire des choses dynamiques, et la puissance des objets JS n'en est pas une petite partie.

Le fait que styled-components supporte les objets est une sorte de faux-fuyant :

• Il les prend en charge, mais pour une raison quelconque, il indique "Ceci est particulièrement utile lorsque vous avez des objets de style existants et que vous souhaitez passer progressivement aux composants stylés". Ils ne voient apparemment pas l'intérêt de pouvoir manipuler des objets et il semble que les objets de style seront toujours traités comme des citoyens de seconde classe dans leur API.
• Les docs ne précisent pas s'il prend en charge les sélecteurs CSS du monde réel comme celui-ci avec JSS :

{
  color: 'black',
  '&$error': {
    color: 'red'
  }
}

Even Emotion respecte la valeur des objets de style et les traite davantage comme des citoyens de première classe :

Les styles d'écriture avec des objets sont un modèle puissant intégré directement au cœur de l'émotion.

@lcswillems , vous sous-estimez à quel point il est compliqué de créer tous ces petits HOC tout le temps (et le fait que la plupart des systèmes d'importation automatique ne sont pas assez intelligents pour savoir si vous souhaitez importer @material-ui/core/Card en tant que Card ou MuiCard (et si vous écrivez encore des instructions d'importation à la main, vous perdez énormément de temps))

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

Ce genre de chose provoque une fatigue de décision horrible car vous devez constamment décider comment nommer chaque emballage et composant enveloppé.

C'est de cela que @dfernandez-asapp parle quand il dit :

(au bout d'un moment, avoir le Styled HOC partout ajoute beaucoup de travail supplémentaire et j'ai commencé à détester ces HOC... du moins c'est mon expérience personnelle)

Les HOC ont à peu près besoin de mourir. C'est un modèle obsolète. Par exemple, react-redux est sorti avec le crochet useSelector qui est 100 fois plus pratique que le HOC connect , Apollo est passé des HOC aux crochets, il en va de même pour le useStyles hook dans cette bibliothèque étant plus pratique que withStyles .

Le tracas de la conversion de CSS copié-collé en JSS est un problème beaucoup plus résoluble, s'il y a un intérêt, je ferai même une extension VSCode pour l'automatiser ou un site Web.

s'il y a un intérêt, je ferai même une extension VSCode pour l'automatiser

@ jedwards1211 Il y a paulmolluzzo.convert-css-in-js , mais si vous pouvez l'améliorer pour JSS, je suis sûr que ce serait bienvenu.

Oui, on dirait que je peux certainement l'améliorer, il ne convertit que les propriétés CSS, pas les règles et les sélecteurs.

@ jedwards1211 J'ai lu ce que vous avez dit et pris du recul par rapport à tout cela pendant un moment - cela me rappelle simplement les commentaires de personnes qui se disputent sur l'utilisation des onglets sur les espaces. La réalité est que ce que vous utilisez ne fait pas vraiment de différence tant qu'il produit un produit utile à la fin.

Laissez vos opinions/prises à chaud sur Twitter ou Reddit et nous pourrons en discuter là-bas - mais ne continuons pas à faire dérailler ce problème avec des guerres de flammes inutiles sur les chaînes de modèles contre les objets pour CSS... Je pense que nous pouvons tous convenir que nous sommes meilleurs que ça 😄

Merci d'avoir souligné que cela ne vaut pas la peine de changer le statu quo dans MUI ? 😉

Ma principale préoccupation est de savoir si mes bundles Webpack sont gonflés avec un mélange de code de composants stylés et de code JSS, car il y a trop de JSS existant dans notre application pour être retiré et remplacé par autre chose, et/ou parce que je voudrais rester avec JSS pour nos styles de toute façon.

Pour être juste, je me fiche des onglets par rapport aux espaces, mais si je devais écrire une demi-douzaine de HOC pour chaque composant que je fabrique, je n'apprécierais pas mon travail. Tous les outils existants ont eu la capacité de produire un produit utile ; si quelque chose était vraiment parfaitement pratique à utiliser dans tous les cas, il n'y aurait pas de changement constant dans l'écosystème, et nous n'aurions pas ces débats. Donc, cela fait vraiment une différence quand on y pense.

@ jedwards1211 même si vous êtes obligé d'utiliser des composants stylés, il existe une syntaxe alternative css prop introduite dans v4 que vous pouvez utiliser - au moins, de cette façon, vous n'aurez pas à vous en soucier donnant des préfixes aux composants stylés (MuiCard, StyledCard etc.).

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

// CSS is separate from the markup 👍
const avatarStyle = css`
  width: 32px;
  height: 32px;
  border-radius: 50%
`;

// No wrappers, prefixes in the markup (such as <MuiAvatar>, <StyledAvatar> etc.) 👍
function SomeComponent(props) {
  return <div> ... <Avatar css={avatarStyle} /> ... </div>
}

@ jedwards1211 votre exemple peut également être simplifié comme suit si vous utilisiez des composants stylés

const Card = styled(MuiCard)`
  display: flex;

  ${MuiCardContent} {
    flex: 1 0 auto;
  }

  ${MuiCardMedia} {
    width: 151px;
  }
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

@koistya l'accessoire css est plutôt cool, même si une mise en garde importante est qu'il est implémenté avec un plugin Babel, donc ce n'est pas pour tout le monde, en particulier les personnes qui utilisent tsc pour compiler leurs fichiers tsx. De plus, je suppose que cela amènerait TypeScript ou au moins Flow à se plaindre que le composant n'a pas d'accessoire css .

Je pense que je suis principalement mécontent de la perturbation potentielle que cela entraînerait dans mon application. @oliviertassinari a mentionné l'autre jour qu'il envisageait de faire styled-components la valeur par défaut dans MUI v5. Et j'espère que ce serait facultatif et que JSS pourrait toujours être utilisé, mais nous verrons s'ils peuvent le faire, vous savez. Cela a été un choc - Y a-t-il vraiment eu un référendum approfondi sur les préférences de l'ensemble de la base d'utilisateurs ? Je me serais attendu à Emotion parce que c'est beaucoup plus populaire maintenant.

De plus, je suppose que cela amènerait TypeScript ou au moins Flow à se plaindre que le composant n'a pas de prop css.

Peut être configuré.

Y a-t-il vraiment eu un référendum approfondi sur les préférences de l'ensemble de la base d'utilisateurs ?

C'est impossible. Nous ne pouvons que supposer que les personnes qui s'engagent sur GitHub sont "nos" utilisateurs. Ce problème est le plus élevé que nous ayons jamais eu .

Je me serais attendu à Emotion parce que c'est beaucoup plus populaire maintenant.

Comment avez-vous mesuré la popularité ?

⚠️ l'émotion est nettement moins choisie par les développeurs que les composants stylés (/6 de mes souvenirs). Si vous considérez les téléchargements sur npm, supprimez le livre de contes et réagissez-sélectionnez le nombre de téléchargements (c'est énorme).

@eps1lon voici ce que je regardais : https://2019.stateofcss.com/technologies/css-in-js/

J'avais tort cependant, malheureusement, tout ce dont je me souvenais était la tendance à la hausse apparente, même s'il ne s'agit pas d'un graphique de popularité au fil du temps (conception de graphique très discutable):

Peut être configuré

Existe-t-il réellement un moyen de faire en sorte que TypeScript suppose que tous les éléments JSX prennent en charge un accessoire css ? Je ne connais pas de moyen de configurer Flow pour le faire.

EDIT : heureusement, j'ai trouvé un moyen pour TypeScript, je ne sais pas s'il existe un moyen pour Flow.

Ce problème est le plus voté que nous ayons jamais eu.

Je vois. Soupir

FWIW, l'un des principaux contributeurs de styled-components , semble avoir une attitude hostile envers les systèmes de type :

https://github.com/styled-components/styled-components/issues/3012#issuecomment -583878486

Je me sentirais beaucoup plus rassuré à l'idée de migrer vers des composants stylés s'ils semblaient se soucier de l'expérience de développement des utilisateurs de TS/Flow...

@ jedwards1211 il y a une macro Babel pour css si cela aide. Surtout venant de css/scss/less, je ne pense pas que tout le monde aime passer à la manière "stylée".

Quels sont les objectifs cependant? Qu'en est-il des performances ? Par exemple, certains systèmes prennent en charge les CSS atomiques. Venant de Tailwinds, cela rend les choses beaucoup plus propres et peut-être plus rapides.

@hc-codersatlas vous pouvez trouver des repères dans packages/material-ui-benchmark .

@koistya si je le lis correctement, l'émotion semble beaucoup plus rapide que le reste.

@oliviertassinari est-ce que la plupart des développeurs "font" réellement ce choix ? Selon votre mention de react-select et storybook, la plupart des développeurs vont probablement utiliser tout ce qui est fourni avec les composants de l'interface utilisateur et material-ui étant un gros 1. À moins que ce qui est fourni ne soit terrible, aucun 1 ne va augmenter la taille et les dépenses de son bundle plus d'efforts avec un système différent en plus de ce que le cadre d'interface utilisateur utilise déjà.

La plupart de ces cadres d'interface utilisateur proviennent de grands corps, c'est-à-dire que quelques personnes font en fait ce "choix".

par exemple, l'œillet utilise des composants de style, que de nombreuses entreprises utilisent / utilisaient à un moment donné.

Et sur cette note, que signifient les téléchargements npm ? L'utilisation en entreprise signifie probablement des pare-feu et une mise en cache interne npm, ce qui fausse ces mesures.

S'il y a un changement, veuillez changer pour le meilleur 1 basé sur le mérite technique et non sur quelque chose comme la popularité. Je prédis que si material-ui utilise n'importe quelle bibliothèque, ce sera le populaire 1 car mui est lui-même l'un des frameworks d'interface utilisateur les plus populaires.

@South-Paw votre simplification proposée ne fonctionnerait pas, vous ne pouvez pas utiliser ${MuiCardContent} dans votre exemple car MuiCardContent n'est pas un composant stylé.

https://styled-components.com/docs/advanced#referring-to-other-components

Essentiellement, il n'y a aucun moyen d'éviter tous les emballages HoC individuels. Bien qu'après y avoir réfléchi pendant un moment, j'ai réalisé qu'il s'agissait essentiellement du même nombre de décisions de saisie / de nommage que celles que l'on doit prendre avec JSS.

@mbrookes @oliviertassinari comment les styles conditionnels et les styles de composants internes seraient-ils gérés ?
Par exemple, que serait un équivalent basé sur styled-components de ce qui suit ?

// conditional class name
<MenuItem classes={{selected: classes.selectedItem}}>...</MenuItem>

// inner component class name
<Dialog classes={{paper: classes.dialogPaper}}>...</Dialog>

Je me suis calmé à propos de l'idée du passage à styled-components , mais je veux m'assurer qu'il existe un plan solide pour gérer ce type de cas d'utilisation, car je suppose que l'API devrait être très différente ou s'appuyer sur les noms de classe de style BEM.

@ jedwards1211 ah mon erreur. J'avais l'impression que l'exemple était s'il s'agissait de composants stylés - mais en effet cela ne fonctionnera pas s'ils ne le sont pas 👍

@ jedwards1211 clsx est quelque chose que j'ai vu associé à des composants stylés dans le passé pour les classes conditionnelles - est-ce ce que vous voulez dire?

Les projets que je fais en ce moment utilisent des composants stylés enveloppant les composants MUI selon les besoins, donc je n'ai utilisé aucun des styles conditionnels MUI

@South-Paw cela (ou classnames ) pourrait être un détail interne de la solution, mais ce que je veux dire, c'est que puisque styled-components wrappers n'injectent qu'un seul className AFAICT, il y aurait Ce n'est pas vraiment un moyen pratique de passer plusieurs noms de classe de remplacement dans un composant. Au lieu de cela, nous devrons peut-être faire quelque chose comme <Dialog Paper={StyledPaper}>...</Dialog> , et je ne sais même pas quoi pour l'exemple de classe MenuItem sélectionné.

@jedwards1211 auriez-vous le temps de faire un exemple rapide afin que je puisse mieux comprendre quel est le cas d'utilisation que vous décrivez et où vous pensez que le problème est ? J'aimerais pouvoir essayer d'aider avec une solution mais je ne comprends pas encore à quoi cela s'applique 😄

Ouais je n'ai plus de temps ce soir mais demain je le ferai.
J'ai également des travaux en cours sur jss-codemorphs , prévoyant finalement de créer une extension VSCode pour convertir le CSS collé en JSS.

Je n'ai jamais été fan de la syntaxe des composants stylés ou de la façon dont le package est maintenu, pas fan de cette proposition. L'une des choses que j'aime le plus dans l'interface utilisateur matérielle est la solution de style actuelle.

Il est intéressant de noter que j'ai lu que Facebook pourrait également proposer une solution CSS-in-JS en open source. Il pourrait être utile de jeter un coup d'œil à cela également lors de sa sortie.

Concernant le sujet réel à portée de main. Je n'aime pas les composants stylés car l'expérience Typescript n'est pas géniale. Les types font souvent plus de mal que d'aide. Des temps de compilation lents, des interfaces insensées (essayer de comprendre comment les composants stylisés fonctionnent à travers l'interface est un cauchemar en raison de toutes ces magies Pick imbriquées). Tant que les composants stylés ont ce type de DX, cela semblerait être un pas en arrière pour material-ui d'adopter cela.

Il est intéressant de noter que j'ai lu que Facebook pourrait également proposer une solution CSS-in-JS en open source.

@venikx Quelle est la probabilité que cela se produise? La dernière fois que j'ai entendu parler de quelque chose qui pourrait suggérer que c'était dans https://reactpodcast.simplecast.fm/75 , cela semblait être un objectif de 5 ans.

Oh vraiment? Je ne savais pas qu'ils avaient déjà donné un "calendrier". Pour une raison quelconque, j'ai supposé que cela arriverait à peu près au même moment avec le mode simultané. Dommage.

Cela étant dit, mon point sur les composants stylés est toujours valable. Je préfère utiliser la manière pure de gérer les styles de material-ui plutôt que d'utiliser des composants stylés. Les typages des composants stylés semblent être là pour le compilateur et pas tant pour la documentation.

Une autre chose ennuyeuse (mais c'est probablement encore une préférence personnelle) est la façon dont vous gérez l'application dynamique de styles à un composant. Je préfère de loin l'ajout ou la suppression de classNames plutôt que l'intégration de cette logique dans le composant stylé.

Material-ui api est vraiment propre pour le moment à mon humble avis.

Je n'aime pas les composants stylés car l'expérience Typescript n'est pas géniale.

J'ai utilisé des composants stylés et Typescript ensemble dans au moins 4 grands projets jusqu'à présent et je n'ai eu aucun problème avec les types - ils peuvent être un peu poilus lorsque vous faites des choses dans une bibliothèque de composants, mais ce serait à la fin des MUI - pas du côté des consommateurs.

Temps de compilation lents

Je n'ai vécu cela dans aucun projet sur lequel j'ai travaillé qui les utilise - avez-vous un exemple quelque part de ce que vous voulez dire ?

interfaces insensées (essayer de comprendre comment les composants stylés fonctionnent à travers l'interface est un cauchemar en raison de toutes ces magies Pick imbriquées)

Vous pouvez également envisager de contribuer au projet @types si vous pensez que vous pouvez les améliorer d'une manière ou d'une autre - je suis sûr que tout le monde apprécierait tout travail là-dedans s'il s'agit d'une amélioration par rapport à ce qui existe actuellement !

Je préfère de loin l'ajout ou la suppression de classNames plutôt que l'intégration de cette logique dans le composant stylé.

Rien ne vous empêche d'utiliser des classes avec des composants de style :

const Box = styled.div`
  height: 160px
  width: 160px;
  background-color: black;

  .red {
    background-color: red;
  }
`;

// simple usage
<Box className="red" />

// get more complex with conditionals and using something like clsx (https://www.npmjs.com/package/clsx)
const isRed = true;
<Box className={clsx({ red: isRed })} />

A noter que malgré certains commentaires prétendant le contraire, il y a 150 👍 et 27 🎉 sur la question parent et seulement 18 👎 et 9 😕. On dirait qu'il y a une minorité vocale qui n'aime pas cette discussion et une majorité qui pense que c'est une étape positive 🤷‍♂

@South-Paw, le problème avec le vote est que le seul choix est : JSS vs styled-components. La partie vocale consiste à ne pas aimer les composants stylés et non pas qu'ils aiment JSS. Peut-être que si le vote

En fin de compte, tout est mieux que JSS. C'est vieux. C'est lent et volumineux (taille du paquet) et il devrait être déplacé. Donc, les votes ne soutiennent pas du tout votre conclusion.

Pourriez-vous tous passer au chat Spectrum ou quelque chose qui ne remplit pas ce problème de bruit sur les gens qui se battent pour voir qui gagne l'argument?

Je suis le fil de discussion sur ce sujet de l'équipe principale.

Je pense que vous sous-estimez le jugement de l'équipe principale, et personnellement, je pense que vous devriez arrêter de vous disputer sur ce sujet et faire davantage confiance à l'équipe principale ; en fin de compte, c'est à l'équipe principale de décider de la direction de Material UI.

Si vous avez vraiment une opinion forte à ce sujet, Material UI est étonnamment autorisé par le MIT, bifurquez-le et continuez avec la vision que vous avez, je vous encourage à le faire, peut-être que nous apprendrons à l'avenir de l'environnement diversifié.

Mais, s'il vous plaît, je vous en prie, laissez l'équipe de base faire son travail, faites-lui confiance, car ce sont des gens vraiment compétents avec des compétences incroyables.

Voici quelque chose de beau à regarder

En fin de compte, tout est mieux que JSS. C'est vieux.

@hc-codersatlas old == mature - pourriez-vous expliquer pourquoi c'est un problème ?

Ok semble être un problème brûlant, mais quelqu'un peut-il confirmer cette simple information : est-il actuellement possible d'utiliser une syntaxe de type styled-components , avec des littéraux de modèle balisés qui ressemblent à du CSS, dans les versions actuelles de Mui (4 ou 5) ?
Je n'ai pas trouvé de réponse claire par oui ou par non à cette question. Je ne me soucie pas vraiment de la technologie sous-jacente, seulement de la commodité du développeur. Le copier-coller du CSS d'InVision est fondamentalement très utile dans certains cas.

Ce problème concerne la solution de style utilisée dans Material-UI, votre question semble porter sur la façon dont vous stylisez votre application / restylez les composants, pour lesquels vous pouvez utiliser n'importe quelle solution :

https://material-ui.com/guides/interoperability/

JSS prend en charge de base les littéraux de modèle en tant que plug-in.

Je viens de terminer l'implémentation d'un convertisseur CSS vers JSS très complet :

• https://codemodsquad.github.io/jss-codemorphs/
• Extension VSCode : https://marketplace.visualstudio.com/items?itemName=vscodeshift.jss-codemorphs

Espérons que cela vous évitera de copier et coller du CSS dans les styles JSS.

@ jedwards1211 voir ça
https://css2js.dotenv.dev/

@nainardev J'ai remarqué que et d'autres utilitaires sont très limités, ils convertissent les attributs CSS, mais ne convertissent pas les sélecteurs, les sélecteurs imbriqués, les images clés d'animation, les requêtes multimédias, etc. À cause de cela, j'ai rendu mon outil très complet, il peut convertir j'espère que tout CSS complet que vous lui lancerez.

Peut-être avez-vous manqué cette réponse quelque part, mais vous voulez quand même la soulever. Nous sommes en train de migrer vers les composants Material UI ainsi que d'évaluer notre solution de style ( less vs makeStyles vs styled-components ), la plupart de notre style se fait avec moins et que la plupart du nouveau code MUI utilise makeStyles , ce que je veux savoir, c'est que puisque cela fera partie de la v5, que pouvons-nous faire pour réduire la dette technique autour du style ?

1. makeStyles sera-t-il présent dans la v5 ? Comment cela fonctionnera-t-il avec styled-components et les thèmes ? Par exemple, à quoi cela ressemblera-t-il avec styled-components :

const useStyles = makeStyles((theme) => ({
  paper: {
    padding: theme.spacing(2),
    textAlign: 'center',
    color: theme.palette.text.secondary,
  },
}));

1. (v4) Existe-t-il un meilleur moyen de récupérer l'objet theme dans une chaîne de modèle stylisée que celle-ci, afin que je puisse l'utiliser plusieurs fois ?

const StyledContainer = styled.div`
  color: ${({ theme }) => theme.palette.primary.main};
  padding: ${({ theme }) => theme.spacing(1)};
  background-color: ${({ theme }) => theme.palette.background.paper};
`;

1. En supposant makeStyles est présent dans la v5, devrions-nous nous attendre à une baisse des performances si nous utilisons à la fois le fournisseur de thème styled-components et le fournisseur de thème Material UI pour une grande base de code ?

J'adore utiliser Material UI, merci pour tout le travail acharné !

@egilsster

1. Oui, soit depuis @material-ui/styles ou react-jss, verra.
2. Oui https://material-ui.com/guides/interoperability/#theme ,

const StyledContainer = styled.div`
  ${({ theme }) => `
  color: ${theme.palette.primary.main};
  padding: ${theme.spacing(1)};
  background-color: ${theme.palette.background.paper};
  `}
`;

1. Les principaux problèmes sont 1. surcharge de configuration, coût unique, 2. chargement de deux runtimes CSS-in-JS, qui a une surcharge gzippée d'environ 15 ko, un coût similaire, par exemple, y compris Sentry : https://bundlephobia.com /result?p=@sentry/navigateur.

Merci pour une réponse rapide, très apprécié.

1. Oui material-ui.com/guides/interoperability/#theme

C'est plutôt cool. Certains outils de travail autour de l'outillage suivraient probablement cela, le projet que je migre n'utilise pas TS mais VSCode / serveur de langage ne semble pas avoir la moindre idée de ce que theme est dans ce cas et je perds styled-components la coloration syntaxique également.

Merci encore, je vais continuer à suivre cette évolution.

@oliviertassinari s'il y a une migration vers des composants stylés, cela signifiera-t-il que nous ne pouvons plus compter sur des API CSS comme <ListItem classes={{ selected: myCustomClassName}}> pour être là ?

@ jedwards1211 L'API classes restera.

D'accord. Je suis un peu confus quant à la façon dont MUI utiliserait les composants stylés en interne, car les composants stylés ne peuvent appliquer qu'une seule classe à l'élément racine.

const MyRoot = styled('div')`
  // some nice styles
`;

const MyAwesomeChild = styled('div')`
  // some nice styles
`;

export function AwesomeRoot(props) {
  return (
    <MyRoot className={props.classes?.root}>
      <MyAwesomeChild className={props.classes?.child}/>
      {props.children}
    </MyRoot>
  );
}

Est-ce que ça a du sens @jedwards1211 ?

@yordis Je sais que cela semble aussi simple, mais comment refactoriseriez-vous des sélecteurs composés comme https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/Button/Button.js #L75 ?

Je ne peux vraiment pas penser à un moyen de préserver ce comportement existant avec styled-components , donc cela pourrait entraîner plus de changements avec rupture que les gens ne le pensent.

  outlined: {
    '&$disabled': {
      border: `1px solid ${theme.palette.action.disabledBackground}`,
    },
  },

Le code existant et les remplacements personnalisés des utilisateurs dépendent probablement de la spécificité CSS dans certains cas également.

Peut être ça? Je ne suis pas sûr de suivre car cela me semble basique, il me manque probablement un peu de contexte et/ou d'informations.

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

@yordis éventuellement. Comme je l'ai dit, bien que les gens ne pensent probablement pas au nombre de changements avec rupture que cela entraînera pour les utilisateurs, je ne pense pas que cet exemple empêcherait les changements avec rupture.

Cela vous dérangerait-il de partager de vrais exemples et de réels changements potentiels ?

Il est difficile de vous suivre lorsque vous ne partagez pas de cas solides. Sur la base de vos messages, je pense que vous ne comprenez pas entièrement ce sujet, ou que je porte peut-être de mauvais jugements. Merci de m'aider à comprendre, je me trompe peut-être.

@oliviertassinari les remplacements de thème fonctionneront-ils toujours sans modification dans la v5 ? Pour que l'exemple de remplacement suivant fonctionne, il semble que MUI devrait encore appliquer des noms de classe générés par JSS en plus d'un nom de classe racine généré par styled-components .

const theme = createMuiTheme({
  overrides: {
    MuiButton: {
      root: {
        '&$disabled': {
          color: myCustomColor,
        },
      },
    },
  },
});

@yordis après y avoir réfléchi davantage, j'ai réalisé que les sélecteurs composés pour les styles passés via classes prop fonctionneraient toujours, heureusement. Pas sûr des styles de remplacement de thème cependant.

J'ai eu le plaisir d'utiliser les deux composants stylés sur MUI ainsi que le simple style MUI en utilisant style={object}.

Prenez une page de liste de résultats contenant 50 cartes, chacune avec des carrousels multimédias, des informations, des gestionnaires de clics, des boutons, etc.

L'utilisation de composants stylés a ajouté près d'une demi-seconde au temps de rendu ; par rapport à const useStyles = makeStyles ou style={object}.

Je vais devoir accepter le résultat de cette planification de feuille de route ; mais cela va certainement jeter un pli dans nos plans d'adoption de l'interface utilisateur s'il n'est pas remplaçable par quelque chose d'autre de complètement descendant.

@Icehunter pourriez-vous publier vos résultats et un exemple de projet en ligne pour que les gens puissent le consulter ?

@Icehunter pourriez-vous publier vos résultats et un exemple de projet en ligne pour que les gens puissent le consulter ?

Un exemple de projet serait difficile car il contiendrait du code propriétaire. Je publierai bientôt une image rendue et la section des résultats de synchronisation de l'onglet performances.

Prenez une page de liste de résultats contenant 50 cartes, chacune avec des carrousels multimédias, des informations, des gestionnaires de clics, des boutons, etc.

@Icehunter envoyez -vous des accessoires à ces styles ? qu'il s'agisse de 50 cartes ou de 500 cartes, le nombre de classes générées doit être le même. il semble que votre exemple spécifique contienne du code propriétaire qui ne peut pas être partagé, mais vous serait-il possible de reproduire ce problème avec du code que vous pouvez partager ?

Les API styled() / styled.div ajoutent une surcharge au rendu de _chaque_ élément, donc même avec la mise en cache des noms de classe, cela peut être plus lent. Avec makeStyles , vous pouvez attacher un groupe de styles une fois, puis appliquer manuellement les noms de classe, ce qui est souvent beaucoup plus rapide.

J'ai créé un exemple CodeSandbox pour illustrer que les solutions reposant sur des composants stylés styled peuvent être 3 à 4 fois plus lentes qu'un MUI makeStyles :

Les API styled sont agréables pour la commodité, mais je fais écho au sentiment de @Icehunter selon lequel cela peut être un problème de performances lorsqu'il est utilisé de manière intensive dans des listes/tables. C'est bien d'avoir makeStyles comme sauvegarde.

@schnerd Merci d'avoir rassemblé ces exemples, cela illustre très bien la préoccupation. Tout comme une note secondaire, pensez à préfacer le message avec, "Ce n'est pas difficile à voir ..." peut sembler condescendant et n'a pas vraiment ajouté à un ensemble d'exemples par ailleurs excellents

Excuses @tuxracer – mis à jour.

@Icehunter Je ne comprends pas ce que vous entendez par là, vous avez utilisé les styles communs avec SC ou JSS ?

@Icehunter Je ne comprends pas ce que vous entendez par là, vous avez utilisé les styles communs avec SC ou JSS ?

Les deux en fait. Nous avons fini par utiliser makeStyles mais soit cela, soit utiliser styled={object} nous a donné les mêmes résultats de performance.

Nous sommes dans un processus de migration pour obtenir de meilleures performances sur l'ensemble de la bibliothèque de composants et du site principal.

Stack sage, il est écrit dans nextjs.

Juste pour être clair (edit):

J'ai utilisé SC comme prévu, en enveloppant les composants mui. S'est avéré très lent.

Ensuite, j'ai utilisé des composants mui en utilisant makeStyles et/ou style={object} à partir d'une configuration de fichier partagé, et local (cascadage simulé). Bien plus vite.

Je ne veux pas du tout bloquer cette idée; mais si c'est par défaut; alors il devrait y avoir un moyen de remplacer globalement de haut en bas le choix par défaut et d'injecter le vôtre.

Peut être ça? Je ne suis pas sûr de suivre car cela me semble basique, il me manque probablement un peu de contexte et/ou d'informations.

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

Peut-être que je suis trop tard pour ce jeu. Mais je pense que @ jedwards1211 cherche un moyen d'exprimer cela avec SC : https://codesandbox.io/s/magical-snow-5bzd8

J'ai moi-même cela à certains endroits. Ce serait bien si c'était simple de migrer vers la v5 le jour venu

En fait, je ne sais pas comment quelque chose comme ça fonctionnera en utilisant des composants stylés.

Par exemple, si Material UI prendra en charge le remplacement des variantes par défaut de Typography à l'avenir, je suppose que JSS est plus simple que les composants stylés.

@heb-mm il y a un RFC détaillé ici que @oliviertassinari a mentionné ce fil le 7 mars.

Il m'a fallu moins d'une minute pour faire défiler vers le haut et voir la mention.

Edit : pour ceux qui se demandent, heb-mm a maintenant supprimé son commentaire.

J'ai créé un exemple CodeSandbox pour illustrer que les solutions reposant sur des composants stylés styled peuvent être 3 à 4 fois plus lentes qu'un MUI makeStyles :

@schnerd J'ai mis à jour votre benchmark pour inclure l'API interne Material-UI styled qui devrait imiter styled-components . J'ai été surpris de voir à quel point il est incroyablement lent par rapport aux autres options. Voir https://codesandbox.io/s/css-in-js-comparison-ljtjz?file=/src/App.js

Est-ce que quelqu'un sait si @emotion/styled (qui a essentiellement la même API que les composants stylés) serait tout aussi lent ? Je me demande simplement s'il y a quelque chose dans leur mise en œuvre qui pourrait être mieux optimisé.

Est-ce que quelqu'un sait si @emotion/styled (qui a essentiellement la même API que les composants stylés) serait tout aussi lent ? Je me demande simplement s'il y a quelque chose dans leur mise en œuvre qui pourrait être mieux optimisé.

https://codesandbox.io/s/css-in-js-comparison-sej1m

À peu près aussi rapide que les composants stylisés. Toujours pas aussi rapide que makeStyles. Le problème que je vois pour la plupart est la création d'objets et les différences de mise en cache/mémorisation d'objets.

Hmm, cela pourrait perturber un peu nos plans de migration vers MUI. Nous nous éloignons actuellement de styled-components en faveur du système de style Material UI après avoir rencontré beaucoup de problèmes pour gérer notre CSS, nos thèmes et nos performances. styled components était bien au début, nous avons construit notre propre solution de thème dessus, mais lorsque l'interface utilisateur s'est développée, le CSS a fait de même. Nous utilisons TypeScript, donc le fait que nous puissions facilement refactoriser un objet JS au lieu d'une chaîne CSS en ligne était un énorme argument de vente. 😕

Je suis donc assez nouveau dans Material UI et je viens également de voir la version alpha de la v5. @ldiego08 tu as dit :

Nous nous éloignons actuellement des composants stylisés au profit du système de style Material UI

J'utilise généralement des composants stylés lorsque je travaille avec React. Qu'est-ce que le système de style Material UI et quelle est la méthode recommandée pour utiliser les styles et CSS dans Material UI à l'avenir ? J'ai lu cette page et je ne sais pas si vous êtes en faveur de CSS-IN-JS ou non : https://material-ui.com/system/basics/. Je préfère généralement écrire du CSS pas dans la syntaxe objet, et j'ai apprécié les avantages de l'utilisation de CSS-IN-JS, puisque vous pouvez utiliser la "syntaxe css normale", mais aussi avoir la puissance de JS à portée de main.

Merci pour toute aide pour continuer!

Je ne sais pas pourquoi l'API des composants de style est si populaire. C'est plus lent, vous devez tout encapsuler dans un composant au lieu de simplement générer le nom de la classe. Et aussi, quel est le problème avec les littéraux de modèle balisés ? Nous ne voulions pas écrire de css dans des fichiers css, car c'est bien mieux de l'écrire en chaîne javascript ? :D La syntaxe d'objet est bien plus puissante en matière de composition et de refactorisation, etc. Pour moi, les fonctions css et cx d'émotion simples qui prennent l'objet css et renvoient le nom de la classe sont l'API la plus flexible et la plus puissante. Donc, simplement générer des noms de classe avec émotion et utiliser l'API des classes est super flexible et puissant. Donc, je ne comprends pas pourquoi vous échangeriez les performances et la flexibilité contre une "API de développement plus pratique" (pour certaines personnes, pour moi, c'est une API terrible).

Je ne sais pas pourquoi l'API des composants de style est si populaire. C'est plus lent, vous devez tout encapsuler dans un composant au lieu de simplement générer le nom de la classe. Et aussi, quel est le problème avec les littéraux de modèle balisés ? Nous ne voulions pas écrire de css dans des fichiers css, car c'est bien mieux de l'écrire en chaîne javascript ? :D La syntaxe d'objet est bien plus puissante en matière de composition et de refactorisation, etc. Pour moi, les fonctions css et cx d'émotion simples qui prennent l'objet css et renvoient le nom de la classe sont l'API la plus flexible et la plus puissante. Donc, simplement générer des noms de classe avec émotion et utiliser l'API des classes est super flexible et puissant. Donc, je ne comprends pas pourquoi vous échangeriez les performances et la flexibilité contre une "API de développement plus pratique" (pour certaines personnes, pour moi, c'est une API terrible).

J'ai eu le même souci :) peut-être que ça clarifie un peu les choses:
https://github.com/mui-org/material-ui/issues/6115#issuecomment -580449539

@martinjlowm Oui, nous sommes sur la même page :) Je pense que la façon la plus intelligente d'aller pour l'équipe d'interface utilisateur matérielle est de mettre en œuvre une sorte de solution enfichable et de ne pas coupler avec une solution css en js, laissant les gens choisir quoi utiliser et économisez une certaine taille de paquet de cette façon. Et aussi en gardant les classes et l'API createMuiTheme, car c'est la partie la plus puissante de celle-ci. Pour moi, css dans js concerne un style dynamique facile basé sur l'état des composants, la confiance lors de la refactorisation ou de la suppression de css ou de composants entiers (c'est là que l'approche objet est supérieure), les performances (ne pas télécharger un tas de styles inutilisés à partir d'un tas de feuilles de style externes) , etc. Et encore une fois, je ne comprends pas pourquoi les gens aiment écrire une chaîne avec une mise en surbrillance de l'éditeur. Je veux dire, vous devez utiliser ${} pour accéder aux accessoires à partir du contexte. Pour quelque chose de plus complexe que de définir l'arrière-plan de l'élément div, cette approche est désordonnée et illisible à mon avis. Je ne le dénigre pas, je dis simplement ce que je pense et j'essaie de prouver que tous les développeurs n'aiment pas les composants stylés, et même s'ils le faisaient, je ne vois pas en quoi c'est une bonne affaire d'échanger performances et flexibilité pour cela :)

@vdjurdjevic En effet, coupler material-ui à une solution css in js est presque une recette garantie de conflit lorsque les pratiques css-in-js se développent inévitablement dans des directions différentes.

Que diriez-vous d'un modèle d'adaptateur qui applique le style avec un fournisseur css-in-js spécifique ? Les styles eux-mêmes doivent être définis dans un format cohérent dans les packages material-ui. C'est l'application de ces styles qui est effectuée différemment par les adaptateurs correspondants.

Quelque chose du genre :

import {EmotionAdapter, StyledComponentAdapter, ThemeProvider} from "@material-ui/core/styles";
...
return 
    (<ThemeProvider theme={theme} adapter={EmotionAdapter}>
        ...
    </ThemeProvider>)

@vdjurdjevic Je suis assez d'accord avec vos réflexions sur https://github.com/mui-org/material-ui/issues/6115#issuecomment -652762320. Vous aimerez peut-être ce résumé de la direction que nous prenons que j'ai récemment partagé sur https://github.com/mui-org/material-ui/issues/16947#issuecomment -653797178.

Je ne comprends pas pourquoi les gens aiment écrire une chaîne avec un éditeur en surbrillance

Deux raisons de mon point de vue :

• Près de pourquoi nous n'écrivons pas React.createElement('div', {}) .
• Les personnes ayant une expérience limitée dans le développement Web (elles sont nombreuses) ont du mal à apprendre l'API JavaScript, cela semble plus simple avec la syntaxe CSS. Prenons l'exemple des designers, allez demander à ceux de votre équipe ce qu'ils en pensent :).
• Impossible de copier et coller entre les outils de développement et la source (je déteste celui-ci).

@oliviertassinari Ok, ce sont quelques points solides, je suis d'accord :) Mais quand même, pour moi (pas un designer, pas un débutant, un développeur senior), les composants stylés et les littéraux de modèle étiquetés ne seraient jamais une option. J'ai lu votre résumé pour la direction du développement ultérieur, et je suis heureux d'apprendre que le moteur CSS sera facultatif. Cela ne me dérange pas les composants stylés par défaut (si c'est ce que la majorité des utilisateurs aiment), tant que je peux changer cela. Et pour être honnête, je pense que je vais m'en tenir à JSS avec la v4 pour mon prochain projet, il a quelques fonctionnalités intéressantes (comme développer et composer des plugins). J'ai dû écrire un plugin stylis pour que l'émotion ait quelque chose de similaire.

PS. Je ne suis pas non plus un grand fan de JSX :) Cela devient vite compliqué, vous vous retrouvez avec du code fléché et pour les composants qui doivent afficher des éléments dynamiques, vous n'avez pas d'autre choix que d'utiliser createElement. Ne dis pas que travailler directement avec createElement est mieux, dis juste que JSX n'est pas idéal. À mon avis, Flutter a le meilleur DX, j'espère qu'il pourra bien gérer la plate-forme Web un jour.

@oliviertassinari Selon nos tests de performances en cours, comme indiqué dans https://github.com/mui-org/material-ui/issues/6115#issuecomment -643398897, j'espère juste que l'équipe matérielle ne se contentera pas de choisir des composants stylés parce qu'ils sont populaires. C'est lent. A toujours été. Personnellement, c'est un point d'être un développeur que vous devez apprendre des choses comme la notation JS de CSS.

Cela fait partie du travail.

Faciliter la vie des développeurs fait partie de notre travail en tant que mainteneurs de paquets (pour mes propres projets dont je parle), mais il y a une ligne entre le rendre facile et le rendre performant.

C'est pourquoi je n'utilise que makeStyles et je l'ai toujours fait depuis son introduction.

L'architecte de mes dernières équipes n'a pas écouté et a avancé avec des composants stylés et maintenant le site est lent. Je suis passé à makeStyles dans une branche de test et j'ai économisé 50% (10 secondes) sur TTI sur les appareils mobiles, mais comme vous l'avez dit dans ce commentaire, la notation JS n'est pas connue de tout le monde, elle n'a donc pas été acceptée.

En interne, le matériel peut choisir ce qu'il veut, mais veuillez le rendre performant par défaut.

[Question déplacée vers StackOverflow.]

@haysclark Veuillez utiliser StackOverflow pour les questions d'assistance plutôt que de les aborder sur un RFC.

@haysclark Veuillez utiliser StackOverflow pour les questions d'assistance plutôt que de les aborder sur un RFC.

@mbrookes Merci pour l'avertissement !

Est-ce que quelqu'un sait si @emotion/styled (qui a essentiellement la même API que les composants stylés) serait tout aussi lent ? Je me demande simplement s'il y a quelque chose dans leur mise en œuvre qui pourrait être mieux optimisé.

https://codesandbox.io/s/css-in-js-comparison-sej1m

À peu près aussi rapide que les composants stylisés. Toujours pas aussi rapide que makeStyles. Le problème que je vois pour la plupart est la création d'objets et les différences de mise en cache/mémorisation d'objets.

Je me demandais quelles seraient les performances du composant Box par rapport à votre profilage, et j'ai ajouté la Box de Chakra-UI pour faire bonne mesure, et les résultats ont été... surprenants :P
https://codesandbox.io/s/css-in-js-comparison-forked-mg3gx?file=/src/App.js

@Nvveen avez-vous essayé Chakra-UI v1 ? Il a été réécrit et j'espère qu'il devrait être meilleur. Il y a aussi l'émotion v11, bien qu'encore en version bêta.

@Nvveen avez-vous essayé Chakra-UI v1 ? Il a été réécrit et j'espère qu'il devrait être meilleur. Il y a aussi l'émotion v11, bien qu'encore en version bêta.

Je viens de l'essayer avec le dernier RC, mais aucune différence notable ; c'est toujours environ 1,5x à 2x plus lent que le SC ordinaire. La plus grande question pour moi est de savoir pourquoi la MUI Box est si lente.

@Nvveen avez-vous essayé Chakra-UI v1 ? Il a été réécrit et j'espère qu'il devrait être meilleur. Il y a aussi l'émotion v11, bien qu'encore en version bêta.

Je viens de l'essayer avec le dernier RC, mais aucune différence notable ; c'est toujours environ 1,5x à 2x plus lent que le SC ordinaire. La plus grande question pour moi est de savoir pourquoi la MUI Box est si lente.

Il utilise Jss. SC est au moins un peu mieux.

Sur ma machine, l'ordre dans lequel les cas de test sont exécutés a un impact sur les résultats. Comparer

1. Boîte d'abord https://codesandbox.io/s/css-in-js-comparison-forked-tqlg1?file=/src/App.js
   

2. Encadré dernier https://codesandbox.io/s/css-in-js-comparison-forked-js6th?file=/src/App.js
   

Le ramasse-miettes @oliviertassinari et le jit de la v8 en sont la cause. Mieux vaut avoir des tests isolés / séparés vraiment. Les tests ultérieurs ont un meilleur jit, mais de temps en temps, cela déclenchera une récupération de place.

Il semble qu'Emotion, SC et Chakra soient tous proches d'une performance maximale théorique lorsque chaque petit composant a ses propres styles à monter, le style MUI n'étant pas encore tout à fait optimisé. Il semble que le seul moyen d'obtenir de meilleures performances que cela soit d'avoir une feuille de style pour l'ensemble de l'arborescence des composants, comme dans makeStyles/pure CSS. Je suppose que les 30 ms supplémentaires pour l'émotion, le SC, etc. sont la surcharge inévitable de chaque petit composant devant s'assurer que ses styles sont montés.

@ jedwards1211 s'il s'agit de conserver le dx, Atlassian a créé une bibliothèque qui le compile en css, appelée compilé