Material-ui: Use componentes con estilo en todas las demostraciones

@oliviertassinari what is the exactly the tasks in hand? @oliviertassinari ¿cuáles son exactamente las tareas en cuestión?

Here is what I understand, Esto es lo que entiendo,

1. Run the docs website Ejecute el sitio web de documentos
2. Find all the example source code that uses material-ui/styles Encuentre todo el código fuente de ejemplo que usa material-ui/styles
3. Replace them with styled-components Reemplácelos con styled-components

Is this correct? ¿Es esto correcto?

@yordis I think that the timing is going to be key in this transition. @yordis Creo que el momento será clave en esta transición. I would imagine the following steps: Me imagino los siguientes pasos:

1. We replace the usage of @material-ui/styles in the demos with the Box component, where possible. Reemplazamos el uso de @material-ui/styles en las demostraciones con el componente Box, siempre que sea posible. Moving #16858 at the same time would help. Mover #16858 al mismo tiempo ayudaría. This can be done in the near future. Esto se puede hacer en un futuro próximo.
2. We solve #15561, we migrate more demos away from @material-ui/styles to use the system props. Resolvemos #15561, migramos más demostraciones lejos de @material-ui/styles para usar los accesorios del sistema. The sooner we solve this, the better. Cuanto antes resolvamos esto, mejor.
3. We update the customization demos to use styled-components, leveraging the global Mui class names. Actualizamos las demostraciones de personalización para usar componentes con estilo, aprovechando los nombres de clases globales de Mui. We might need to work on some helpers to make accessing the theme values easier. Es posible que debamos trabajar en algunos ayudantes para facilitar el acceso a los valores del tema.
4. We solve #6115, we migrate the last usages of @material-ui/styles to styled-components. Resolvemos #6115, migramos los últimos usos de @material-ui/styles a componentes con estilo. This is a task for v5, I think that we can start it Q1 2020 in the v5 alpha/beta versions. Esta es una tarea para v5, creo que podemos comenzarla en el primer trimestre de 2020 en las versiones v5 alfa/beta.

@oliviertassinari Tengo curiosidad y me disculpo si esto se repitió: ¿por qué no mantener @material-ui/styles como envoltorio o abstracción para styled-components ?

@ConAntonakos it's an option. @ConAntonakos es una opción. It could help if we need to extend/normalize some of the features of styled-components. Podría ayudar si necesitamos extender/normalizar algunas de las características de los componentes con estilo.

@oliviertassinari tenemos una lista de lo que queda?

@yordis We haven't done many efforts in this direction yet. @yordis Todavía no hemos hecho muchos esfuerzos en esta dirección. 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. Sin embargo, existe la probabilidad de que requiera cambios importantes, la v5 está planificada para alrededor del cuarto trimestre de 2020. Creo que deberíamos explorar una estrategia de implementación parcial para los desarrolladores que quieran aprovecharla antes. 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). Ahora, este esfuerzo debe equilibrarse con otras prioridades, como el soporte de nuevos componentes avanzados (gratuitos y de pago) o el lanzamiento de una versión sin estilo de la biblioteca para aumentar el alcance de nuestra audiencia (con diferentes temas, por ejemplo, estilo iOS). The good news is that we will likely grow the team in the coming months, enabling us to move faster. La buena noticia es que probablemente haremos crecer el equipo en los próximos meses, lo que nos permitirá avanzar más rápido.

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles ). Me imagino que ya está utilizando componentes con estilo además de Material-UI hoy como lo hacen muchos otros desarrolladores (y no @material-ui/styles ). What are the top pain points you hope to address with this migration? ¿Cuáles son los principales puntos débiles que espera abordar con esta migración?

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. Desde la perspectiva del producto, nuestro incentivo se trata de: tamaño de paquete más pequeño, mejor rendimiento, compatibilidad con Steaming, menos errores, compatibilidad con cadenas de plantillas CSS, comunidad más grande , permite usar los accesorios del sistema en los componentes principales, permitir temas verdaderamente dinámicos y compatibilidad con accesorios, mejores documentos.

However, there is a high probability that it will require breaking changes, Sin embargo, existe una alta probabilidad de que requiera cambios de última hora,

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. Sí, traté de cambiar algunos ejemplos, pero requieren cierta integración con el proveedor de temas, por lo que es posible que debamos inyectar material/style proveedor de temas y styled-component proveedor de temas, supongo.

v5 is planned for around Q4 2020. v5 está planeado para alrededor del cuarto trimestre de 2020.

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? Eso es lo suficientemente lejos, ¿sería mejor fijar diferentes problemas para la visibilidad de lo que es una prioridad en este momento?

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles). Me imagino que ya está utilizando componentes con estilo además de Material-UI hoy como lo hacen muchos otros desarrolladores (y no @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 realidad, estoy muy contento con @material-ui/styles y no estoy usando styled-components cuando uso Material UI (quitaría withStyles ya que no quiero depender de la disciplina del programador 😉, pero entiendo que el software heredado puede no tener ganchos todavía) 🤷‍♂️

What are the top pain points you hope to address with this migration? ¿Cuáles son los principales puntos débiles que espera abordar con esta migración?

I am trying to help with the migration, personally, no pain points. Estoy tratando de ayudar con la migración, personalmente, sin puntos débiles. 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. A menos que tengas en cuenta que, como ecosistema, tengo que mantener dos formas de desarrollar algo, pero meh, personalmente, está bien para mí.

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. Tal vez styled-components arregle algo de interoperabilidad con NextJS y Gatsby, ya que la última vez que lo intenté fue difícil hacer que Mui funcionara con esas herramientas debido al SSR y los estilos (no estoy seguro si todavía es doloroso) y la mayoría de las bibliotecas usan styled-components trabajo fuera de la caja.

Let me know how I could help, like I said, I was using the pinned issues to find the prioritization of the Org Déjame saber cómo podría ayudar, como dije, estaba usando los problemas anclados para encontrar la priorización de la organización.

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? Eso es lo suficientemente lejos, ¿sería mejor fijar diferentes problemas para la visibilidad de lo que es una prioridad en este momento?

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. Depende del horizonte de tiempo que le interese. Puede seguir el problema con la etiqueta important , la página de hoja de ruta en la documentación y las actualizaciones mensuales del producto del blog.

I don't fully understand this point. No entiendo completamente este punto. Why not using styled-components when using Material-UI (today)? ¿Por qué no usar componentes con estilo al usar Material-UI (hoy)? We had 1/3 of our users going down this path when we did our last survey, 6 months ago. Teníamos 1/3 de nuestros usuarios siguiendo este camino cuando hicimos nuestra última encuesta, hace 6 meses.

I don't fully understand this point. No entiendo completamente este punto. Why not using styled-components when using Material-UI (today)? ¿Por qué no usar componentes con estilo al usar Material-UI (hoy)?

@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 funciona como un campeón hasta ahora, no hay razón para migrar todo 😄 así que soy uno de los 3 que no lo usan juntos hoy.

Thank you for the info about prioritization. Gracias por la información sobre la priorización.

@yordis btw, my answer was made under the assumption you were following up on the main styled-components issue. @yordis por cierto, mi respuesta se hizo bajo el supuesto de que estaba siguiendo el problema principal de los componentes de estilo. I haven't realized we were on the documentation one. No me he dado cuenta de que estábamos en la documentación.

@oliviertassinari do you have any suggestions about the issue with theme context? @oliviertassinari , ¿tiene alguna sugerencia sobre el tema del contexto?

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. Traté de usar props.theme dentro de styled-components pero no funcionó, no estoy seguro de si tiene alguna sugerencia, pero creo que necesitaremos agregar styled-components proveedor de temas también.

Hey @oliviertassinari! Hola @oliviertassinari! Are you looking for PR's that convert the existing customization demos to use styled-components as part of this issue? ¿Está buscando relaciones públicas que conviertan las demostraciones de personalización existentes para usar componentes con estilo como parte de este problema?

I dont think styled-components is a good styling solution. No creo que styled-components sea una buena solución de diseño. current solution looks much much more readable, appealing, accessible and cleaner than styled. La solución actual se ve mucho más legible, atractiva, accesible y más limpia que el estilo. i dont see any good reason to migrate. No veo ninguna buena razón para migrar.

I dont think styled-components is a good styling solution. No creo que styled-components sea una buena solución de diseño. current solution looks much much more readable, appealing, accessible and cleaner than styled. La solución actual se ve mucho más legible, atractiva, accesible y más limpia que el estilo. i dont see any good reason to migrate. No veo ninguna buena razón para migrar.

And get almost fully typed. Y obtener casi completamente mecanografiado. Don't see any reason to migrate +1 No veo ninguna razón para migrar +1

The link you've posted, that should show growing interest to styled-components, recently started showing a downward trend: El enlace que ha publicado, que debería mostrar un interés creciente por los componentes con estilo, recientemente comenzó a mostrar una tendencia a la baja:

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. Siento que reducir una solución de estilo a una sola biblioteca nos dará exactamente el mismo problema que tenemos hoy.

What about integration with zero-runtime libraries such as linaria ? ¿Qué pasa con la integración con bibliotecas de tiempo de ejecución cero como linaria ? This was suggested as being looked at in May 2019 Update . Se sugirió que esto se analizó en la actualización de mayo de 2019 .

So far it only recovered to pre-v5-hype. Hasta ahora solo se recuperó a la exageración anterior a v5. Let's see how the updated data point for January till now looks. Veamos cómo se ve el punto de datos actualizado de enero hasta ahora.

@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 No confíes demasiado en rank2traffic.com, los datos no han sido muy confiables ni actualizados, su principal ventaja fue la tendencia general durante 10 años (antes de que se pagara). For a shorter time window, so 6 months, prefer https://www.similarweb.com/ as more reliable. Para una ventana de tiempo más corta, por ejemplo, 6 meses, prefiera https://www.similarweb.com/ como más confiable.
Also take into account that once people know the API, they come back much frequently to the documentation. También tenga en cuenta que una vez que las personas conocen la API, regresan con mucha frecuencia a la documentación.

I dont think styled-components is a good styling solution. No creo que styled-components sea una buena solución de diseño. current solution looks much much more readable, appealing, accessible and cleaner than styled. La solución actual se ve mucho más legible, atractiva, accesible y más limpia que el estilo. i dont see any good reason to migrate. No veo ninguna buena razón para migrar.

And get almost fully typed. Y obtener casi completamente mecanografiado. Don't see any reason to migrate +1 No veo ninguna razón para migrar +1

+1 styles is the main reason we're migrating to Material UI and moving away from styled components. +1 styles es la razón principal por la que migramos a Material UI y nos alejamos de los componentes con estilo. It's too much CSS and refactoring it has proven to be a huge burden for us. Es demasiado CSS y refactorizarlo ha demostrado ser una gran carga para nosotros.

Hi! ¡Hola! First of all, thank you for providing a great component library, best one I've used so far. En primer lugar, gracias por proporcionar una gran biblioteca de componentes, la mejor que he usado hasta ahora. 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. Nuestros equipos han escrito cientos de miles de líneas de código usando los componentes y la metodología que usted creó y una vez que los desarrolladores aprenden los conceptos básicos del uso de classes , cómo escribir los estilos, etc., es muy fácil trabajar con él incluso en un tipo de base de código de escala empresarial masiva.

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. No estoy seguro de si ese es el uso más común de su biblioteca, pero supongo que sabe que muchos equipos construyen sus bibliotecas de componentes sobre Material UI, por lo que cualquier componente y decisión que tome también se filtrará a esas bibliotecas. On our end we've been very happy with both performance and APIs so far. Por nuestra parte, hasta ahora estamos muy contentos tanto con el rendimiento como con las API.

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. He estado siguiendo el desarrollo reciente en la biblioteca y, para ser honesto, tengo problemas para comprender algunas de las decisiones y me preocupa cómo afectará eso a nuestros equipos, y cuál sería el beneficio general de este movimiento, a diferencia de, por ejemplo, bifurcación MUI. Others have voiced their concern about move to styled components so I'll focus on the other one for me - the Box component. Otros han expresado su preocupación por cambiar a componentes con estilo, así que me centraré en el otro para mí: el componente 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. Entiendo la utilidad de un componente de Box: hacer posible el uso de variables de tema, etc. en valores de prop, sin embargo, la API y las consecuencias de usar este componente lo descalifican de algo que podría recomendar a nuestros equipos.

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} /> . Primero , tiene una API críptica por ninguna razón que pueda discernir (a menos que el motivo sea guardar unos pocos bytes): en lugar de escribir <Box margin={3} /> , sería <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 ?" Abreviaturas como esa parecen innecesarias, hacen que las cosas sean potencialmente ambiguas e introducen una nueva curva de aprendizaje para los desarrolladores, una asignación de abreviaturas a propiedades reales que ahora necesitan memorizar: "¿Se está aplicando color hecho usando c o color ?", "Es background un b , o bg , o background , o era b un border ?" "Is background-size abbreviated as bs ?" "¿Se abrevia background-size como 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. En segundo lugar , los componentes abstraen los patrones de interfaz de usuario más comunes y crean API que proporcionan medios para personalizar esos patrones en la medida en que el sistema de diseño lo permita. This manifests in creating props like gutterBottom on Typography , or dense on ListItem - as opposed to accepting just about any padding or margin. Esto se manifiesta en la creación de accesorios como gutterBottom en Typography , o dense en ListItem , en lugar de aceptar cualquier relleno o margen. 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. Siento que la introducción Box socava en gran medida este esfuerzo e introduce una herramienta que arruinará cualquier intento de seguir un sistema de diseño a menos que definamos algunas formas muy delicadas en las que el componente Box se puede usar y gastar. esfuerzo en las revisiones de código para asegurarse de que todos los valores en los accesorios de Box usados ​​no estén más allá de la lista aceptada. 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. Y en ese punto, la forma de "automatizar" esto sería crear un componente que restrinja las opciones, y volvemos al punto de partida. To give an example, why would using Box mb={2} to achieve margin under Typography be okay, but Box mb={6} not? Para dar un ejemplo, ¿por qué estaría bien usar Box mb={2} para lograr un margen en Tipografía, pero Box mb={6} no? This concern doesn't exist when we can rely on props to limit the options. Esta preocupación no existe cuando podemos confiar en accesorios para limitar las opciones.

Third concern, or rather a question I have. Tercera inquietud, o más bien una duda que tengo. 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. Dado que el componente Box es potencialmente una forma rápida de crear ciertas funciones, también lo utilizarían las bibliotecas creadas sobre MUI. How would one override the styles of Box components used within another component? ¿Cómo se anularían los estilos de los componentes Box utilizados dentro de otro componente? As an example. Como ejemplo. 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 construimos ListItem usando Box under the hood, ¿necesitaríamos introducir BoxProps={{ padding: 2 }} , o aceptar también dense prop basado en el cual escribimos lógica para aplicar un padding prop a un Box particular, o todavía algo más?

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. No estoy seguro de si ese es el uso más común de su biblioteca, pero supongo que sabe que muchos equipos construyen sus bibliotecas de componentes sobre Material UI , por lo que cualquier componente y decisión que tome también se filtrará a esas bibliotecas. On our end we've been very happy with both performance and APIs so far. Por nuestra parte, hasta ahora estamos muy contentos tanto con el rendimiento como con las API.

@maciej-gurban This use case is an important one for us. @maciej-gurban Este caso de uso es importante para nosotros. Our incentives are aligned to significantly improve it. Nuestros incentivos están alineados para mejorarlo significativamente. This is one of our objectives with v5. Este es uno de nuestros objetivos con 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. Por ejemplo, estamos investigando la viabilidad de proporcionar una herramienta de diseño que podría ponerse en manos de los diseñadores (de pago) y generaría componentes personalizados de Material-UI (MIT) listos para usar, la documentación correspondiente, el kit Sketch y Figma. Basically, all we have been going it for Material Design but scaling it 🚀. Básicamente, todo lo que hemos estado haciendo es Material Design pero escalando 🚀.
The end goal here would be to free the time of a couple of front-end developers in each company. El objetivo final aquí sería liberar el tiempo de un par de desarrolladores front-end en cada empresa. 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? ¿Por qué los desarrolladores front-end crean un sistema de diseño personalizado cuando pueden hacerlo sus propios diseñadores + Material-UI a una fracción del costo? + reduce risk and have your front-end developers spend time where they make the most differences: working on the product. + reduzca el riesgo y haga que sus desarrolladores front-end dediquen tiempo donde hacen la mayor diferencia: trabajando en el producto.

I'm having trouble understanding some of the decisions and worried how that will affect our teams Tengo problemas para entender algunas de las decisiones y me preocupa cómo afectará eso a nuestros equipos.

If you could list them, it would be awesome. Si pudieras enumerarlos, sería increíble.

Others have voiced their concern about move to styled components Otros han expresado su preocupación por pasar a componentes con estilo.

What's your concern with such a shift? ¿Cuál es su preocupación con tal cambio? Our objective on the styling side has a couple of layer: Nuestro objetivo en el lado del estilo tiene un par de capas:

1. Unstyled component, expose the same existing components but without any styles. Componente sin estilo, expone los mismos componentes existentes pero sin ningún estilo. Keep the same classes API (first seen in jQuery-UI), provide default hardcoded values for each of the classes (global class names). Mantenga la misma API classes (visto por primera vez en jQuery-UI), proporcione valores codificados predeterminados para cada una de las clases (nombres de clases globales). The objective behind this shift answer to a couple of incentives. El objetivo detrás de este cambio responde a un par de incentivos. 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. Primero, es para descartar un temor que tienen nuestros usuarios, lo mismo que el modo de expulsión de CRA, no lo usará pero se siente seguro estar presente. Second, it's required to be able to build the paid design tool. En segundo lugar, es necesario poder crear la herramienta de diseño de pago. Third, it's required for the next layer Tercero, se requiere para la siguiente capa.
2. Multiple style engines. Múltiples motores de estilo. The community is fragmented between different styling approaches. La comunidad está fragmentada entre diferentes enfoques de estilo. By order of popularity: styled-components, plain CSS, CSS modules, emotion, JSS, utility first classes. Por orden de popularidad: componentes con estilo, CSS simple, módulos CSS, emoción, JSS, primera clase de utilidad. It still feels like we didn't find the holy grail for styling. Todavía parece que no encontramos el santo grial para el estilo. And until we do, better not bet too much on any styling solution. Y hasta que no lo hagamos, mejor no apostar demasiado por ninguna solución de estilismo. So, have styled-components has the default, but allow developers to switch engine, stay on JSS if they are happy too. Por lo tanto, tener componentes con estilo tiene el valor predeterminado, pero permite que los desarrolladores cambien de motor y permanezcan en JSS si también están contentos.
3. Baseline theme. Tema de línea de base. Something less opinionated than the current default Material Desing Theme, but using the same theme's specification. Algo menos obstinado que el Material Design Theme predeterminado actual, pero usando la misma especificación del tema.
4. A couple of different themes on top of the baseline. Un par de temas diferentes además de la línea de base. One for marketing pages, One for the Chinese market (close to the Gmail equivalent of China). Una para páginas de marketing, otra para el mercado chino (cerca del equivalente de Gmail de China).

I'll focus on the other one for me - the Box component. Me centraré en el otro para mí: el componente Box.

Yeah, I can hear you! ¡Sí, puedo oírte! I have been working with @gregberge in the past. He estado trabajando con @gregberge en el pasado. At some point, we have considered hiding all the className props on @doctolib 's design system. En algún momento, hemos considerado ocultar todos los accesorios className en el sistema de diseño de @doctolib . The interesting thought is that you can gain features (properties) in exchange of more constraints. La idea interesante es que puede obtener características (propiedades) a cambio de más restricciones.

I wouldn't worry too much about this one. Yo no me preocuparía demasiado por este. This can be resolved with a global option to limit the access to the "system"'s features or an eslint rule. Esto se puede resolver con una opción global para limitar el acceso a las funciones del "sistema" o una regla de eslint.

The abbreviation on the Box component is confusing. La abreviatura del componente Box es confusa. Code is being read more than being written, so it's important to keep clear what the code is meaning. El código se lee más que se escribe, por lo que es importante tener claro lo que significa el código. Last day I found "Box py={2}" in our codebase and I'm totally confused. El último día encontré "Box py={2}" en nuestro código base y estoy totalmente confundido. After a search I figured out that means "paddingY". Después de una búsqueda, descubrí que significa "relleno Y". Those abbreviation should not be encouraged especially non-css properties (I can guess pt means padding-top but not for py) Esas abreviaturas no deben alentarse, especialmente las propiedades que no son css (puedo suponer que pt significa padding-top pero no para py)

@oliviertassinari Thanks for your patience @oliviertassinari Gracias por su paciencia

I'm having trouble understanding some of the decisions and worried how that will affect our teams Tengo problemas para entender algunas de las decisiones y me preocupa cómo afectará eso a nuestros equipos.

If you could list them, it would be awesome. Si pudieras enumerarlos, sería increíble.

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. No me gustaría que esto se convirtiera en una letanía de cosas con las que no estoy de acuerdo porque, en última instancia, ustedes son los que mantienen esta biblioteca y nuestra visión de lo que tiene sentido estará determinada por nuestras propias necesidades, lo que podría y probablemente no siempre. alinear, y eso está 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. No estoy en contra de introducir los medios para usar otras soluciones de diseño; de hecho, creo que es genial, ya que atraerá a más usuarios que se retrasaron debido a su disgusto por JSS, pero también estamos nosotros, los usuarios ya existentes de su biblioteca que están vendidos en su solución y, si es posible, les gustaría evitar una refactorización masiva.

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. Incluso si decide que "seguimos brindando soporte para JSS", la refactorización de todas las demostraciones y sus componentes a componentes con estilo obligará a los equipos que usan JSS a migrar a componentes con estilo. "Why are we still using X, when MUI team moved to Y?" "¿Por qué seguimos usando X, cuando el equipo de MUI se mudó a 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. - será una de las muchas preguntas ante las cuales sería muy difícil no estar de acuerdo con la necesidad de realizar esa migración tarde o temprano.

I can definitely empathize with wanting to reach a wider audience by using a styling solution that's more popular. Definitivamente puedo empatizar con el deseo de llegar a un público más amplio mediante el uso de una solución de estilo que es más popular. 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. Sin embargo, creo que vale la pena considerar que "popular" no siempre es "mejor" y que cambiar a una tecnología diferente necesita considerar no solo las ventajas y desventajas de ambas soluciones, sino también el contexto en el que tomamos la decisión.

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. Comenzar de nuevo, mirar simplemente las ventajas de X sobre Y tiene sentido, pero al trabajar en un sistema ya existente, también debemos considerar el costo de cambiar y los efectos dominó que esto genera en los equipos posteriores. For this switch over to make sense the advantanges of the other solution need to outweight the cost of migrating over. Para que este cambio tenga sentido, las ventajas de la otra solución deben superar el costo de la migración. 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. Parece que para su equipo, el análisis de costo-beneficio gobierna a favor de los componentes con estilo, pero por lo que puedo decir al observar las reacciones en las publicaciones que hablan sobre los componentes con estilo en su repositorio, su base de usuarios está lejos de llegar a la misma conclusión.

Like you said, your aim is to open up MUI to more styling solutions. Como dijiste, tu objetivo es abrir MUI a más soluciones de diseño. 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. Para brindar un buen soporte para esas soluciones, se necesitaría una buena documentación, ejemplos y una capa de integración fluida; de lo contrario, a los desarrolladores les resultaría difícil traducir lo que ven en las demostraciones en lo que necesita la solución de diseño de su elección. I'm just not sure if you really need to migrate to styled components to achieve the goals. Simplemente no estoy seguro de si realmente necesita migrar a componentes con estilo para lograr los objetivos. 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. Parece que su solución también es perfectamente capaz, si no más que otras, de construir la herramienta de diseño que está buscando, ya que ya usa el objeto JS real para todos los estilos.

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? Tengo una pregunta, ¿significa esto que el núcleo de Mui todavía usaría jss, y esto permite una mejor manera de usar componentes con estilo además de eso? Or would there be a way to say the core is also styled? ¿O habría una manera de decir que el núcleo también tiene estilo? I just think it would add a lot of bloat if you have two css in js solutions. Simplemente creo que agregaría mucha hinchazón si tiene dos soluciones CSS en js.

How would theming work if using styled-components? ¿Cómo funcionaría la tematización si se utilizaran componentes con estilo? I used to use helpers in the CSS portion, and it was really messy. Solía ​​​​usar ayudantes en la parte de CSS, y era realmente complicado. For me, the approach of applying theme props in a JS object is a lot cleaner than in a templated string. Para mí, el enfoque de aplicar accesorios de tema en un objeto JS es mucho más limpio que en una cadena con plantilla.

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. Para mí (programador back-end científico de origen), los estilos MUI aportan una lógica hermosa, tranquilizadora, predecible y parametrizable al mundo mental, loco y loco de las reglas del por qué diablos de 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 biblioteca de estilos (y su estrecha integración con el tema) es la razón principal por la que exijo el uso de MUI sobre cualquier otra biblioteca de componentes en las dos organizaciones para las que superviso la tecnología: ¡elimina toda la agonía de 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!!" Al principio, todos los desarrolladores con los que trabajo dicen "¿qué diablos está pasando? ¿Dónde está el css? ¡Solo dame css!" and then they're like "Ohhhh. riiight. Got it. Magic." y luego dicen "Ohhhh. riiight. Lo tengo. Magia".

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). A más largo plazo, creo que el enfoque actual se volverá cada vez más poderoso a medida que el mundo se mueve hacia soluciones de código bajo o sin código (por ejemplo, como sketch o figma, pero generando una aplicación enrutada real y un conjunto de componentes en lugar de un conjunto de estructuras alámbricas) - tener estilos expresados ​​como un objeto desbloquea la capacidad de introspección que - y crear más características nuevas en dicho entorno (como la provisión de un esquema que permite el uso directo de componentes MUI dentro de un CMS, o la generación de 'tema de esto' y cientos I no lo he pensado todavía).

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. Volver al tipo de enfoque más raw-css de styled-components no lo impide, pero hace que muchas cosas (particularmente la parametrización en el tema) sean mucho más complicadas y frustrantes de lograr, y aún requiere un conocimiento mucho más profundo de los tecnicismos de CSS, lo que lo hace menos accesible tanto para los nuevos programadores como para los tipos creativos.

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). Sobre la evolución del estado del arte, creo que styled-components se ha vuelto muy popular porque es un gran paso en la dirección correcta desde donde estaba el mundo (razón por la cual se hizo popular). But the existing MUI styles system is the next step on from that; Pero el sistema de estilos MUI existente es el siguiente paso; not an incorrect side-step. no es un paso lateral incorrecto. 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...?" Una vez que todos hayan migrado a componentes con estilo, la pregunta será "espera: ¿por qué diablos estamos haciendo esto con estas extrañas cadenas en bruto en nuestros componentes...?"

Maybe I'm totally wrong, but for my $0.02, I'm begging you to stay the course for at least another major version :) Tal vez esté totalmente equivocado, pero por mis $ 0.02, les ruego que mantengan el rumbo por al menos otra versión principal :)

@thclark your main concern seems to be with the CSS template string syntax vs the JavaScript style object API. @thclark, su principal preocupación parece ser la sintaxis de cadena de plantilla CSS frente a la API de objeto de estilo JavaScript. Is this accurate? ¿Es esto exacto? It also seems to be the concern with most of the other comments of the thread. También parece ser la preocupación con la mayoría de los otros comentarios del hilo.

Styled-components and emotions support both APIs. Los componentes con estilo y las emociones son compatibles con ambas API. This wasn't the main purpose of the issue. Este no era el objetivo principal del problema. The objective of this issue was to anticipate the migration to a different styling solution. El objetivo de este número era anticipar la migración a una solución de estilo diferente. However, we never move forward with "use styled-components in all the demos even if we didn't migrate the core engine". Sin embargo, nunca avanzamos con "usar componentes con estilo en todas las demostraciones, incluso si no migramos el motor central". We have opted for keeping both synchronized. Hemos optado por mantener ambos sincronizados.
At this point, keeping the issue open doesn't add much value outside triggering discussions like this one :). En este punto, mantener el problema abierto no agrega mucho valor aparte de desencadenar discusiones como esta :). We have to migrate the demos anyway for #22342. Tenemos que migrar las demostraciones de todos modos para #22342.

I personally prefer the JavaScript API over the CSS string one because: Personalmente, prefiero la API de JavaScript a la cadena CSS porque:

• It doesn't ask for another linter/formater. No pide otro linter/formateador.
• I'm used to it. Estoy acostumbrado a eso.
• It plays nicely with TypeScript. Juega muy bien con TypeScript.

However, it's unclear what the community, at large, will enjoy using most. Sin embargo, no está claro qué disfrutará más la comunidad en general. CSS template has its advantages too. La plantilla CSS también tiene sus ventajas. It's easier to copy & paste code between the browser and the code. Es más fácil copiar y pegar código entre el navegador y el código. A lot more people (overall: designers, developers, etc.) are familiar with the approach. Muchas más personas (en general: diseñadores, desarrolladores, etc.) están familiarizadas con el enfoque.

To be noted that I think that we should use the style utilities as much as possible in the demos with v5. Cabe señalar que creo que deberíamos usar las utilidades de estilo tanto como sea posible en las demostraciones con v5.

@mnajdova any thoughts on the matter? @mnajdova alguna idea sobre el asunto? Maybe it's worth asking the community on a poll. Tal vez valga la pena preguntarle a la comunidad en una encuesta.

@oliviertassinari succinctly put, as usual. @oliviertassinari en pocas palabras, como de costumbre. Yes, my main concern is retaining the Javascript API. Sí, mi principal preocupación es conservar la API de Javascript. Honestly, I wasn't aware that styled-components retained that, as all of the examples I came across seem to be css templated. Honestamente, no sabía que los componentes con estilo retuvieran eso, ya que todos los ejemplos que encontré parecen tener plantillas CSS.

That perhaps moots most of my points above. Eso quizás debata la mayoría de mis puntos anteriores. Nevertheless, glad you didn't move across - and thanks for your and the team's continued efforts here. Sin embargo, me alegro de que no te hayas mudado, y gracias por los continuos esfuerzos tuyos y del equipo aquí. I've built things I never could have without MUI existing. He construido cosas que nunca podría tener sin la existencia de MUI.

This issue is being resolved in v5. Este problema se está resolviendo en v5. We have migrated the documentation of the slider to the new approach: https://next.material-ui.com/components/slider-styled/. Hemos migrado la documentación del control deslizante al nuevo enfoque: 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. Usamos el accesorio sx cada vez que se necesita CSS simple y luego usamos la API styled para personalizaciones más pesadas. I believe the previous concern raised have been handled, if not, please comment :). Creo que la inquietud anterior planteada se ha manejado, si no, comente :).