Material-ui: Refactorizar CSS en Javascript

Me gusta eso, pero no sé cómo funciona en el mundo real. Imagina tener muchos elementos, cada elemento tendrá un estilo personalizado. Hará que el dom sea enorme. ¿No es esto un problema de rendimiento? (Hice una interfaz de usuario similar completamente en react.js con estilo y todo funcionó bien, pero fue un pequeño proyecto de prueba)

@ totty90 sí, me preguntaba esto, pero de las diapositivas, el problema en Facebook por los sonidos era que todos los archivos CSS y las clases CSS eran un problema de rendimiento.

Tal vez @vjeux podría arrojar luz sobre esto y es la solución sugerida en esa presentación de diapositivas.

¿Quizás para algunos de los componentes más pequeños esta podría ser una mejor solución?

Editar: Otra cosa de la que no estaba seguro era cómo lidiar con las consultas de medios y la capacidad de respuesta.

Ya le pedí que me mostrara una aplicación del mundo real usando esta técnica. Esto resuelve uno de los mejores problemas: un componente vino en un solo archivo. Puedo compartir un archivo con usted y usted obtiene mi componente exactamente igual que el mío sin ninguna configuración de su parte. Sin problemas de CSS.

Hay otro proyecto que tiene como objetivo proporcionar una buena manera de integrar CSS-in-JS y React - https://github.com/js-next/react-style y también un trabajo inicial en los componentes de Material UI usándolos - https: //github.com/SanderSpies/react-material

Este proyecto tiene más tracción en este momento y una mayor cantidad de componentes implementados, pero react-material tiene la ventaja de que los componentes funcionan de forma independiente sin tener que agrupar archivos CSS. También obtiene todos los beneficios descritos en la presentación de @vjeux .

¡Sería genial si los dos proyectos pudieran combinarse!

El otro proyecto es mucho peor. La única parte interesante es el CSS en js.

Me gusta el concepto de tener JS y CSS acoplados, pero los estilos en línea son malos para el rendimiento del navegador y la implementación de CSP. ¿Quizás usar WebPack si está preocupado?

Webpack parece ser la única forma "razonable" de importar estilos. Tiene un require('component.css'); , pero luego termina teniendo una dependencia para su componente. ¡También deben usar Webpack! No me gusta esa solución. Uno debería poder compartir un componente fácilmente con solo instalarlo, usarlo y obtener ganancias.

El enfoque actual aquí parece fácil de usar. No es perfecto, pero copiar un par de líneas de importación es bastante sencillo. Aunque sugeriría que usar Less una vez más bloquea a los usuarios en ese preprocesador ...

¡Es difícil simplificar las cosas! ¿Alguien tiene alguna sugerencia? Esto es mucho más amplio que solo este proyecto. Toda la comunidad de react / polímero / componente necesita una solución.

PD: acoplar CSS dentro de su JS parece una mala idea. Por un lado, termina escribiendo un pseudo CSS con propiedades en mayúsculas y valores en cadena y está mezclando cognitivamente preocupaciones que hacen que sea más difícil razonar sobre su código. Nunca he tenido problemas para escribir CSS. Sí, puede ser difícil y las cosas pueden salir mal (espacio de nombres global, consecuencias no deseadas, etc.), pero cambiar eso a JS NO solucionará el problema. Escribir mejor CSS lo es.

@ pspeter3 ¿tienes algún punto de referencia? :)

Principalmente estos dos JsPerfs, http://jsperf.com/class-vs-inline-styles/2 y http://jsperf.com/classes-vs-inline-styles. Sin embargo, http://jsperf.com/inline-style-vs-css-class/9 parece implicar lo contrario. Malo para el desempeño fue una exageración. Estoy seguro de que también puede causar un mal rendimiento con las hojas de estilo utilizando selectores deficientes. ¿Tiene algún consejo sobre la implementación de la Política de seguridad de contenido al usar estilos en línea?

@jarsbe

PD: acoplar CSS dentro de su JS parece una mala idea. Por un lado, termina escribiendo un pseudo CSS con propiedades en mayúsculas y valores en cadena y está mezclando cognitivamente preocupaciones que hacen que sea más difícil razonar sobre su código. Nunca he tenido problemas para escribir CSS. Sí, puede ser difícil y las cosas pueden salir mal (espacio de nombres global, consecuencias no deseadas, etc.), pero cambiar eso a JS NO solucionará el problema. Escribir mejor CSS lo es.

He escrito mucho CSS y CSS en JS. El primero es más fácil, pero en proyectos grandes se complica, el otro creo que (porque solo he creado una aplicación pequeña) funcionaría mejor en una aplicación más grande. Intenta programar una aplicación js con todo lo global + fusionando cosas, ¡eso es un infierno! (O siempre lo he hecho mal ...)

Aquí hay una prueba que hice con react.js http://jsperf.com/react-class-name-vs-inline-css2

Sí, desearía que hubiera una respuesta fácil para esto. :) Al final, creo que ambos enfoques tienen méritos.

Mi mayor preocupación con la inclusión de estilos dentro de los componentes JS tiene que ver con el mantenimiento del código. Por ejemplo, ¿qué sucede con el CSS que se necesita para restablecer varios navegadores? ¿Estos estilos también se incluyen en los componentes? Además, obtenemos muchas comodidades al usar MENOS como mixins, variables, etc.que de alguna manera tendríamos que reemplazar y abstraer dentro de JS.

Dicho esto, hemos espaciado de nombres todas las clases de CSS que se utilizan en este proyecto con "mui" e intentamos escribir CSS orientado a objetos. En el futuro, probablemente debería haber algún proceso que permita a los usuarios elegir qué componentes descargar en una compilación personalizada.

Gracias por el problema. ¡Los puntos realmente buenos planteados son la discusión!

¿Qué hace que el estilo de un componente sea menos parte de ese componente que su estructura (html) y funcionalidad (js)? Me parece que hemos llegado a confundir un método para mitigar un problema (capacidad de mantenimiento del código) con un patrón de diseño intrínsecamente inteligente y hemos olvidado que en realidad era un parche. Podría decirse que React es una solución más elegante para la mantenibilidad del problema del código que dividir la estructura, la funcionalidad y el estilo en sus propios lenguajes. Tiene sus propios problemas (velocidad en el caso de CSS), pero si llegamos a estar de acuerdo en que esta forma reunida de escribir componentes es buena, podemos empezar a intentar resolver el problema de la velocidad.

Cabe señalar que personalmente creo que esta es una de las fallas de la especificación de componentes web. Donde agrupa diferentes idiomas en un módulo, React desafía la idea misma de html y css.

@mcwhittemore Sí, el estilo no es menos parte del componente que HTML o JS. Juntos se combinan para crear un componente. Esto no requiere que el componente deba escribirse como una 'unidad', así es como debe distribuirse.

Reaccionar acopla estrechamente la estructura y la funcionalidad. Te obliga a seguir este patrón y he encontrado que esto es simple y lógico. Puedo entender fácilmente el código que estoy viendo, mi cerebro no está sobrecargado.

Por otro lado, CSS dentro de un archivo JS hace que el código sea más difícil de entender para mí. Las descripciones del estilo visual no se ajustan bien a la funcionalidad y la estructura. No estoy simplemente molesto por eso, estoy confundido y ralentizado ya que tengo que procesar múltiples preocupaciones. También combina estrechamente el estilo con el componente, lo que dificulta que otros autores escriban sus propios estilos.

Quiero distribuir mi componente como un solo paquete. ¡El desarrollo de bloques de Lego es el sueño! Parece que todos estamos en la misma página con ese objetivo final. CSS en línea suena como una buena solución, pero no creo que sea la solución correcta.

@jarsbe 100% está de acuerdo en que el estilo de lectura en el componente no es lo suficientemente claro. A veces, puede resultar difícil simplemente encontrar dónde se crea el estilo. He estado usando un archivo style.json donde sus defaults y permanents se fusionan con this.props.style hace un montón para mayor claridad.

{
  "defaults": {
    "backgroundColor": "#efefef"
  },
 "permanents": {
    "width": "100%"
  }
}

Otro argumento en contra de aplicar estilos en JS frente a CSS es que el atributo style no tiene los mismos poderes que un selector de CSS. Por ejemplo, no creo que el *:after en el actual menos sea ​​posible de implementar.

@mcwhittemore tratando de obtener un elemento psuedo fue exactamente lo que me hizo decir, "¿eh? oh sí, eso no existe en este contexto ...". Sí, la extracción en otro archivo ayuda. Debo echar un vistazo al sistema en bespoke.js para diseñar nuevos temas. Escuché que implementa CSS en JS pero estoy cansado.

@mcwhittemore ¿por qué necesitas *:after ?

@ totty90 Actualmente es parte del CSS. Puede haber formas de resolver este problema, pero no es una simple situación de "convertir su css a js". ¿Tiene una solución para el selector :after o :before en la que no estoy pensando?

En mi opinión: after y: before son una especie de trucos y nunca los necesité, quiero saber para qué los necesitas para darte una solución / opinión.

@ totty90 Te mencionaré en otro número sobre otro proyecto para no saturar este.

@ hai-cea Teniendo en cuenta un flujo de trabajo SMACSS (https://smacss.com/book/categorizing), un buen enfoque puede ser mantener el CSS para las categorías _Base_, _Layout_ y (tal vez) _Theme_ en los buenos archivos css antiguos . _Module_ y _State_ css me parece un buen candidato para hacer estilo JS.

@WRidder Gracias por el enlace, eso tiene mucho sentido.

Un pensamiento aleatorio que no sabía dónde poner ... ¿Cómo implementan los componentes nativos el estilo? Imagino que los componentes de reacción deberían ser de naturaleza similar a los componentes nativos. Puede ser un buen lugar para buscar ideas.

Soy muy escéptico de este enfoque de colocar CSS dentro de JS: la presentación en sí habla sobre el tema de asociar estilos con componentes como si no hubiera habido un esfuerzo completo de varios años para hacer precisamente eso con Shadow DOM estándar. Ahora, claramente, React no usa ese mecanismo en la actualidad, pero no me sorprendería si lo hiciera a tiempo.

Ese estándar funciona porque proporciona una forma para que un creador de componentes asocie un conjunto mínimo de estilos básicos con su componente que luego puede ser anulado por un diseñador que se adentra en el DOM en la sombra. No está nada claro cómo un diseñador anularía los estilos establecidos puramente dentro de Javascript si no estuvieran usando los componentes con reaccionar directamente.

Acabo de regresar de reaccionar conf y muchas gracias a @vjeux por organizarlo. Yo también era escéptico con este enfoque, pero creo que tiene sus ventajas. Este proyecto tiene algunos desafíos que me encantaría resolver si optamos por este enfoque.

1. Nos gustaría que estos componentes fueran temáticos. Tendrían algunos estilos predeterminados, pero los desarrolladores deberían poder cambiar el aspecto para satisfacer sus necesidades. Actualmente, pueden hacer esto anulando ciertas variables en MENOS. ¿Cómo podríamos ofrecer las mismas capacidades usando estilos js?
2. Muchas veces, los componentes generarán elementos secundarios anidados. ¿Cómo permitimos que los desarrolladores personalicen estilos en elementos secundarios anidados? Mi instinto es que solo deberíamos exponer accesorios de estilo en esos niños que serían personalizables. ¿Pero esto uniría estrechamente nuestros estilos con la estructura dom de un componente? Lo que quiero decir es que, si terminamos cambiando la estructura dom de un componente, ¿terminaríamos cambiando también sus accesorios de estilo?

Gracias por toda su ayuda y comentarios hasta ahora. Espero con ansias lo que todos tengan que decir.

¿Hubo un video sobre esta idea en la conferencia React?

@vjeux Lo tocó un poco en su charla React Native - http://conf.reactjs.com/schedule.html#react -native

También me habló de una charla que dio en NationJS, pero no sé si hay audio.
http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html

Hola @ hai-cea,
Mi equipo tiene un experimento muy pequeño sobre el problema de la temática. La solución de mi equipo es la biblioteca de material de interfaz de usuario que expone una función para establecer el tema:
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/src/index.js

Cuando usamos material-ui, llamamos a esta función con la propiedad de definición personalizada. Y material-ui llamará a la actualización de esta función. Puedes ver en:
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/src/js/scaffold-styles.js

y el ejemplo que usamos en estos archivos:
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/src/js/raised-button.jsx
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/example/src/app/custom-styles.js
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/example/src/app/components/main.jsx

Gracias @ cuongcua90 - Tuve una idea similar a la tuya.

Habría un objeto de tema que se encargará de mantener todas las variables definidas en custom-variables.less . Los desarrolladores pueden anular estas variables en la inicialización de su aplicación con un método auxiliar como este:

//Override Theme Variables
Theme.set({
  textColor: 'red'
});

Para proporcionar un control más detallado de los estilos, cada componente incluirá accesorios de estilo que se fusionarán con los estilos predeterminados:

//merge styles that are passed in
var styles = this.mergePropStyles(defaultStyles, this.props.style);

Además, encontré algunos otros desafíos en mi prueba:

1. ¿Cómo manejaríamos los prefijos de proveedores?
2. ¿Qué pasa con las consultas de medios?

hey @ cuongcua90 y @ hai-cea - ¿y si utilizamos otro marco para hacer esto? No he leído mucho al respecto, pero parece que http://jhudson8.github.io/fancydocs/index.html#project/jhudson8/react -css-builder? Focus = outline podría ser una buena opción.

Soporta mixins y variables.

Caballeros

Creé una rama css-in-js para trabajar en este problema y tener un prototipo en la carpeta de ejemplo.

Los desarrolladores tienen 2 puntos por personalización. Primero es anular las variables de tema predeterminadas. Las variables incluirán elementos como colores de los componentes, tipos de letra, etc.
https://github.com/callemall/material-ui/blob/css-in-js/example/src/app/app.jsx#L16

Para un control más granular, los desarrolladores también pueden anular los estilos de componentes predeterminados a través de accesorios:
https://github.com/callemall/material-ui/blob/css-in-js/example/src/app/components/main.jsx#L10

Aquí hay un ejemplo de cómo implementaríamos un componente en el lado de MUI:
https://github.com/callemall/material-ui/blob/css-in-js/src/js/svg-icons/svg-icon.jsx

Puede ver que nos encargaremos de fusionar variables de tema, accesorios de estilo y también prefijos automáticos basados ​​en la detección de características.

¿Algún comentario sobre este patrón?

Mover todo el CSS a un sistema basado en JS sería bueno y resolvería # 316. No estoy seguro de cuánto se sabe en términos de mantenibilidad, y algunos estilos comunes se aplican a todos los elementos (por ejemplo, el restablecimiento y las cosas en less/core/ ), por lo que no estoy seguro de lo que está planeado para cómo obtener esos estilos en las aplicaciones de las personas. Algunas preguntas abiertas, pero definitivamente muy interesantes.

podríamos crear algún tipo de sistema de herencia clásico para crear objetos de estilo. de esa manera, para los estilos comunes, puede haber un objeto BaseStyle heredable.

Tengo curiosidad por entender el problema real que está tratando de resolver mezclando CSS en JS.

1- Facilitar la construcción porque no nos preocupamos por "¿Dónde está el CSS que necesito para esto?"
2- ¿Tematización de JavaScript?
3- ¿Anular estilos?

Estos problemas existen desde el principio, y en mi caso todo se resolvió al tener una estructura de carpetas simple más una "página. (Css | menos | sass)" con reglas @import , todas relativas al archivo.

¿Alguien podría detallar / explicar / compartir por qué mezclar CSS en JS es una buena idea?

¡Gracias por tu tiempo!

No soy el autor del paquete, pero crear estilos dinámicamente con JS es algo que se está volviendo más popular últimamente.

Hay una serie de problemas con CSS en general. CSS se compila con una serie de variables estáticas, como (por ejemplo) el tamaño de su cuadrícula, el color de su tipo principal, etcétera. No puede cambiarlos después, excepto si selecciona manualmente los elementos afectados y establece estilos personalizados que anulan el CSS compilado.

Poner CSS en JS significa que se vuelve completamente dinámico y puede cambiar cualquiera de las variables subyacentes a voluntad. También significa (específicamente en el caso de React) que puedes mantener los estilos relevantes dentro del componente.

Sin embargo, no estoy 100% convencido. También significa que no tiene estilo hasta que JS termine de cargarse. No es un trato importante en el caso de una aplicación de una sola página, pero es algo que podría justificar una reflexión en el futuro. (¿O quizás la renderización del lado del servidor ya se ocupa de esto de una manera eficiente? También espero escuchar a alguien que tenga más experiencia en hacer esto). Tener un archivo CSS separado también significa que el navegador puede comenzar a cargar los estilos en paralelo .

@dendril : la presentación que dio @vjeux describe los problemas con CSS a gran escala. Algunos de los problemas que resuelve el uso de JS para crear CSS incluyen:

• Los módulos, variables, cálculos y mixins pueden usar todas las herramientas existentes que JS ya tiene: módulos CommonJS, variables JS, expresiones JS en lugar de tener que usar una sintaxis separada y un conjunto de herramientas para administrarlos.
• Puede utilizar las herramientas JS existentes para averiguar dónde se hace referencia a un estilo en particular. Puede llevar esto más allá con FlowType y TypeScript para obtener errores en tiempo de compilación si escribe mal un nombre de clase, por ejemplo.
• Puede definir la estructura, la apariencia y la lógica en un solo lugar, lo que es un paso útil para facilitar la reutilización de componentes. Web Components resuelve este problema con las importaciones de HTML. Definir todo con un idioma es otro enfoque.
• Hacer cosas dinámicas con CSS es más fácil. Debido a que tanto el estilo estático como el dinámico se implementan en el mismo idioma, puede compartir constantes, etc. entre ellos.

Como ejemplo, tengo una implementación de un botón de estilo Material Design usando estilos en línea de TypeScript + aquí: https://github.com/robertknight/passcards/blob/master/webui/controls/button.ts .

• El tema + estructura del botón está en un solo lugar, lo que es útil para el desarrollo y la reutilización. Con un IDE, puede encontrar fácilmente dónde se hace referencia a todos los elementos particulares del tema.
• En la función render () puedo construir el estilo del botón dependiendo de los accesorios haciendo referencia a partes del tema de una manera simple sin tener que concatenar cadenas de nombres de clases.
• Al definir el tema, puedo usar JS para calcular ciertos colores usando fórmulas especificadas por la especificación de diseño de material (Ver colors.premultiplyColor() )

Aquí hay una compensación que es la compensación habitual de los enfoques declarativos frente a los imperativos para especificar cosas. El lenguaje imperativo (JS) te da mucho poder. Sin embargo, la sintaxis es más detallada y la flexibilidad está abierta al abuso. Para componentes complejos con mucho estilo dinámico, el equilibrio se inclina a favor de JS. Para un estilo estático que se expresa fácilmente en CSS, no tanto. No usaría este enfoque para contenido similar a un documento.

@msikma : especificar estilos en JS no tiene por qué significar usar estilos en línea o esperar a que se cargue la aplicación. Puede usar JS solo como un lenguaje para crear los estilos que compilan hasta JS, básicamente una alternativa a SASS o LESS. Combine esto con la representación del lado del servidor y la salida real que obtiene el navegador puede parecerse mucho a CSS y eso funciona muy bien con las herramientas de desarrollo del navegador.

@robertknight Muchas gracias por su respuesta, acaba de agregar suficiente información para comprender completamente la idea.

Prefiero la evolución de SASS / LESS en lugar de agregar más JavaScript al programa, al final, si desea reutilizar mecanismos, podemos mejorar LESS, que está codificado en JavaScript, y reutilizar tanto como queramos de JavaScript, pero parece Es fácil diseñar una nueva API y comenzar a mezclar todo en un solo archivo.

Espero que encontremos una mejor solución, porque perder la idea declarativa de CSS no será una buena idea, y menos cuando estamos haciendo todo declarativo en lugar de imperativo. \ o /

@msikma : especificar estilos en JS no tiene por qué significar usar estilos en línea o esperar a que se cargue la aplicación.

¿Es posible declarar estilos globalmente (construyendo dinámicamente un elemento de estilo)? Me lo imagino, ya que eso es esencial.

Sin embargo, ¿cómo evitar tener que esperar a que se cargue el JS?

@msikma - Sí. En el ejemplo al que me vinculé, todo el estilo en la var 'tema' que se define en la parte superior del archivo se compila en CSS en el momento de la compilación. En la función render (), hay llamadas a style.mixin (theme.someElement, otherProps) que devuelve un objeto con una propiedad className que es la lista habitual de nombres de clases separados por espacios. Si ejecutó React en el servidor, obtendría una cadena HTML normal con elementos que tienen atributos de 'clase' y 'estilo' que se pueden representar en el cliente sin ejecutar ningún código.

@dendril : la alternativa al CSS declarativo no tiene por qué ser JS imperativo. El JS se puede escribir de forma funcional / declarativa; todo el estilo estático puede ser un simple objeto Javascript. Si necesita hacer referencia a la misma constante (por ejemplo, un color o tamaño de fuente) en el estilo dinámico y el estilo estático, eso se vuelve fácil de hacer.

Gracias por la explicación, suena muy bien.

Acabo de entrar en este hilo, pero estoy interesado porque estoy intentando desarrollar un proyecto con material-ui. Cambié a la versión SASS, descubrí que no hay un sistema de cuadrícula implementado en material-ui y luego me di cuenta de que la versión SASS no está sincronizada. Así que tengo mucha curiosidad por saber qué dirección tomará este proyecto en el futuro. Parece que hay tantas compensaciones al colocar el CSS en los propios componentes que no es una elección clara. Intuitivamente, encuentro la idea un poco peligrosa porque es una forma de salida tan radical de las prácticas de desarrollo web establecidas hasta ahora. Por otro lado, ¡también lo es React!

@ hai-cea ¿Ha considerado la biblioteca JSS ? Lo he estado usando para un nuevo proyecto de React en el que he estado trabajando, y hasta ahora me gusta mucho. Lo bueno es que tiene la opción de declarar nombres de clases globales si es necesario en raras ocasiones. Prácticamente cualquier cosa que pueda hacer en CSS lo puede hacer en JSS, ya que está creando sus propias clases con espacios de nombres y agregándolas a una etiqueta <style> en <head> .

Hay un nuevo proyecto sobre los estilos de React para su consideración. Aquí hay un enlace: Radio

Acabo de ver este hilo y desearía haberlo encontrado antes. Estamos haciendo CSS en JS en un tema de iOS incluido en reapp-ui . Estuvo en desarrollo durante unos meses antes de su lanzamiento.

De hecho, @ hai-cea, aterricé en un sistema muy similar al tuyo.

1. Cargue " constantes " (piense: colores, detección de características). De hecho, hacemos dos niveles de constantes, el primero es la detección de características y los colores, el segundo son las constantes para componentes específicos .
2. Cargar estilos para componentes . En realidad, tienen una estructura coherente. Objetos con claves que son "ref" => "stylesObj".
3. Cargar animaciones .

Así es carga un tema personalizado mezclando y haciendo coincidir el tema base con sus propias variables para "

Esto tiene algunos beneficios realmente asombrosos:

1. Los usuarios no tienen que cargar ningún estilo adicional que no necesiten.
2. Los componentes tienen nombres y declaraciones de estilo consistentes.
3. Todo es temático en todos los niveles.
4. Fácil de agregar temas para otras plataformas.

Estamos usando el estilo de reacción para todo esto y ha funcionado muy bien. Junto con una combinación de estilos que nos permite agregar estilos declarativos realmente increíbles. Eso, y el mixin Tappable también da estados de Enfoque / Activo. Ambos se extraerán en poco tiempo.

En realidad, hay un poco más de todo lo que me gustaría escribir en documentos oficiales pronto.

Sin embargo, nuestro siguiente paso es crear un tema de interfaz de usuario material en Reapp, y he tenido este proyecto marcado como favorito por un tiempo para volver. ¡Me pregunto si no podríamos trabajar juntos en eso!

@ hai-cea Su objeto Theme realmente encajaría muy bien con la función de contexto de React. En caso de que no esté familiarizado con él, el contexto es básicamente accesorios que se transmiten automáticamente a su jerarquía de componentes. En cualquier nivel dado de la jerarquía, los componentes pueden consultar su contexto por algún valor.

En su caso, recomendaría establecer una variable theme en el contexto. Funcionaría algo como esto:

var App = React.createClass({
  childContextTypes: {
    theme: React.PropTypes.instanceOf(Theme)
  },
  getChildContext() {
    return {
      theme: CustomTheme
    };
  },
  // ...

Luego, en su componente <Button> podría hacer

var Button = React.createClass({
  contextTypes: {
    theme: React.PropTypes.instanceOf(Theme)
  },
  getTheme() {
    return this.context.theme || DefaultTheme;
  },
  render() {
    return <button style={this.getTheme().getButtonStyle()}>...</button>;
  }
});

Cosas que me gustan de este enfoque:

• No hay un objeto Theme global
• Se puede tematizar una sección completa de la interfaz de usuario simplemente cambiando el contexto en un solo componente principal (piense en tematizar un modal completo con una declaración)

De todos modos, están haciendo un trabajo increíble aquí. Espero que esto ayude :)

¡Hy!
He creado una biblioteca para escribir css en vistas de reacción, eche un vistazo https://github.com/hackhat/smart-css

Qué hace: Escribe CSS en JavaScript con espacios de nombres, nombres propios, sin conflictos y resultados esperados para react.js.

@mjackson Me gusta mucho su enfoque de enviar el contexto del tema por la jerarquía, pero esta parte

this.getTheme (). getButtonStyles ()

No es bastante escalable porque el tema debe conocer el estilo. Creo que el tema debería ser un nombre, una paleta de colores y algunas definiciones de espaciado, pero no un estilo CSS completo. Esto permitiría componentes y aplicaciones realmente personalizables y escalables.
¿Qué piensas?

@mjackson Me gusta el contexto Idea. Usamos un decorador que hace básicamente lo mismo.

@hackhat Sí, si haces bien tus constantes, puedes cargar tantas como quieras para poder superponerlas. Comience con "base" para colores, luego tenga "componentes" para específicos, etc. Así es como podemos permitir que los "temas" incluso funcionen desde el material hasta iOS y Windows (en el futuro).

De cualquier manera, ¡buena suerte con todo! Creo que vamos en la misma dirección, pero eso es bueno. Si está interesado en fusionarse, póngase en contacto. Dado que hemos creado un gran conjunto de cosas para iOS y tu Android y hemos explorado bastante en CSS / JS, podría ser útil. De cualquier manera, he agregado algunos documentos aquí para contribuir a eso: https://github.com/reapp/reapp-ui/issues/29.

Perdón por el hilo, acabo de ver una oportunidad para trabajar en equipo: +1:

@natew Me alegra escuchar sobre su proyecto. Parece que vamos por buen camino. :)

@mjackson Gracias por contarme sobre la función de contexto de React; nunca la había usado antes, pero la escuché mencionar en la conferencia de reacción y también la vi usada en React Router. Parece una gran solución, definitivamente la probaré.

Hemos progresado bastante en la transferencia de estilos a js. Creo que una de las mayores ventajas que veo es que somos más explícitos sobre los estilos de cada componente. Hasta ahora, no hemos sentido la necesidad de incorporar una biblioteca como JSS, Radium o React Styles. Aunque se me puede persuadir de lo contrario.

Espero completar este cambio de arquitectura para que podamos volver a fortalecer nuestros componentes existentes.

¿Este cambio hará que sea difícil anular los estilos predeterminados?

@DylanPiercey gran pregunta. Como mencionó @ hai-cea, no hemos sentido la necesidad de usar bibliotecas relacionadas con el estilo. Todos los estilos de componentes se definirán en línea, por lo que ya no habrá archivos Less (aparte de los del sitio de documentos).

Este es actualmente nuestro enfoque para anular estilos:

• Los componentes también recibirán un style prop para anular los estilos en línea de un elemento raíz de los componentes. Esto lo llevará a cabo el mixin StylePropable .
  
  
  
  • _Algunos_ componentes tendrán accesorios adicionales para diseñar elementos de componentes internos. Los componentes sin estos accesorios adicionales no tendrán acceso para anular estos estilos. Este es un cambio rotundo
  
  
• Para los usuarios que todavía usan Less, los componentes recibirán un className prop a su elemento raíz, de modo que los usuarios puedan agregar estilo adicional (este es el propósito actual de nuestro mixin Classable ).
• Otro cambio importante es la eliminación de todos los archivos Less, incluidas las variables Less. Esto cambiará mui de ser css-framework y un conjunto de componentes react a _only_ ser un conjunto de componentes react. Creemos que este cambio es más apropiado a medida que continuamos completando más componentes de Material Design.

Una última cosa: también proporcionaremos un archivo de tema utilizando la función de contexto de react como lo sugiere @mjackson para una mayor personalización.

¿Qué piensan todos sobre este enfoque?

Por cierto, lanzamos la creación de temas a través de contexto con reapp-ui . Lo haces así:

const theme = {
  styles: {
    List: {
      self: { background: '#000', ... }
    }
  },
  animations: {},
  constants: {}
}

// top level component
export default React.createClass({
  render() {
    return (
      <Theme {...theme}>
        <RouteHandler />
      </Theme>
    );
  }
});

Consulte el archivo de tema para ver cómo establece el contexto:
https://github.com/reapp/reapp-ui/blob/4355556dee24407e5e7827df7a484944aeaf32cc/helpers/Theme.jsx

También nos resultó útil usar constantes como una capa de primer nivel para que pueda establecer todo tipo de propiedades desde isRetina a listBorderColor y luego esas constantes se pasan a los estilos cuando se cargan a través del asistente . Uso así:

import UI from 'reapp-ui';

UI.addConstants({
  borderColor: '#000'
});

UI.addStyles({
  List: c => ({
    firstItem: {
      border: `1px solid ${c.borderColor}`
    }
  })
})

// exports the theme object you need for the <Theme /> helper
export default UI.makeTheme()

Pensé que esto puede ser útil de ver mientras ustedes se sumergen en él.

@natew Me he inclinado hacia este enfoque. ¿Puede explicar el significado de c ? No estoy muy familiarizado con la función de flecha gruesa de ES6. ¿Es c el nuevo parámetro de constantes? Actualmente, los estilos en línea se anulan mediante la combinación superficial de React a través de nuestra StylePropable .

Sin embargo, este método no maneja objetos json anidados a menos que se pasen explícitamente. Hemos hablado sobre el uso de una combinación recursiva, pero esto será costoso porque cada componente usaría la función de combinación varias veces. Dado que ya estamos usando ES6, esto parece prometedor.

¡Me encanta la idea de refactorizar el CSS de material-ui en Javascript!

Pero me encontré con algunos problemas desagradables cuando intenté usar estilos en línea en JS en lugar de LESS en uno de mis proyectos ...

Safari: error de estilo ondulado en los componentes del botón

El mayor problema fue este: https://github.com/callemall/material-ui/issues/496
Solo pude solucionar los problemas de Safari usando grunt-autoprefixer
Pero autoprefixer solo funciona para LESS / CSS. Entonces, en ese momento, tuve que abandonar los estilos en línea y reescribir mi aplicación para usar LESS. (Eso fue un fastidio ...)

No se admiten pseudoestilos y selectores de medios

Algunas características de CSS como todos los pseudoestilos y selectores de medios no son compatibles con los estilos en línea de react. Al principio terminé usando LESS para las piezas faltantes y estilos en línea para el resto.

Agregar automáticamente "px" a los números

Hay un montón de propiedades en las que los estilos en línea de reacción deciden agregar px a un número. Por ejemplo, order: 1 convierte en order: 1px , lo cual es una tontería.
Tener que lidiar con px no deseados parece ser un problema común, consulte https://github.com/facebook/react/pull/3499

Pobre soporte de minificación

Tengo que usar el compilador de cierre de Google con ADVANCED_MODE para mis proyectos. Cuando intenté usar los estilos en línea de reacción, terminé exterminando al menos estas propiedades:

/**
* <strong i="27">@type</strong> {*}
*/
var __REACT_DEVTOOLS_GLOBAL_HOOK__;

/**
* <strong i="28">@type</strong> {*}
*/
var Symbol;

/**
* <strong i="29">@type</strong> {*}
*/
var MSApp;

Además, tuve que usar cadenas para nombres de propiedades como backgroundSize y float .
Por ejemplo, en lugar de usar

var iconStyle = {
  backgroundSize: "300px 400px",
  float: "left"
};

Tuve que usar cadenas en su lugar para poder compilar con el compilador de cierre de Google en ADVANCED_MODE

var iconStyle = {
  'backgroundSize': "300px 400px",
  'float': "left"
};

¡Pero aparte de esos problemas, todo estaba bien!
No me malinterpretes: creo que los estilos en línea son el camino correcto a seguir. Hay solo algunos baches a lo largo del camino. Tengo la esperanza de que todos esos problemas sean resueltos por Facebook, es decir, @vjeux.

Gracias a las aportaciones de todos, ayer pudimos completar menos refactorización en estilos en línea. El master actual contiene una versión preliminar de la v0.8.0 para que la revisen, y nos encantaría recibir cualquier comentario que pueda tener.

También puede ejecutar el sitio de documentación localmente para consultar la documentación actualizada. A continuación, se muestran algunos aspectos destacados de lo que pudimos lograr:

1. Todos los estilos de componentes ahora se realizan en línea. Esto no solo nos permitió ser más explícitos sobre los estilos que se incluyen en cada componente, sino que también hizo que cada componente sea mucho más portátil. Dado que no hay ninguna dependencia externa menos / css, debería poder requerir cada componente que necesite. Además, los estilos de la biblioteca MUI no entrarán en conflicto con los estilos de su propia aplicación.
2. La personalización se puede lograr en 2 niveles. Puede anular las variables del tema que afectarán a todos los componentes secundarios utilizando el objeto de contexto del tema. Además, cada componente acepta un accesorio de estilo que puede usar para implementar una personalización de grano más fina.
3. El prefijo automático de proveedores se realiza a través de la detección de características utilizando una versión liviana y personalizada de Modernizr. ¿El prefijo solo se hace cuando es necesario y es la mejor parte? Se hace automáticamente para usted dentro de cada componente.

Me gustaría tener este horneado maestro durante una semana o 2 antes de lanzarlo. Durante este tiempo, trabajaremos en la recopilación de código de ejemplo y la conversión de algunos de los estilos del sitio de documentos para usar estilos en línea.

Gracias de nuevo por el aporte y la paciencia de todos. Tenemos muchas ganas de publicar esto y volver a abordar los problemas y agregar nuevos componentes. :)

¿Necesitamos hacer algo además de usar los componentes?

Tenga en cuenta que estoy tratando de empaquetarlo como un paquete meteoro (esencialmente usando browserify para empaquetar todos los componentes) y puedo hacer algo mal.

Parece que tenemos que crear una instancia de ThemeManager y configurarlo como un tema childContext en un componente en el que usamos componentes material-ui.

EDITAR: theme ha sido renombrado a muiTheme

Hola @ukabu , ThemeManager solo necesita ser instanciado en el componente más externo de su aplicación. Luego pasará a todos sus hijos y nietos. Puede leer más sobre la función de contexto de React aquí y aquí .

Incluya este código en su componente más externo:

Si está usando ES6

var React = require('react');
var mui = require('mui');
var ThemeManager = new mui.Styles.ThemeManager();
class OuterMostParentComponent extends React.Component {
  // Important!
  getChildContext() { 
    return {
      muiTheme: ThemeManager.getCurrentTheme()
    };
  }
};
// Important!
OuterMostParentComponent.childContextTypes = {
  muiTheme: React.PropTypes.object
};
module.exports = OuterMostParentCompone

Si está usando ES5

var React = require('react');
var mui = require('mui');
var ThemeManager = new mui.Styles.ThemeManager();
var OuterMostParentComponent = React.createClass ({
  // Important!
  childContextTypes: {
    muiTheme: React.PropTypes.object
  },
  // Important!
  getChildContext: function() { 
    return {
      muiTheme: ThemeManager.getCurrentTheme()
    };
  }
});
module.exports = OuterMostParentComponent

Se puede ver más documentación sobre cómo usar Temas si ejecuta los documentos localmente y va a #/customization/themes

Gracias. Está funcionando ahora: +1:

Ahora que todos los estilos están en línea, todavía necesitamos tener un CSS de reinicio. Parece que no hay css o menos archivos en el árbol src /. ¿Planeas agregar uno?

@ hai-cea @mmrtnz ¡Felicitaciones! ¿Tiene alguna receta para el código que se basa en las pseudoclases de CSS ? Me perderé :hover seguro, consulte https://github.com/reactjs/react-future/issues/13 . @vjeux recomienda usar onMouseOver pero eso es una molestia. ¿0.8.0 viene con un código de reemplazo útil por :hover ?

@bparadie He cambiado de opinión sobre esto. Creo que quiero que funcione lo siguiente:

<div
  style={{color: 'blue'}} 
  hoverStyle={{color: 'red'}}
/>

@vjeux, ¿estás hablando al nivel del marco de React o sería algo que los proyectos implementarían individualmente? porque en el nivel del marco sería emocionante ...

Sin embargo, pide algunas variaciones como pressedStyle focusedStyle disabledStyle (para entradas), etc.

Además, felicitaciones a todos los que trabajaron en este gran logro: sonrisa:

Me preguntaba si sería mejor usar una clave de contexto más específica para el tema. por ejemplo, muiTheme - entonces esto no entraría en conflicto si hubiera otra biblioteca en la página que también quisiera usar esa clave de contexto, o si quisiera usar context.theme en mi aplicación para mi propia cosa.

@vjeux ¡

@bparadie

Esta es una utilidad con la que he estado experimentando para hacer que el estilo de desplazamiento sea un poco menos molesto ...

'use strict';

const React = require('react');

const withHoverStyle = (Component, compType) => {
  class ComponentWithHover extends React.Component {
    _handleMouseOver() {
      const theme = this.context.theme.component[compType];

      React.findDOMNode(this).style.backgroundColor = theme.hoverColor;
    }

    _handleMouseOut() {
      const theme = this.context.theme.component[compType];

      React.findDOMNode(this).style.backgroundColor = theme.color;
    }

    render() {
      const hoverProps = {
        onMouseOver: this._handleMouseOver.bind(this),
        onMouseOut: this._handleMouseOut.bind(this)
      };

      return React.createElement(Component, Object.assign({}, this.props, hoverProps));
    }
  }

  ComponentWithHover.contextTypes = {
    theme: React.PropTypes.object
  };

  return ComponentWithHover;
};

module.exports = withHoverStyle;

https://github.com/troutowicz/geoshare/blob/css-in-js/app/utils/withHoverStyle.js

Puede usarse así:

'use strict';

const React = require('react');
const FlatButton = require('material-ui/lib/flat-button');

const withHoverStyle = require('../utils/withHoverStyle');

class AuthButton extends React.Component {
  render() {
    return <FlatButton {...this.props} />;
  }
}

AuthButton.propTypes = {
  label: React.PropTypes.string,
  onClick: React.PropTypes.func
};

AuthButton.defaultProps = {
  label: 'Login',
  onClick() {}
};

module.exports = withHoverStyle(AuthButton, 'flatButton');

https://github.com/troutowicz/geoshare/blob/css-in-js/app/components/AuthButton.jsx

Lo quiero en el nivel React y también en el nivel dom :) No está claro cuándo tendré el momento de implementarlo

@troutowicz ¡ Gracias por compartir!

¡Hy!
He visto que estás hablando de CSS en js por un tiempo. Aquí hay una comparación de CSS en JS lib https://github.com/hackhat/css-in-js-comparison echa un vistazo. Ya revisa 3 bibliotecas, podría ser interesante ver los diferentes enfoques a este problema.

También eche un vistazo a https://github.com/hackhat/smart-css , no necesita onMouseOver para agregar ": hover"

¿Alguien tuvo comentarios sobre mi idea de usar una clave de contexto diferente para theme ? por ejemplo, muiTheme

@vjeux, si me indicó la dirección correcta para implementar eso en React, estaría feliz de

Espero que esto se esté probando completamente con otros módulos de reacción que dependen del contexto, porque hasta ahora me he encontrado con al menos una biblioteca que clasifica el contexto de otras bibliotecas: flocks.js. El autor está trabajando en ello, pero asegúrese de que material-ui no va a golpear a react-router ni a ningún otro módulo que use contextos. Sin embargo, es una gran idea, feliz de ver estilos en línea y espero que nos haga la vida más fácil para usar material ui: +1:

@JedWatson Sí, creo que es una gran idea. Definitivamente lo haremos.

@ hai-cea impresionante, me alegro de escucharlo: sonrisa:

@anyong / @vjeux / cualquiera: ¿hay alguna documentación disponible sobre cómo se comporta el contexto cuando hay varias bibliotecas que lo usan? es decir, ¿cómo nos aseguramos (como autores de bibliotecas) de jugar bien? No he realizado muchas pruebas sobre cómo funciona la definición de contexto en diferentes niveles.

@bparadie Me gustaría agregar un mixin o clase como el ejemplo de @troutowicz para pseudo selectores en un futuro cercano, pero por ahora tendrás que usar eventos como onMouseOver . Aunque estoy de acuerdo en que puede ser un fastidio.

@JedWatson Esa es una gran idea, haré una actualización en breve.

@ukabu Actualmente no hay planes para leer un archivo resets.css . Decidimos que Material-UI dejara de ser un marco CSS y se convirtiera en un conjunto de componentes de React. Sin embargo, el resets.css se puede encontrar en línea si es necesario.

@mmrtnz Entiendo, pero tal como está ahora, algunos componentes no se mostrarán correctamente con los estilos del agente de usuario. Ejemplo: si no incluyo ningún CSS, h1 tienen márgenes superiores (estilo de agente de usuario), lo que impide que el título AppBar se alinee correctamente.

@ukabu Entiendo lo que quieres decir, gracias por señalar esto. Los componentes cuyos estilos dependen de resets.css y otros archivos CSS de soporte relacionados se han redefinido en línea. Este parece ser un ejemplo que me he perdido durante la refactorización. Si se encuentran más problemas relacionados con la necesidad de resets.css o cualquier otra hoja de estilo, podemos volver a agregarlos, pero no antes de intentar resolver el problema a nivel de componente primero.

Para hover, etc., abrí # 684.

Gracias a todos por esta increíble discusión. Pudimos lanzar esta función en v0.8.

Tenía muchas ganas de usar esta biblioteca, pero ver que todo usa estilos en línea fue un gran rechazo, no entiendo por qué harías esto, leí las diapositivas sobre por qué se hizo pero no tiene sentido, por qué fusionar apariencia, vistas y la lógica en una sola cosa, la separación de las preocupaciones de las personas, esa es una de las declaraciones más sólidas para la ingeniería de software.

Pablo, estas preocupaciones no están separadas. Si quieres que las cosas se vean
De manera diferente, puede utilizar el administrador de temas, una verdadera separación de preocupaciones.
Por lo demás, lo que deben hacer los componentes y sus html y css están estrechamente
acoplado, y separar eso solo hace que las cosas sean más complejas.

El domingo 23 de agosto de 2015 a las 05:35, Pablo Fierro [email protected] escribió:

Tenía muchas ganas de usar esta biblioteca, pero veo que todo usa
estilos en línea fue un gran rechazo, no entiendo por qué harías
esto, leí las diapositivas sobre por qué se hizo, pero no tiene sentido, por qué fusionar
apariencia, puntos de vista y lógica en una sola cosa, separación de preocupaciones
personas, esa es una de las declaraciones más sólidas para la ingeniería de software.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/callemall/material-ui/issues/30#issuecomment -133778140
.

Wout.
(escrito en el móvil, disculpe la concisión)

Estoy de acuerdo con @pablofierro : el navegador no puede almacenar en caché los estilos en línea y perdemos una funcionalidad CSS bastante básica como :hover , selectores de hermanos o cualquier noción de estilos en cascada.

Es un compromiso ir con estilos en línea para habilitar aplicaciones estáticas solo del lado del cliente y evitar dependencias en cadenas de herramientas de preprocesamiento (paquete web, etc.), pero decepciona proyectos más grandes con la capacidad adicional (aplicaciones isomórficas de manera más prominente). Me encantaría la opción de usar hojas de estilo externas o el uso de compatibilidad con módulos CSS, pero estropearía los casos más simples.

Las cascadas BEM .

@Kagami consideró una mala práctica por parte de quién? Si divide sus hojas de estilo en módulos reutilizables (similar a la filosofía de reacción), esto se vuelve muy fácil de mantener. Incluso la página web de React menciona que es la Vista de sus componentes y no la apariencia, esta decisión de forzar que todo esté en línea es simplemente ridícula.

Esto necesita cambiarse. Inlining ciertamente tiene sus beneficios en algunos casos de uso, pero el marcado resultante es:

• hinchado : se utilizará una tonelada de ancho de banda solo para enviar el estilo. En cada solicitud. 5 veces MÁS GRANDE para alguna ejecución del aplicación de molino. ¿Y si tiene una aplicación con muchos, muchos nodos DOM? ¿Y cómo afecta eso la sobrecarga y el rendimiento de la memoria? Esto trae una gran cantidad de implicaciones con las que no deberíamos tener que lidiar.
• feo : diviértete leyendo lo que genera, es tan agradable como leer css minificado sin formato / sin formato.
• y _stupid_ : desde la especificación CSS 1 , la WW3C incluía clases por una razón. Este estilo de enfoque arroja la flexibilidad / la creación rápida de prototipos / la funcionalidad que la comunidad ha ganado al crear LESS / SCSS / etc. etc. por la ventana. Ya se puede ver cómo se reinventa la rueda; desplácese hacia arriba a través de este hilo y mire todos los comentarios que sugieren diferentes bibliotecas / lo que sea para extraer el css de javascript.

¡Pero espera! Hay más:

• No hay soporte IDE listo para usar
• Sin soporte de psuedoclass

Chicos: _esto es algo que jquery puede hacer_. ¿Por qué tenemos que sacar esto a la superficie? además forzarlo por defecto?

un ejemplo divertido

Abrir herramientas para desarrolladores de Chrome
Intente realizar algunas ediciones de estilo (cambie el color de fondo o algo así) en una página que tenga varios componentes mui del mismo tipo, _e.g. los <MenuItem ...> en un menú de navegación.

solo cambia _ ese_ componente. ¿Qué pasa con React Devtools? no, lo mismo.

No quiero ser un idiota, aunque seguramente sueno como uno, pero como dijo @pablofierro , esto es ridículo. Esta funcionalidad puede ser interesante, la falta de dependencias css es muy atractiva. Pero arrancar el .css no tiene sentido.

Debo agregar; Estaría más que feliz de crear un PR. Solo quiero escuchar lo que la comunidad tiene que decir sobre la reimplementación de esto; con suerte llegará a algún tipo de consenso sobre cómo hacer esto.

¿Qué sugieres hacer en su lugar? Para mi caso de uso (aplicación Cordova), el enfoque en línea es excelente.

@oliviertassinari parece que el mayor beneficio de los estilos en línea es que el proyecto no necesita tener una hoja de estilo externa como dependencia.

Si este es el caso, recomendaría volver a las clases (ya que parece que muchos quieren eso y parece simplificar las cosas) y en su lugar exponer todo el CSS a través de una cadena.

/*styles.css for people who are fine with a separate file*/
.my-styles {...}

// styles.js (expose as "material-ui/theme" or something)

var css = { __html: "injected styles.css content" };

// alternatively we could expose a component.
module.exports = (
    <style dangerouslySetInnerHTMLIfYouAreSureItIsWhatYouWantToDo={ css }/>
);

De esta manera, las personas pueden usar el tema directamente con JavaScript mediante:

theme = require("material-ui/theme");

MyJSX = (
    <div>{ theme }</div>
);

Pros:

• es solo css
• potencialmente múltiples temas sin que todo esté incluido
• se puede importar a través de js, preprocesador css o manualmente en html.

Contras:

• se dedicó mucho tiempo a hacer todos los estilos en línea.

@rozzzly +11111110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Con MUI -> http://recordit.co/9mBknPLZUb
Sin MUI -> http://recordit.co/6MkzWhQiBt

Bueno @rozzzly , no estoy de acuerdo.

• hinchado . Claro, usamos más ancho de banda para enviar el estilo cuando el usuario llega al sitio.
  Pero la latencia, y no el ancho de banda, es el cuello de botella en el rendimiento de la mayoría de los sitios web. para más detalles .
  Entonces, creo que enviar el estilo en línea más abajo la primera vez de renderizado. Y esto es lo que realmente importa para los usuarios. No tiene que esperar el RTT (tiempo de ida y vuelta) para tener el estilo.
• feo . Sí, no es fácil de leer. ¿Por qué necesitas leerlo?
• y estúpido . Facebook explicó sus motivaciones para usar el estilo en línea. Es bastante convincente. El enlace

He estado usando estilos en línea exclusivamente durante más de 6 meses y ha sido una experiencia liberadora. Los estilos se han vuelto más manejables, flexibles y con muchas menos sorpresas en comparación con CSS.

Personalmente estoy de acuerdo con @rozzzly, quien detalla bien los problemas. Esto simplemente no es una buena idea a gran escala. CSS funciona. Estamos reinventando la rueda para que sea más "portátil". Este loco cambio se reduce a solucionar un problema, incluido css. Esto requeriría 1 línea de explicación en el archivo Léame. Sin mencionar que incluso los desarrolladores novatos están bien versados ​​en incluir CSS en HTML o con su herramienta de construcción. Esta no es gente nueva.

En su lugar, estamos reconstruyendo el estilo de las páginas web en JS. Parece una tontería. ¿Funciones de estilo absolutamente básicas como pseudo elementos? Ido. ¿Compilación SASS / LESS? Ido.

Hola a todos. Comencé a usar material-ui en un proyecto paralelo y he estado siguiendo la discusión aquí y aquí .

Quería agregar algunos puntos a la mezcla:

¿Tiene sentido esto para aplicaciones más pequeñas?
He escrito muchas aplicaciones web internas más pequeñas para empresas que utilizan bootstrap y similares. Nunca he sentido mucho dolor al tener que incluir más componentes-css junto con su marcado y js. _Es un esfuerzo de una sola vez_. Los conflictos rara vez eran un problema y eran fáciles de resolver la mayor parte del tiempo.

Pero definitivamente siento dolor al mirar el DOM en mis herramientas de desarrollo ahora. Incluso ver la estructura básica del árbol es mucho más difícil con todos los estilos en línea. Y este dolor no es algo de una sola vez, vuelve cada vez que abro devtools.

¿Estamos alienando a los diseñadores expertos en CSS con este enfoque?
Con todos los estilos incrustados en JavaScript, parece difícil para los diseñadores que están acostumbrados a redactar y editar trabajos en archivos CSS. ¿No están ahora obligados a aprender JavaScript, ES6, transpilers, herramientas de construcción, etc. y es mucho más probable que rompan cosas?

Tal vez eso no sea algo malo: estoy a favor de los equipos multifuncionales y todavía no he trabajado con "diseñadores de componentes", pero quiero asegurarme de que los diseñadores también sean considerados en esta discusión.

También:

+1 para la separación de preocupaciones: el estilo y la lógica de la interfaz de usuario deben separarse en mi libro
+1 por considerar la falta de soporte IDE

Estoy absolutamente de acuerdo en que existen problemas con CSS especialmente a escala. Espero que esta discusión conduzca a un mejor lugar para todos nosotros en este sentido.

Bueno, yo también encontré la charla convincente, pero en la práctica usé principalmente CSS con
el cambio de nombre basado en módulos y tal vez algo de estilo en línea es lo más fácil de
trabajar con en mi humilde opinión.

El martes 24 de noviembre de 2015 a las 9:49 a.m. Owen Campbell-Moore [email protected]
escribió:

Por lo que vale, el uso de estilos en línea fue una de las principales razones por las que me convertí en un
gran fan de MUI. Encontré la charla de Facebook extremadamente convincente y
personalmente siento que el estilo y la estructura no tienen sentido para estar separados
al crear interfaces de usuario.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/callemall/material-ui/issues/30#issuecomment -159198060
.

Wout.
(escrito en el móvil, disculpe la concisión)

Puntos interesantes @mpseidel. Sin embargo, creo que a medida que más y más marcos se mueven hacia componentes, me parece que mantener JS y CSS juntos como parte del componente tiene más sentido que tener una inclusión de CSS más global que cubra una variedad de componentes, páginas, etc. Sin embargo, el concepto de componentes de tematización me tiene rascándome la cabeza ... No sé mucho de CSS, así que tal vez haya una manera fácil para que los componentes escojan estilos de tematización para sobrescribir sus estilos predeterminados para que los escritores de componentes puedan encajar sus componentes un estilo de tema general? Si lo hay, me gustaría entenderlo más.

Aquí hay una gran discusión. Y es difícil adivinar la dirección general.
¿Alguien puede estimar las posibilidades de que los estilos vuelvan a ocupar su lugar?

Todavía no uso material-ui. Y desde mi punto de vista "fresco", veo estos problemas que me advierten de utilizar este proyecto en el futuro:

• las capas de presentación y lógica están desordenadas
• degradación del rendimiento debido a estilos en línea
• difícil de agregar estilos propios
• DOM ilegible feo

No veo ningún beneficio de los estilos en línea.

Sería mejor reorganizar menos / sass / css de una manera más legible y fácil de mantener que intentar reinventar el estilo desde cero.

Esta discusión está prácticamente terminada.
Siga https://github.com/callemall/material-ui/issues/684.

@oliviertassinari .. ¿significa que no hay forma de volver a CSS?

Significa que estamos explorando opciones para mejorar el enfoque de estilo actual (módulos CSS, Radium, Looks, react-themeable).