Material-ui: Utiliser des composants stylés dans toutes les démos

Créé le 9 août 2019  ·  28Commentaires  ·  Source: mui-org/material-ui

Following #6115, I think that we should migrate all our demos to use the Box component or styled-component. Suite au #6115, je pense que nous devrions migrer toutes nos démos pour utiliser le composant Box ou styled-component. The goal is to hide @material-ui/styles as much as possible. Le but est de cacher @material-ui/styles autant que possible. styled-components keeps growing , a consolidation of this styling solution will be better, overall, for the React community. styled-components ne cesse de croître , une consolidation de cette solution de style sera meilleure, dans l'ensemble, pour la communauté React.

Regarding the timing, I think that we can start to use the Box component now. En ce qui concerne le timing, je pense que nous pouvons commencer à utiliser le composant Box maintenant. For the demos that we can't migrate, we probably want to wait for the first proof of concept with #6115. Pour les démos que nous ne pouvons pas migrer, nous voulons probablement attendre la première preuve de concept avec #6115.

en
docs important

Commentaire le plus utile

I dont think styled-components is a good styling solution. Je ne pense pas que styled-components soit une bonne solution de style. current solution looks much much more readable, appealing, accessible and cleaner than styled. La solution actuelle semble beaucoup plus lisible, attrayante, accessible et plus propre que stylée. i dont see any good reason to migrate. Je ne vois aucune bonne raison de migrer.

en

Tous les 28 commentaires

@oliviertassinari what is the exactly the tasks in hand? @oliviertassinari quelles sont exactement les tâches en cours ?

Here is what I understand, Voici ce que je comprends,

  1. Run the docs website Exécutez le site Web de documentation
  2. Find all the example source code that uses material-ui/styles Trouvez tous les exemples de code source qui utilisent material-ui/styles
  3. Replace them with styled-components Remplacez-les par styled-components

Is this correct? Est-ce correct?

en

@yordis I think that the timing is going to be key in this transition. @yordis Je pense que le timing va être la clé de cette transition. I would imagine the following steps: J'imagine les étapes suivantes :

  1. We replace the usage of @material-ui/styles in the demos with the Box component, where possible. Nous remplaçons l'utilisation de @material-ui/styles dans les démos par le composant Box, dans la mesure du possible. Moving #16858 at the same time would help. Déplacer #16858 en même temps aiderait. This can be done in the near future. Cela peut être fait dans un futur proche.
  2. We solve #15561, we migrate more demos away from @material-ui/styles to use the system props. Nous résolvons #15561, nous migrons plus de démos depuis @material-ui/styles pour utiliser les accessoires système. The sooner we solve this, the better. Plus tôt nous résoudrons cela, mieux ce sera.
  3. We update the customization demos to use styled-components, leveraging the global Mui class names. Nous mettons à jour les démos de personnalisation pour utiliser des composants de style, en tirant parti des noms de classe Mui globaux. We might need to work on some helpers to make accessing the theme values easier. Nous devrons peut-être travailler sur certaines aides pour faciliter l'accès aux valeurs du thème.
  4. We solve #6115, we migrate the last usages of @material-ui/styles to styled-components. On résout #6115, on migre les derniers usages de @material-ui/styles vers styled-components. This is a task for v5, I think that we can start it Q1 2020 in the v5 alpha/beta versions. C'est une tâche pour la v5, je pense que nous pouvons la démarrer Q1 2020 dans les versions v5 alpha/beta.
en

@oliviertassinari Je suis curieux, et je m'excuse si cela s'est répété : pourquoi ne pas garder @material-ui/styles comme wrapper ou abstraction pour styled-components ?

en

@ConAntonakos it's an option. @ConAntonakos c'est une option. It could help if we need to extend/normalize some of the features of styled-components. Cela pourrait aider si nous devons étendre/normaliser certaines des fonctionnalités des composants stylés.

en

@oliviertassinari est-ce qu'on a une liste de ce qu'il reste ?

en

@yordis We haven't done many efforts in this direction yet. @yordis Nous n'avons pas encore fait beaucoup d'efforts dans ce sens. However, there is a probability that it will require breaking changes, v5 is planned for around Q4 2020. I think that we should explore a partial deployment strategy for developers that want to leverage it sooner. Cependant, il est probable que cela nécessitera des changements de rupture, la v5 est prévue pour le quatrième trimestre 2020 environ. Je pense que nous devrions explorer une stratégie de déploiement partiel pour les développeurs qui souhaitent en tirer parti plus tôt. Now, this effort has to be balanced with the other priorities, like the support of new advanced components (free and paid) or the release of an unstyled version of the library to increase our audience reach (with different themes, eg iOS style). Maintenant, cet effort doit être équilibré avec les autres priorités, comme le support de nouveaux composants avancés (gratuits et payants) ou la sortie d'une version sans style de la bibliothèque pour augmenter notre audience (avec différents thèmes, par exemple le style iOS). The good news is that we will likely grow the team in the coming months, enabling us to move faster. La bonne nouvelle est que nous allons probablement agrandir l'équipe dans les mois à venir, ce qui nous permettra d'avancer plus rapidement.

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles ). J'imagine que vous utilisez déjà des composants stylés au-dessus de Material-UI aujourd'hui, comme le font de nombreux autres développeurs (et non @material-ui/styles ). What are the top pain points you hope to address with this migration? Quels sont les principaux problèmes que vous espérez résoudre avec cette migration ?

From a product perspective, our incentive is about: smaller bundle size, better performance, steaming support, fewer bugs, CSS template strings support, larger community, enables to use the system props in the core components, allow true dynamic themes and props support, better docs. Du point de vue du produit, notre incitation concerne : une taille de bundle plus petite, de meilleures performances, une prise en charge de la vapeur, moins de bogues, la prise en charge des chaînes de modèles CSS, une communauté plus large , permet d'utiliser les accessoires système dans les composants principaux, permet une véritable prise en charge dynamique des thèmes et des accessoires, meilleurs docs.

en

However, there is a high probability that it will require breaking changes, Cependant, il y a une forte probabilité que cela nécessite des changements de rupture,

Yeah, I tried to change some examples, but they require some integration with the theme provider, so we may need to inject material/style theme provider and styled-component theme provider I am assuming. Oui, j'ai essayé de changer certains exemples, mais ils nécessitent une certaine intégration avec le fournisseur de thème, nous devrons donc peut-être injecter le fournisseur de thème material/style et le fournisseur de thème styled-component je suppose.

v5 is planned for around Q4 2020. La v5 est prévue pour le quatrième trimestre 2020 environ.

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? C'est assez loin, serait-il préférable d'épingler différents enjeux de visibilité sur ce qui est prioritaire en ce moment ?

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles). J'imagine que vous utilisez déjà des composants stylés au-dessus de Material-UI aujourd'hui, comme le font de nombreux autres développeurs (et non @material-ui/styles).

Actually, I am quite happy with @material-ui/styles and I am not using styled-components when I use Material UI (I would remove withStyles since I don't want to rely on programmer discipline 😉 , but I understand legacy software may no have hooks still )🤷‍♂️ En fait, je suis assez satisfait de @material-ui/styles et je n'utilise pas styled-components lorsque j'utilise Material UI (je supprimerais withStyles car je ne veux pas compter sur la discipline du programmeur 😉, mais je comprends que les anciens logiciels n'ont peut-être pas encore de crochets) 🤷‍♂️

What are the top pain points you hope to address with this migration? Quels sont les principaux problèmes que vous espérez résoudre avec cette migration ?

I am trying to help with the migration, personally, no pain points. J'essaie d'aider à la migration, personnellement, pas de points douloureux. Unless you take into consideration that as an ecosystem, I have to maintain two ways to develop something, but meh, personally, it is okay for me. À moins que vous ne preniez en considération qu'en tant qu'écosystème, je dois maintenir deux façons de développer quelque chose, mais perso, ça me va.

Maybe styled-components fixes some interoperability with NextJS and Gatsby since the last time I tried was hard to make Mui work with those tools because of the SSR and styles (I am not sure if still painful) and most libraries using styled-components work out of the box. Peut-être que styled-components corrige une certaine interopérabilité avec NextJS et Gatsby puisque la dernière fois que j'ai essayé, il était difficile de faire fonctionner Mui avec ces outils à cause du SSR et des styles (je ne sais pas si c'est toujours douloureux) et la plupart des bibliothèques utilisant styled-components fonctionne hors de la boîte.

Let me know how I could help, like I said, I was using the pinned issues to find the prioritization of the Org Faites-moi savoir comment je pourrais aider, comme je l'ai dit, j'utilisais les problèmes épinglés pour trouver la hiérarchisation de l'Org

en

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? C'est assez loin, serait-il préférable d'épingler différents enjeux de visibilité sur ce qui est prioritaire en ce moment ?

It depends on the time horizon you are interested in. You can follow the issue with the label important , the roadmap page on the documentation and the monthly blog product updates. Cela dépend de l'horizon temporel qui vous intéresse. Vous pouvez suivre le problème avec l'étiquette important , la page de feuille de route sur la documentation et les mises à jour mensuelles du produit du blog.

I don't fully understand this point. Je ne comprends pas tout à fait ce point. Why not using styled-components when using Material-UI (today)? Pourquoi ne pas utiliser des composants de style lors de l'utilisation de Material-UI (aujourd'hui) ? We had 1/3 of our users going down this path when we did our last survey, 6 months ago. Nous avions 1/3 de nos utilisateurs qui empruntaient cette voie lors de notre dernière enquête, il y a 6 mois.

en

I don't fully understand this point. Je ne comprends pas tout à fait ce point. Why not using styled-components when using Material-UI (today)? Pourquoi ne pas utiliser des composants de style lors de l'utilisation de Material-UI (aujourd'hui) ?

@material-ui/styles works like a champ so far, no reason to migrate everything 😄 so I am one of those out of 3 that don't use it together today. @material-ui/styles fonctionne comme un champion jusqu'à présent, aucune raison de tout migrer 😄 donc je fais partie de ceux sur 3 qui ne l'utilisent pas ensemble aujourd'hui.

Thank you for the info about prioritization. Merci pour l'info sur la priorisation.

en

@yordis btw, my answer was made under the assumption you were following up on the main styled-components issue. @yordis btw, ma réponse a été faite en supposant que vous suiviez le problème principal des composants stylés. I haven't realized we were on the documentation one. Je n'avais pas réalisé que nous étions sur la documentation.

en

@oliviertassinari do you have any suggestions about the issue with theme context? @oliviertassinari avez-vous des suggestions sur le problème de contexte de thème ?

I tried to use props.theme inside an styled-components but didn't work, I am not sure if you have a suggestion for it, but I think we will require to add styled-components theme provider as well. J'ai essayé d'utiliser props.theme dans un styled-components mais cela n'a pas fonctionné, je ne sais pas si vous avez une suggestion à ce sujet, mais je pense que nous devrons ajouter styled-components fournisseur de thèmes également.

en

Hey @oliviertassinari! Salut @oliviertassinari ! Are you looking for PR's that convert the existing customization demos to use styled-components as part of this issue? Recherchez-vous des relations publiques qui convertissent les démos de personnalisation existantes pour utiliser des composants stylés dans le cadre de ce problème ?

en

I dont think styled-components is a good styling solution. Je ne pense pas que styled-components soit une bonne solution de style. current solution looks much much more readable, appealing, accessible and cleaner than styled. La solution actuelle semble beaucoup plus lisible, attrayante, accessible et plus propre que stylée. i dont see any good reason to migrate. Je ne vois aucune bonne raison de migrer.

en

I dont think styled-components is a good styling solution. Je ne pense pas que styled-components soit une bonne solution de style. current solution looks much much more readable, appealing, accessible and cleaner than styled. La solution actuelle semble beaucoup plus lisible, attrayante, accessible et plus propre que stylée. i dont see any good reason to migrate. Je ne vois aucune bonne raison de migrer.

And get almost fully typed. Et obtenez presque entièrement tapé. Don't see any reason to migrate +1 Je ne vois aucune raison de migrer +1

en

The link you've posted, that should show growing interest to styled-components, recently started showing a downward trend: Le lien que vous avez posté, qui devrait montrer un intérêt croissant pour les composants stylés, a récemment commencé à montrer une tendance à la baisse :
image

I feel that narrowing down a styling solution to a single library is going to give us the exact same problem as we have today. Je pense que limiter une solution de style à une seule bibliothèque va nous poser exactement le même problème que celui que nous avons aujourd'hui.

What about integration with zero-runtime libraries such as linaria ? Qu'en est-il de l'intégration avec des bibliothèques à exécution nulle telles que linaria ? This was suggested as being looked at in May 2019 Update . Cela a été suggéré comme étant examiné dans la mise à jour de mai 2019 .

en

So far it only recovered to pre-v5-hype. Jusqu'à présent, il n'a récupéré que le battage médiatique pré-v5. Let's see how the updated data point for January till now looks. Voyons à quoi ressemble le point de données mis à jour pour janvier jusqu'à présent.

en

@TheHolyWaffle Don't trust rank2traffic.com too much, data hasn't been very reliable nor up-to-date, its main advantage was the overall trend over 10 years (before it was made paid). @TheHolyWaffle Ne faites pas trop confiance à rank2traffic.com, les données n'ont pas été très fiables ni à jour, son principal avantage était la tendance générale sur 10 ans (avant qu'elle ne soit payée). For a shorter time window, so 6 months, prefer https://www.similarweb.com/ as more reliable. Pour une fenêtre de temps plus courte, donc 6 mois, préférez https://www.similarweb.com/ car plus fiable.
Also take into account that once people know the API, they come back much frequently to the documentation. Tenez également compte du fait qu'une fois que les gens connaissent l'API, ils reviennent très fréquemment à la documentation.

en

I dont think styled-components is a good styling solution. Je ne pense pas que styled-components soit une bonne solution de style. current solution looks much much more readable, appealing, accessible and cleaner than styled. La solution actuelle semble beaucoup plus lisible, attrayante, accessible et plus propre que stylée. i dont see any good reason to migrate. Je ne vois aucune bonne raison de migrer.

And get almost fully typed. Et obtenez presque entièrement tapé. Don't see any reason to migrate +1 Je ne vois aucune raison de migrer +1

+1 styles is the main reason we're migrating to Material UI and moving away from styled components. +1 styles est la principale raison pour laquelle nous migrons vers Material UI et nous nous éloignons des composants stylisés. It's too much CSS and refactoring it has proven to be a huge burden for us. C'est trop de CSS et sa refactorisation s'est avérée être un énorme fardeau pour nous.

en

Hi! Salut! First of all, thank you for providing a great component library, best one I've used so far. Tout d'abord, merci d'avoir fourni une excellente bibliothèque de composants, la meilleure que j'ai utilisée jusqu'à présent. Our teams have written hundreds of thousands of lines of code using the components and methodology you created and once developers learn the basics of using classes , how to write the styles etc., it's a breeze to work with even on a massive enterprise scale type of codebase. Nos équipes ont écrit des centaines de milliers de lignes de code en utilisant les composants et la méthodologie que vous avez créés et une fois que les développeurs ont appris les bases de l'utilisation de classes , comment écrire les styles, etc., c'est un jeu d'enfant de travailler même sur un type de base de code à l'échelle de l'entreprise massive.

I'm not sure if that's the most common use of your library, but I suppose you are aware that many teams build their component libraries on top of Material UI, and so any components and decision you make also trickle down to those libraries. Je ne sais pas si c'est l'utilisation la plus courante de votre bibliothèque, mais je suppose que vous savez que de nombreuses équipes construisent leurs bibliothèques de composants au-dessus de Material UI, et donc tous les composants et décisions que vous prenez se répercutent également sur ces bibliothèques. On our end we've been very happy with both performance and APIs so far. De notre côté, nous avons été très satisfaits des performances et des API jusqu'à présent.

I've been following recent development in the library and to be honest, I'm having trouble understanding some of the decisions and worried how that will affect our teams, and what's overall the benefit of this move would be, as opposed to for example forking MUI. J'ai suivi les développements récents dans la bibliothèque et pour être honnête, j'ai du mal à comprendre certaines des décisions et je m'inquiète de la façon dont cela affectera nos équipes, et quel serait l'avantage global de ce déménagement, par opposition à par exemple bifurquer MUI. Others have voiced their concern about move to styled components so I'll focus on the other one for me - the Box component. D'autres ont exprimé leur inquiétude quant au passage à des composants stylés, je vais donc me concentrer sur l'autre pour moi - le composant Box.

I understand the utility of a Box component - to make it possible to use theme variables etc. in prop values, however the API and the consequences of using this component disqualify it from something I could recommend to our teams. Je comprends l'utilité d'un composant Box - pour permettre d'utiliser des variables de thème, etc. dans les valeurs de prop, mais l'API et les conséquences de l'utilisation de ce composant le disqualifient de quelque chose que je pourrais recommander à nos équipes.

First , it has a cryptic API for no reason I can discern (unless saving a few bytes is that reason): Instead of writing <Box margin={3} /> , it would be <Box m={3} /> . Tout d'abord, il a une API cryptique sans raison que je puisse discerner (à moins que cette raison ne sauve quelques octets): Au lieu d'écrire <Box margin={3} /> , ce serait <Box m={3} /> .

Abbreviations like that seem needless, make things potentially ambigious, and introdue a new learning curve to developers, a mapping of abbreviations to actual properties they now need to memorize: "Is applying color done using c or color ?", "Is background a b , or bg , or background , or was b a border ?" De telles abréviations semblent inutiles, rendent les choses potentiellement ambiguës et introduisent une nouvelle courbe d'apprentissage pour les développeurs, un mappage des abréviations sur les propriétés réelles qu'ils doivent maintenant mémoriser : "Est-ce color est appliqué en utilisant c ou color ?", "Est-ce background est un b , ou bg , ou background , ou était b un border ?" "Is background-size abbreviated as bs ?" "Est-ce background-size est abrégé en bs ?"

Second , components abstract most commonly recurring UI patterns, and create APIs that provide means of customizing those patterns to the extent that the design system permits. Deuxièmement , les composants résument les modèles d'interface utilisateur les plus récurrents et créent des API qui permettent de personnaliser ces modèles dans la mesure où le système de conception le permet. This manifests in creating props like gutterBottom on Typography , or dense on ListItem - as opposed to accepting just about any padding or margin. Cela se manifeste par la création d'accessoires comme gutterBottom sur Typography ou dense sur ListItem - au lieu d'accepter à peu près n'importe quel rembourrage ou marge. I feel like introducing Box to large extent undermines this effort and introduces a tool that will make a mess out of any attempt to follow a design system unless we define some very nitpicky ways that Box component can be used for and spend effort in code reviews to make sure the all the values in used Box props aren't beyond the accepted list. J'ai l'impression que l'introduction Box sape dans une large mesure cet effort et introduit un outil qui gâchera toute tentative de suivre un système de conception à moins que nous ne définissions des façons très délicates d'utiliser et de dépenser le composant Box effort dans les révisions de code pour s'assurer que toutes les valeurs dans les accessoires Box utilisés ne sont pas au-delà de la liste acceptée. And at that point, the way to "automate" this would be to create a component that restricts the options, and we're backt to square one. Et à ce stade, la façon "d'automatiser" cela serait de créer un composant qui restreint les options, et nous sommes de retour à la case départ. To give an example, why would using Box mb={2} to achieve margin under Typography be okay, but Box mb={6} not? Pour donner un exemple, pourquoi utiliser Box mb={2} pour obtenir une marge sous Typographie serait-il acceptable, mais pas Box mb={6} ? This concern doesn't exist when we can rely on props to limit the options. Cette préoccupation n'existe pas lorsque nous pouvons compter sur des accessoires pour limiter les options.

Third concern, or rather a question I have. Troisième préoccupation, ou plutôt une question que j'ai. Since the Box component is potentially a quick way to build certain functionality, it would be also used by libraries built on top of MUI. Étant donné que le composant Box est potentiellement un moyen rapide de créer certaines fonctionnalités, il serait également utilisé par les bibliothèques construites au-dessus de MUI. How would one override the styles of Box components used within another component? Comment remplacer les styles des composants Box utilisés dans un autre composant ? As an example. Par exemple. If we built ListItem using Box under the hood, would we need to introduce BoxProps={{ padding: 2 }} , or accept also dense prop based on which we write logic to apply a padding prop to a particular Box, or still something else? Si nous avons construit ListItem en utilisant Box sous le capot, devrions-nous introduire BoxProps={{ padding: 2 }} , ou accepter également dense prop basé sur lequel nous écrivons la logique pour appliquer un prop padding à un Box en particulier, ou encore autre chose ?

en

I'm not sure if that's the most common use of your library, but I suppose you are aware that many teams build their component libraries on top of Material UI , and so any components and decision you make also trickle down to those libraries. Je ne sais pas si c'est l'utilisation la plus courante de votre bibliothèque, mais je suppose que vous savez que de nombreuses équipes construisent leurs bibliothèques de composants au-dessus de Material UI , et donc tous les composants et décisions que vous prenez se répercutent également sur ces bibliothèques. On our end we've been very happy with both performance and APIs so far. De notre côté, nous avons été très satisfaits des performances et des API jusqu'à présent.

@maciej-gurban This use case is an important one for us. @maciej-gurban Ce cas d'utilisation est important pour nous. Our incentives are aligned to significantly improve it. Nos incitations sont alignées pour l'améliorer de manière significative. This is one of our objectives with v5. C'est l'un de nos objectifs avec la v5.

For instance, we are investigating the feasibility to provide a design tool that could be put in the hands of designers (paid) and would output ready to use customized Material-UI components (MIT), corresponding documentation, Sketch & Figma kit. Par exemple, nous étudions la faisabilité de fournir un outil de conception qui pourrait être mis entre les mains des concepteurs (payés) et produirait des composants Material-UI personnalisés (MIT) prêts à l'emploi, la documentation correspondante, le kit Sketch & Figma. Basically, all we have been going it for Material Design but scaling it 🚀. Fondamentalement, tout ce que nous avons fait pour Material Design, mais en le mettant à l'échelle 🚀.
The end goal here would be to free the time of a couple of front-end developers in each company. L'objectif final ici serait de libérer le temps de quelques développeurs front-end dans chaque entreprise. Why have front-end developers build a custom design system when it can be done by your own designers + Material-UI at a fraction of the cost? Pourquoi les développeurs front-end créent-ils un système de conception personnalisé alors que cela peut être fait par vos propres concepteurs + Material-UI à une fraction du coût ? + reduce risk and have your front-end developers spend time where they make the most differences: working on the product. + réduisez les risques et laissez vos développeurs front-end passer du temps là où ils font le plus de différence : travailler sur le produit.

I'm having trouble understanding some of the decisions and worried how that will affect our teams J'ai du mal à comprendre certaines décisions et je m'inquiète de l'impact que cela aura sur nos équipes

If you could list them, it would be awesome. Si vous pouviez les énumérer, ce serait génial.

Others have voiced their concern about move to styled components D'autres ont exprimé leur inquiétude quant au passage à des composants stylisés

What's your concern with such a shift? Quelle est votre préoccupation avec un tel changement? Our objective on the styling side has a couple of layer: Notre objectif côté style comporte plusieurs couches :

  1. Unstyled component, expose the same existing components but without any styles. Composant sans style, expose les mêmes composants existants mais sans aucun style. Keep the same classes API (first seen in jQuery-UI), provide default hardcoded values for each of the classes (global class names). Conservez la même API classes (vue pour la première fois dans jQuery-UI), fournissez des valeurs codées en dur par défaut pour chacune des classes (noms de classe globaux). The objective behind this shift answer to a couple of incentives. L'objectif derrière ce changement répond à quelques incitations. First, it's to dismiss a fear our users have, same to CRA eject mode, you won't use it but it feels safe to be present. Tout d'abord, c'est pour écarter une crainte que nos utilisateurs ont, comme pour le mode d'éjection CRA, vous ne l'utiliserez pas mais vous vous sentirez en sécurité d'être présent. Second, it's required to be able to build the paid design tool. Deuxièmement, il est nécessaire de pouvoir créer l'outil de conception payant. Third, it's required for the next layer Troisièmement, il est requis pour la couche suivante
  2. Multiple style engines. Plusieurs moteurs de style. The community is fragmented between different styling approaches. La communauté est fragmentée entre différentes approches de style. By order of popularity: styled-components, plain CSS, CSS modules, emotion, JSS, utility first classes. Par ordre de popularité : composants stylés, CSS simple, modules CSS, émotion, JSS, premières classes utilitaires. It still feels like we didn't find the holy grail for styling. On a toujours l'impression que nous n'avons pas trouvé le Saint Graal pour le style. And until we do, better not bet too much on any styling solution. Et jusqu'à ce que nous le fassions, mieux vaut ne pas trop miser sur une solution de style. So, have styled-components has the default, but allow developers to switch engine, stay on JSS if they are happy too. Ainsi, avoir des composants de style a la valeur par défaut, mais permet aux développeurs de changer de moteur, restez sur JSS s'ils sont également satisfaits.
  3. Baseline theme. Thème de base. Something less opinionated than the current default Material Desing Theme, but using the same theme's specification. Quelque chose de moins opiniâtre que le thème de conception de matériel par défaut actuel, mais en utilisant les mêmes spécifications de thème.
  4. A couple of different themes on top of the baseline. Quelques thèmes différents en plus de la ligne de base. One for marketing pages, One for the Chinese market (close to the Gmail equivalent of China). Un pour les pages marketing, Un pour le marché chinois (proche de l'équivalent Gmail de la Chine).

I'll focus on the other one for me - the Box component. Je vais me concentrer sur l'autre pour moi - le composant Box.

Yeah, I can hear you! Ouais, je peux t'entendre ! I have been working with @gregberge in the past. J'ai travaillé avec @gregberge dans le passé. At some point, we have considered hiding all the className props on @doctolib 's design system. À un moment donné, nous avons envisagé de masquer toutes les props className sur le système de conception de @doctolib . The interesting thought is that you can gain features (properties) in exchange of more constraints. L'idée intéressante est que vous pouvez gagner des fonctionnalités (propriétés) en échange de plus de contraintes.

I wouldn't worry too much about this one. Je ne m'inquiéterais pas trop pour celui-ci. This can be resolved with a global option to limit the access to the "system"'s features or an eslint rule. Cela peut être résolu avec une option globale pour limiter l'accès aux fonctionnalités du "système" ou une règle eslint.

en

The abbreviation on the Box component is confusing. L'abréviation sur le composant Box prête à confusion. Code is being read more than being written, so it's important to keep clear what the code is meaning. Le code est plus lu qu'écrit, il est donc important de garder clairement la signification du code. Last day I found "Box py={2}" in our codebase and I'm totally confused. Le jour dernier, j'ai trouvé "Box py={2}" dans notre base de code et je suis totalement confus. After a search I figured out that means "paddingY". Après une recherche, j'ai compris que cela signifiait "paddingY". Those abbreviation should not be encouraged especially non-css properties (I can guess pt means padding-top but not for py) Ces abréviations ne doivent pas être encouragées, en particulier les propriétés non CSS (je peux supposer que pt signifie padding-top mais pas pour py)

en

@oliviertassinari Thanks for your patience @oliviertassinari Merci pour votre patience

I'm having trouble understanding some of the decisions and worried how that will affect our teams J'ai du mal à comprendre certaines décisions et je m'inquiète de l'impact que cela aura sur nos équipes

If you could list them, it would be awesome. Si vous pouviez les énumérer, ce serait génial.

I wouldn't want this to turn into a litany of things I disagree with, because ultimately you're the guys who maintain this library and our view of what makes sense will be shaped by our own needs which might and likely don't always align, and that's fine. Je ne voudrais pas que cela se transforme en une litanie de choses avec lesquelles je ne suis pas d'accord, car en fin de compte, vous êtes les gars qui maintiennent cette bibliothèque et notre vision de ce qui a du sens sera façonnée par nos propres besoins qui pourraient et ne le sont probablement pas toujours aligner, et c'est très bien. I'm not against introducing the means of using other styling solutions - in fact I think it's great as it will bring more users who were holding off because of their dislike for JSS, but there's also us - the already existing users of your library who are sold on your solution, and if possible, would like to avoid massive refactor. Je ne suis pas contre l'introduction des moyens d'utiliser d'autres solutions de style - en fait, je pense que c'est génial car cela amènera plus d'utilisateurs qui attendaient à cause de leur aversion pour JSS, mais il y a aussi nous - les utilisateurs déjà existants de votre bibliothèque qui sont vendus sur votre solution, et si possible, aimeraient éviter une refactorisation massive.

Even if you decide that "we still provide support for JSS", refactoring all demos and your components to styled components will force the teams using JSS to migrate to styled components. Même si vous décidez que "nous fournissons toujours un support pour JSS", la refactorisation de toutes les démos et de vos composants en composants stylés obligera les équipes utilisant JSS à migrer vers des composants stylés. "Why are we still using X, when MUI team moved to Y?" "Pourquoi utilisons-nous encore X, alors que l'équipe MUI est passée à Y ?" - will be one of the many questions in light of which it would be really hard not to agree with needing to make that migration sooner or later. - sera l'une des nombreuses questions à la lumière desquelles il serait vraiment difficile de ne pas être d'accord avec la nécessité de faire cette migration tôt ou tard.

I can definitely empathize with wanting to reach a wider audience by using a styling solution that's more popular. Je peux certainement comprendre le fait de vouloir toucher un public plus large en utilisant une solution de style plus populaire. However, I think it's worth considering that "popular" is not always "best" and that a move to a different tech needs onsideration not only of advantages and disadvantages of both solution, but the context in which we're making the decision. Cependant, je pense qu'il vaut la peine de considérer que "populaire" n'est pas toujours "meilleur" et qu'un passage à une technologie différente nécessite de prendre en compte non seulement les avantages et les inconvénients des deux solutions, mais aussi le contexte dans lequel nous prenons la décision.

Starting fresh, looking merely at advantages of X over Y makes sense, but working on an already existing system we also need to consider the cost of switching over and domino effects this bring on downstream teams. Commencer à zéro, regarder simplement les avantages de X sur Y est logique, mais en travaillant sur un système déjà existant, nous devons également tenir compte du coût du basculement et des effets domino que cela entraîne sur les équipes en aval. For this switch over to make sense the advantanges of the other solution need to outweight the cost of migrating over. Pour que ce basculement ait un sens, les avantages de l'autre solution doivent l'emporter sur le coût de la migration. It seems that for your team, that cost benefit analysis rules in favor of styled components, but from what I can tell looking at reactions at posts talking about styled components in your repo, your user base is far from the same conclusion. Il semble que pour votre équipe, cette analyse coûts-avantages soit en faveur des composants stylés, mais d'après ce que je peux dire en regardant les réactions aux messages parlant de composants stylés dans votre dépôt, votre base d'utilisateurs est loin d'avoir la même conclusion.

Like you said, your aim is to open up MUI to more styling solutions. Comme vous l'avez dit, votre objectif est d'ouvrir MUI à davantage de solutions de style. To provide good support for those solutions, there would need to be good documentation, examples and smooth integration layer - otherwise developers would find it hard to translate what they see in demos into what their styling solution of choice needs. Pour fournir un bon support pour ces solutions, il faudrait une bonne documentation, des exemples et une couche d'intégration fluide - sinon les développeurs auraient du mal à traduire ce qu'ils voient dans les démos en ce dont leur solution de style de choix a besoin. I'm just not sure if you really need to migrate to styled components to achieve the goals. Je ne sais pas si vous avez vraiment besoin de migrer vers des composants stylés pour atteindre les objectifs. Seems like your solution is also perfectly capable, if not more so than others, to build the design tool you're after since you already use actual JS object for all the styles. Il semble que votre solution soit également parfaitement capable, sinon plus que d'autres, de créer l'outil de conception que vous recherchez puisque vous utilisez déjà un objet JS réel pour tous les styles.

en

One question I have, does this mean that the core of Mui would still use jss, and this allows for a better way to use styled components on top of that? Une question que j'ai, cela signifie-t-il que le noyau de Mui utiliserait toujours jss, et cela permet une meilleure façon d'utiliser des composants stylés en plus de cela? Or would there be a way to say the core is also styled? Ou y aurait-il un moyen de dire que le noyau est également stylé? I just think it would add a lot of bloat if you have two css in js solutions. Je pense juste que cela ajouterait beaucoup de ballonnement si vous avez deux solutions css en js.

en

How would theming work if using styled-components? Comment le thème fonctionnerait-il si vous utilisiez des composants stylés ? I used to use helpers in the CSS portion, and it was really messy. J'avais l'habitude d'utiliser des aides dans la partie CSS, et c'était vraiment désordonné. For me, the approach of applying theme props in a JS object is a lot cleaner than in a templated string. Pour moi, l'approche consistant à appliquer des accessoires de thème dans un objet JS est beaucoup plus propre que dans une chaîne de modèles.

en

For me (scientific backend programmer by origin), MUI styles bring beautiful, calming, predictable, parameterisable logic to the mental, crazy, bonkers-rules why-the-hell tearing-hair-out world of CSS. Pour moi (programmeur backend scientifique d'origine), les styles MUI apportent une logique magnifique, apaisante, prévisible et paramétrable au monde mental, fou et dingue des règles pourquoi diable s'arracher les cheveux du monde CSS.

The styles library (and its tight integration with the theme) is the main reason I mandate use of MUI over any other components library in the two organisations I oversee tech for - it takes all the css agony away! La bibliothèque de styles (et son intégration étroite avec le thème) est la principale raison pour laquelle j'impose l'utilisation de MUI sur toute autre bibliothèque de composants dans les deux organisations pour lesquelles je supervise la technologie - cela enlève toute l'agonie CSS ! At first, all the developers I work with are like "what the hell's going on? Where's the css? Just give me css!!" Au début, tous les développeurs avec qui je travaille me disent "qu'est-ce qui se passe ? Où est le css ? Donnez-moi juste du css !!" and then they're like "Ohhhh. riiight. Got it. Magic." et puis ils sont comme "Ohhhh. riiight. Compris. Magique."

In the longer term I think the current approach is going to become ever more powerful as the world moves to low/no code solutions (eg like sketch or figma, but outputting an actual routed app and set of components rather than a set of wireframes) - having styles expressed as an object unlocks the ability to introspect that - and create more new features in such an environment (like provision of a schema enabling direct use of MUI components within a CMS, or generation of 'theme from this' and hundreds I haven't thought of yet). À plus long terme, je pense que l'approche actuelle va devenir de plus en plus puissante à mesure que le monde évolue vers des solutions à code faible/sans code (par exemple, comme sketch ou figma, mais en produisant une application routée réelle et un ensemble de composants plutôt qu'un ensemble de wireframes) - avoir des styles exprimés en tant qu'objet débloque la capacité d'introspecter cela - et de créer plus de nouvelles fonctionnalités dans un tel environnement (comme la fourniture d'un schéma permettant l'utilisation directe des composants MUI dans un CMS, ou la génération d'un "thème à partir de ceci" et de centaines I pas encore pensé).

Moving back to the more raw-css kind of approach of styled-components doesn't preclude that - but it does make a lot of things (particularly parameterisation on the theme) a lot jankier and frustrating to achieve, and still requires much more in-depth knowledge of CSS's technicalities making it less accessible to new programmers and creative types alike. Revenir au type d'approche plus raw-css de styled-components n'empêche pas cela - mais cela rend beaucoup de choses (en particulier la paramétrisation sur le thème) beaucoup plus folles et frustrantes à réaliser, et nécessite toujours une connaissance beaucoup plus approfondie des aspects techniques de CSS, ce qui le rend moins accessible aux nouveaux programmeurs et aux types créatifs.

On the evolution of the state-of-the-art, I think styled-components has become really popular because it's a great step in the right direction from where the world was (which is why it became popular). En ce qui concerne l'évolution de l'état de l'art, je pense que styled-components est devenu vraiment populaire parce que c'est un grand pas dans la bonne direction par rapport à l'endroit où se trouvait le monde (c'est pourquoi il est devenu populaire). But the existing MUI styles system is the next step on from that; Mais le système de styles MUI existant est la prochaine étape à partir de cela ; not an incorrect side-step. pas un pas de côté incorrect. Once everyone's migrated to styled-components then the question will be "wait: why on earth are we doing this with these weird raw strings in our components...?" Une fois que tout le monde aura migré vers les composants stylés, la question sera "attendez : pourquoi diable faisons-nous cela avec ces chaînes brutes étranges dans nos composants... ?"

Maybe I'm totally wrong, but for my $0.02, I'm begging you to stay the course for at least another major version :) Peut-être que je me trompe totalement, mais pour mes 0,02 $, je vous supplie de garder le cap pour au moins une autre version majeure :)

en

@thclark your main concern seems to be with the CSS template string syntax vs the JavaScript style object API. @thclark votre principale préoccupation semble être la syntaxe de chaîne de modèle CSS par rapport à l'API d'objet de style JavaScript. Is this accurate? Est-ce exact ? It also seems to be the concern with most of the other comments of the thread. Cela semble également être le problème avec la plupart des autres commentaires du fil.

Styled-components and emotions support both APIs. Les composants de style et les émotions prennent en charge les deux API. This wasn't the main purpose of the issue. Ce n'était pas le but principal du problème. The objective of this issue was to anticipate the migration to a different styling solution. L'objectif de ce numéro était d'anticiper la migration vers une autre solution de style. However, we never move forward with "use styled-components in all the demos even if we didn't migrate the core engine". Cependant, nous n'avançons jamais avec "utiliser des composants stylés dans toutes les démos même si nous n'avons pas migré le moteur principal". We have opted for keeping both synchronized. Nous avons choisi de garder les deux synchronisés.
At this point, keeping the issue open doesn't add much value outside triggering discussions like this one :). À ce stade, garder le problème ouvert n'ajoute pas beaucoup de valeur en dehors du déclenchement de discussions comme celle-ci :). We have to migrate the demos anyway for #22342. Nous devons quand même migrer les démos pour #22342.

I personally prefer the JavaScript API over the CSS string one because: Personnellement, je préfère l'API JavaScript à la chaîne CSS car :

  • It doesn't ask for another linter/formater. Il ne demande pas un autre linter/formateur.
  • I'm used to it. J'en ai l'habitude.
  • It plays nicely with TypeScript. Il joue bien avec TypeScript.

However, it's unclear what the community, at large, will enjoy using most. Cependant, on ne sait pas ce que la communauté, dans son ensemble, appréciera le plus. CSS template has its advantages too. Le modèle CSS a aussi ses avantages. It's easier to copy & paste code between the browser and the code. Il est plus facile de copier et coller du code entre le navigateur et le code. A lot more people (overall: designers, developers, etc.) are familiar with the approach. Beaucoup plus de personnes (dans l'ensemble : concepteurs, développeurs, etc.) connaissent l'approche.

To be noted that I think that we should use the style utilities as much as possible in the demos with v5. A noter que je pense qu'il faut utiliser au maximum les utilitaires de style dans les démos avec la v5.

@mnajdova any thoughts on the matter? @mnajdova des réflexions à ce sujet ? Maybe it's worth asking the community on a poll. Peut-être que cela vaut la peine de demander à la communauté un sondage.

en

@oliviertassinari succinctly put, as usual. @oliviertassinari succinctement, comme d'habitude. Yes, my main concern is retaining the Javascript API. Oui, ma principale préoccupation est de conserver l'API Javascript. Honestly, I wasn't aware that styled-components retained that, as all of the examples I came across seem to be css templated. Honnêtement, je ne savais pas que les composants stylés conservaient cela, car tous les exemples que j'ai rencontrés semblent être des modèles CSS.

That perhaps moots most of my points above. Cela soulève peut-être la plupart de mes points ci-dessus. Nevertheless, glad you didn't move across - and thanks for your and the team's continued efforts here. Néanmoins, heureux que vous n'ayez pas traversé - et merci pour vos efforts continus et ceux de l'équipe ici. I've built things I never could have without MUI existing. J'ai construit des choses que je n'aurais jamais pu avoir sans MUI.

en

This issue is being resolved in v5. Ce problème est en cours de résolution dans la v5. We have migrated the documentation of the slider to the new approach: https://next.material-ui.com/components/slider-styled/. Nous avons migré la documentation du slider vers la nouvelle approche : https://next.material-ui.com/components/slider-styled/. We use the sx prop anytime simple CSS are necessary then use the styled API for more heavy customizations. Nous utilisons l'accessoire sx chaque fois que des CSS simples sont nécessaires, puis utilisons l'API styled pour des personnalisations plus lourdes. I believe the previous concern raised have been handled, if not, please comment :). Je crois que la préoccupation précédente a été traitée, sinon, veuillez commenter :).

en
Cette page vous a été utile?
0 / 5 - 0 notes