Algunas preguntas más:
6) ¿Eliminaremos o intentaremos eliminar xxxxStyle props y los usuarios pasarán un xxxClassName para anular estilos? ¿O serán complementarios?
7) ¿Permitiremos la anulación de estilos a través de CSS y simplificaremos las interfaces de nuestros componentes? Entonces, si quiero anular menuItemStyle en IconMenu, ¿creo una anulación de tipo style = StyleSheet.create({ IconMenu: {MenuItem: { color:red }}) ?

@chrismcv Mi opinión personal es que definitivamente necesitamos aprovechar la solución para eliminar estos accesorios súper específicos que estamos viendo propuestos: [TextField] agregar flotanteLabelFocusStyle prop # 4043

Antes de que nos demos cuenta, la gente pedirá accesorios para estilos de subcomponentes para cada posible enfoque / activo / desplazamiento / cualquier estado.

Veo tantos problemas que son "cómo diseñar XXXX", "no puedo diseñar XXX dentro de YYYY", "agregar somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle prop a XXX, por favor"

@chrismcv en 6. con respecto a los xxxxStyle props más generales frente a classNames, ¿qué opinas? con algunos de nuestros componentes, necesitará poder llegar de una forma u otra (¡afortunadamente, podremos usar :hover etc., aunque!).

@chrismcv Creo que xxxxStyle props deberían ir en la propiedad style , no en el objeto de estilo className .

@nathanmarks Gracias por

Fuera de problemas de rendimiento

Para mí, esa es una de las principales preocupaciones que tengo con la solución que elegiremos.
No tenemos muchos puntos de referencia, ya que podemos imaginar fácilmente que perdimos muchos ciclos de CPU con nuestro enfoque actual. Los ciclos de la CPU se pierden en las asignaciones de memoria y la recolección de basura para nuestro objeto de estilo en línea.

@oliviertassinari

Estoy jugando con un par de soluciones de estilo JS en este momento. Es interesante pero claro que todavía son "los primeros días", por así decirlo.

Una cosa en la que estaba pensando: fuera de las propiedades de estilo dinámico (por ejemplo, si el componente tiene un color prop), ¿deberíamos cambiar la forma en que creamos el objeto de estilo base?

Parece que con las bibliotecas de estilo JS, para obtener el máximo rendimiento, debe usar su método StyleSheet.create() una vez y tener claves (css "clases") en ese objeto para accesorios / estados como open={true} en lugar de construir dinámicamente el objeto de estilo literal con un par de propiedades condicionales y pasarlo al método de fábrica de hojas de estilo en cada renderizado para cada estilo.

Aunque los selectores de hojas de estilo se almacenan en caché en el sentido de que se escriben solo una vez en el DOM (y en algunas bibliotecas solo se escriben en el DOM cuando se necesitan para render() ), seguimos desperdiciando recursos con algunos cálculos. + creación de objetos + recolección de basura como mencionaste anteriormente si estamos creando un nuevo objeto de estilo en cada renderizado solo para descartarlo.

Hmmm ... Dejé un comentario aquí ayer (domingo). ¿Fue eliminado?

@rvbyron Lo recuerdo claramente. Sin embargo, ciertamente no lo borré.

@rvbyron Yo también lo recuerdo. No tengo idea de que pasó.

@rvbyron : lo tenía en mi correo electrónico, ¡así que de vuelta aquí en forma de cotización!

Bueno, por mi parte, me gustaría ver que sucedan varias cosas.

R) Sí, por supuesto, elimine el uso del parámetro de estilo del elemento a nivel de biblioteca. Todos los componentes deben definirse mediante className. Hacer que los componentes usen estilo destruye toda la potencia que ofrece CSS.
B) Sería genial tener classNames adjuntados automáticamente al elemento raíz de cada componente (por ejemplo, el componente RaisedButton tendría implícitamente className = "mui-raise-button" en el elemento raíz del componente). Facilitaría mucho el peinado. Eso incluso podría ser configurable.
C) Elimine la creación de temas de los archivos muiTheme.js por completo. Un archivo de tema muiTheme.SCSS sería mucho mejor, ya que permitiría aplicar cualquier propiedad elegida por el creador del tema y no solo las específicamente permitidas por el componente. Por supuesto, esto probablemente requeriría que B esté implementado y activo.
D) React-look parece ser un buen compromiso ya que convierte objetos JSON que contienen propiedades de estilo en classNames. Hace que las cosas sean más fáciles de anular. Sin embargo, como dije anteriormente en C, aún me gustaría que la base de temas se creara en SCSS. Estoy bastante abierto sobre qué paquete de asistencia CSS usar. Pero me mantendría alejado de cualquier cosa que quisiera usar el parámetro de estilo del elemento sobre el parámetro className.

@chrismcv ¡ Gracias amigo!

Creo que lo que @rvbyron tiene que decir es importante porque, de alguna manera, el estilo JS es en gran medida un cambio de paradigma del CSS normal. La mayoría de la gente no usa el estilo JS en su trabajo diario y requiere una forma diferente de pensar + lo hace más difícil para los diseñadores que generalmente pueden contribuir a proyectos que no son tan competentes en JS.

Es importante considerar todos los ángulos aquí.

@oliviertassinari @chrismcv

Una cosa de la que me di cuenta de react-look es que debes envolver todos tus componentes en el look HoC . Esto parece bastante invasivo, incluso secuestra la función render() , almacena super.render() en un const y realiza operaciones de resolución de estilo de esa manera. Algunas otras soluciones como Khan / aphrodite solo requieren un envoltorio de función alrededor de la referencia styles.xxxx de Stylesheet.create() dentro de className={} .

Secuestrar la función render() solo para css me parece sobre-diseñado. Me dice que las herramientas incorporadas de React / soporte para este tipo de funcionalidad de estilos profundamente integrados simplemente no existe, no estoy seguro de la idea de un asistente de CSS HoC que controle el renderizado de todos nuestros componentes.

Pensamientos

¡Hola, equipo de Material-UI!

Lo he estado siguiendo por un tiempo y ahora, al ver este tema, también quería contribuir con algunas ideas sobre por qué pasar de estilos en línea a CSS podría ser una buena idea. He leído muchas discusiones en este repositorio que cubren el rendimiento de la representación, el estilo de los elementos secundarios / anidados, las consultas de medios, los pseudo-elementos, etc., así que me enfocaré en algo más que aún no he discutido, pero que creo que también es relevante. Y es la organización de estilos. Esto es lo que quiero decir:

• Algunos estilos provienen de los valores predeterminados del componente (que se establecen en la carpeta del nodo y no se pueden tocar)
• Algunos provienen de parámetros de componentes (por ejemplo, el parámetro de componente de Avatar size={40} establece el ancho, alto y alto de línea en 40px )
• Cuando se personalizan los valores predeterminados de los componentes (los colores del tema), los estilos provienen del lugar de personalización del tema
• Cuando el resto de estilos de componentes se modifican, los estilos provienen de la implementación de un componente, que es otra parte del código.

Cuando se trata de ajustar los estilos, hay al menos 4 ubicaciones diferentes (👆) para mirar, lo que dificulta la investigación de problemas.

Cuando los estilos vienen con css, verá el selector y sabrá exactamente dónde corregirlo. Con los estilos en línea, se necesita tiempo para comprender de dónde proviene la propiedad en particular, y dónde y qué se debe modificar. Y si el desarrollador lo modifica en el lugar equivocado (digamos en el área styles lugar del parámetro size , ya que nada realmente dice que size es el estilo) afectará el todo el rendimiento del bloque width=height=line-height=40px , o conducirá a escribir nuevamente width/height/line-height que hará que el parámetro size inaplicable.

Además, también dificulta investigar cuáles de los elementos principales tienen aplicadas propiedades específicas, porque todo lo que puede ver en el inspector es element.style .

Cuando los estilos vienen con selectores (nombres de clases), da mucho más control sobre la estructura de estilos que los estilos en línea.

Actualización: Olvidé mencionar la sugerencia (de la que trata este tema):

/component
--component.js
--component.css (or sass that is converted to css when the page is rendering)

Esta estructura mantendrá el componente en el alcance, pero le dará más control sobre el estilo. Y una convención de className de BEM ayudará a evitar anidaciones innecesarias:

.mui-component {}
.mui-component__child {}

Lo que en general ayudará a implementar, ajustar y mantener los estilos de Material-UI.

@chrismcv

¡Gracias por encontrar el correo electrónico y colocarlo en el comentario!

¿Lo mejor del enfoque de comportamiento de ambos mundos?

¿Qué tal un concepto de "comportamiento" de importar la técnica de peinado que mejor se adapte a sus necesidades? Se podría utilizar una importación de "StyleTheme" o "ClassTheme" para seleccionar el comportamiento. StyleTheme podría referirse al objeto muiTheme material-ui que tiene hoy y hacer felices a los desarrolladores de estilos centrados en componentes. O ClassTheme que usaría un archivo SCSS que se construye a partir del objeto muiTheme.js (sincronizado) haciendo felices a los desarrolladores centrados en CSS. Eso significaría que todos los componentes necesitarían acomodar {... theme.ComponentName} en los elementos de render.

Para ofrecer un ejemplo muy simplificado, un componente RoundButton tendría el método de renderizado como:

render() {
    return (<button {...theme.RoundButton} />);
}

Para el comportamiento StyleTheme, theme.RoundButton contendría:

{ 
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

Para el comportamiento ClassTheme, theme.RoundButton contendría:

{ 
    className: 'mui-round-button'
}

Una combinación de los dos podría recuperarse como comportamiento ClassStyleTheme, theme.RoundButton contendría ambos:

{ 
    className: 'mui-round-button',
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

El archivo mui-theme.scss se generaría a partir del archivo muiTheme.js y reflejaría en SCSS las propiedades exactas que contiene el archivo JS. La carcasa de camello de los nombres JS se convertiría en nombres de clase más estándar:

mui-round-button {
    display: inline-block;
    border-radius: 20px;
    width: 40px;
    height: 40px;
}

Cualquier personalización CSS de los componentes MUI serían simplemente clases idénticas cargadas después de que se cargó el archivo mui-theme.scss, anulando así las propiedades de mui-theme.

@oliviertassinari

Creo que usar algo como scss (+ módulos css para espacios de nombres / hash) tiene muchos beneficios. ¿Es esto algo a lo que te opones al 100%? Probablemente estoy un poco sesgado porque es lo que estoy acostumbrado a usar en el trabajo, pero mucha gente está en el mismo barco.

Mi principal problema con la situación del estilo JS es que parece que todas las soluciones aún están en proceso. No hay muchas evaluaciones de desempeño en el mundo real para ver, las librerías que estamos viendo no están probadas y siento que estamos pasando mucho tiempo tratando de descubrir cómo hacer estilos en JS correctamente. El objetivo principal de esta biblioteca es implementar la especificación de diseño de materiales y no puedo evitar sentir que esto nos está paralizando en este momento. (definitivamente necesitamos resolver los problemas de impacto de rendimiento)

Creo que tenemos diferentes preocupaciones al respecto.

1. Dónde poner los estilos estáticos (fácil, un archivo css puede hacerlo)
2. Cómo cambiar algunos estilos según la entrada (cambio de nombre de clase)
3. Cómo aplicar estilos dinámicos (los estilos en línea pueden hacer eso)

Todo parece bueno cuando está escribiendo una aplicación, nadie fuera de su código necesita cambiar nada.

Pero con las bibliotecas las cosas son diferentes, todas las preocupaciones anteriores están ahí, más las siguientes:

1. ¿Cómo permitir a los usuarios personalizar los estilos estáticos?
2. ¿Cómo implementar el tema de una manera que sea fácil de cambiar, personalizar y aislar (subárbol diferente, tema diferente)?
3. ¿Cómo evitar contaminar el espacio de nombres global para que podamos jugar bien con los demás?
4. ¿Cómo pueden los usuarios anular los estilos dinámicos en línea?
5. transformadores! (rtl, prefijo, etc.)

Lo que tenemos ahora mismo maneja de alguna manera todas esas preocupaciones con estas advertencias:

1. ¡Actuación!
2. Los componentes profundamente anidados son difíciles de personalizar, como dijo @nathanmarks : somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
3. No podemos utilizar el poder de algunas funciones CSS.

Si cambiamos nuestro enfoque de estilo, tendremos que volver a hacerlo. Si se trata de eso, debemos asegurarnos de responder a todas antes de comenzar la migración.

En mi humilde opinión, creo que CSS y lo que sea que lo compile no son parte del futuro. Creo que todos estamos de acuerdo en que los estilos en línea nos hicieron la vida mucho más fácil. Honestamente, la única limitación que veo con los estilos en línea es :hover .

Podemos resolver esos problemas con un poco de diseño.

1. memorizar el objeto de estilos, para los componentes que tienen estado, podemos desglosar el estado y ponerlo en un componente más pequeño para que el objeto de estilo en él se pueda memorizar en función de los accesorios pasados ​​que son el estado del componente superior. ¡Esto se puede solucionar fácilmente!
2. romperlos! ¿Por qué tenemos un ListItem con MUCHAS pequeñas funcionalidades incrustadas en él? podemos desglosarlo y hacerlo componible, entonces no tenemos que agregar monstruosidades como somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
3. meh! todo lo que obtenemos rendimiento es :hover Creo que podemos vivir con eso hasta que los navegadores o reaccionen haga algo al respecto.

Mi punto es que ya abordamos una gran cantidad de preocupaciones con nuestro enfoque de estilo actual. Tiene limitaciones porque no seguimos todos los patrones relacionados con los estilos en línea. si comenzamos a descomponer nuestros componentes y hacerlos mucho más componibles, entonces realmente no tenemos que preocuparnos por nada. tome MeuItem Lo saqué y lo hice componible, ¡ya ve lo fácil que es usarlo y cómo se puede mejorar el rendimiento usando el renderizado puro!

Entonces, en lugar de cambiar nuestro enfoque y resolver todos estos problemas nuevamente, invirtamos el tiempo en mejorar lo que ya tenemos. no necesitamos admitir consultas de medios, podemos cambiar nuestros componentes de una manera que sea fácil para otros implementar la capacidad de respuesta en ellos. ¿Difícil de depurar? si desglosamos nuestros componentes, los estilos en línea serán más pequeños y más fáciles de leer. aunque discutible! Quiero decir, todo lo que necesita es un punto de interrupción para ver qué participa en Object.assign para ver de dónde provienen los estilos.

Por supuesto, esa es mi propia opinión. Estoy muy abierto a la discusión.

@alitaheri

Planteas algunos grandes puntos. Gracias. Me pregunto si existe la posibilidad de algún tipo de solución híbrida. Parece que no importa qué ángulo tomemos, hay un montón de problemas 😆

Tengo tiempo para trabajar en esto la semana que viene; charlemos y veamos si se nos ocurre una idea inteligente.

Estoy de acuerdo con intentar minimizar la cantidad de cambios y tener que volver a resolver los problemas ya resueltos. Hay dos objetivos importantes aquí en mi mente:

1. Actuación
2. Experiencia de desarrollador (las bibliotecas de estilo JS ayudan mucho aquí al permitir que los desarrolladores usen clases en sus aplicaciones con facilidad)

Necesito pensar más en esto, pero mientras logremos resolver esos 2 puntos, estaré contento con nuestra solución.

Otra nota aleatoria: sería genial si tuviéramos una forma automatizada de hacer cumplir ciertas convenciones de código y patrones de diseño para inline / jsstyle / lo que sea en la biblioteca.

¿Es esto algo a lo que te opones al 100%?

@nathanmarks No me opongo al 100% a usar SCSS (_Lo estoy usando en el trabajo_). Pero desde mi punto de vista, es un callejón sin salida .
Una de las principales ventajas de React es abstraer la especificidad de renderizado de los navegadores: el DOM.
Hasta donde yo sé, el objetivo a largo plazo del React Core Team es proporcionar una API para escribir componentes multiplataforma. De hecho, actualmente están

Estoy completamente de acuerdo con @alitaheri. Podríamos comenzar con esos dos pasos:

• Use el patrón getStyles todas partes para que podamos migrar más fácilmente más adelante.
  ¿Podremos utilizar un codificador? Quién sabe.
• Desglosando cada componente según lo propuesto por @alitaheri.

@oliviertassinari Estoy de acuerdo con la conclusión del callejón sin salida: no es el futuro. Lo mencioné en gran medida para estimular la conversación sobre cómo hacer que los estilos JS funcionen para nosotros. Sabía que algunas personas por aquí tenían buenas ideas en torno a los problemas. ¡Ojalá FB estuviera un poco más lejos con sus experimentos!

De hecho, creo que el patrón getStyles() que empleamos actualmente tiene sus propios problemas. @alitaheri y yo tuvimos una buena charla hoy sobre qué hacer para mejorar nuestra configuración de estilo JS (¡incluida la temática!). Te responderé mañana con más información una vez que tenga la oportunidad de tomar algunas notas.

La semana que viene estoy de vacaciones y voy a experimentar con una solución a nuestros problemas actuales manteniendo todos los estilos basados ​​en JS.

Solo lea esta publicación sobre Lecciones aprendidas en React Amsterdam (https://medium.com/@kitze/lessons-learned-at-react-amsterdam-51f2006c4a59#.o12h794or) y una de las presentaciones fue sobre soluciones para el estilo en React: http : //slides.com/kof/javascript-style-sheets#/ Una presentación oportuna para esta discusión.

Un requisito en el que sigo pensando y que no he visto explícitamente declarado (al menos que recuerdo) es la necesidad de admitir solo web frente a web y reaccionar nativo. Si la intención es solo web (es decir, reaccionar de forma nativa no es un requisito), entonces las soluciones que aprovechan lo que los navegadores ya admiten de manera eficiente y sólida y la gente está muy familiarizada serían algo bueno. Si el soporte de react native es imprescindible, eso abre un conjunto diferente de necesidades y requisitos. Solo algo para pensar y tener en cuenta a medida que se evalúan las opciones tecnológicas, los compromisos, etc.

@hburrows

¡Gracias por compartir esa presentación!

@alitaheri

Es posible que queramos ver la biblioteca mencionada en esa presentación ( aquí hay una demostración ). Podría ahorrarnos mucho trabajo. Lo estaba viendo anteriormente, pero había algunas cosas que no me gustaban (como el requisito de envolver cada componente en un HoC propietario). Sin embargo, hay algo de discusión sobre algo de eso que sucede aquí . Menciona que implementar cambios como este permitiría un uso libre de HoC. Prefiero ese método / diseño para la escritura de la hoja (también se ve en aphrodite ).

Alternativamente, siempre podríamos crear nuestros propios enlaces de reacción para jss que puedan funcionar con mixout .

El autor de la biblioteca también dijo esto, que coincide con mis propios pensamientos sobre el tema 👍:

Sin embargo, debe comprender que no todo tiene sentido para ser hojas de estilo. Para los cambios más dinámicos, debe utilizar estilos en línea.

@nathanmarks La implementación es bastante pequeña y muy fácil de mezclar: grin:
https://github.com/jsstyles/react-jss/blob/master/src/index.js
Creo que esta biblioteca puede ayudarnos: +1:

@alitaheri ¡ Sí, estoy de acuerdo!

También estoy experimentando con algunos enlaces personalizados por jss ; hay un par de problemas / limitaciones que quiero intentar abordar. (Uno, aunque puede requerir trabajo en la biblioteca principal)

Parece haber un sentimiento predominante en la comunidad de React de que el estilo de JavaScript es la mejor solución. Ese sentimiento está bien, no estoy en desacuerdo con quienes lo tienen. Sin embargo, la forma en que se implementa el estilo de JavaScript es casi siempre sin tener en cuenta al desarrollador de CSS. La implementación con demasiada frecuencia favorece style=/[element property]= sobre className= y evita que el desarrollador de CSS haga su trabajo.

Como dije en un comentario anterior, creo que los dos podrían vivir bien juntos. Simplemente hay que adoptar un enfoque conductual para aplicar las propiedades de estilo. La biblioteca debe acomodar la aplicación directa de propiedades de estilo a un elemento, o debe permitir el enfoque indirecto de crear un className compuesto por esas propiedades de estilo. Una biblioteca que permite al desarrollador elegir el comportamiento parece una solución ideal.

Hay muchas razones por las que los desarrolladores de CSS no quieren simplemente deshacerse de su enfoque. Busque "por qué usar css" para ver por qué las personas lo encuentran beneficioso. Encontrará la abstracción de estilos y un poderoso selector de lenguaje entre sus beneficios. No olvidemos la enorme cantidad de código que existe hoy que beneficia a los usuarios de CSS.

Nuevamente, esto no pretende ser un comentario CSS profesional de ninguna manera. Algunos de nosotros nos gustaría usar CSS para diseñar. Este comentario tiene como objetivo fomentar un enfoque de estilo arquitectónicamente neutral que permita a los desarrolladores tener la opción.

@rvbyron Una de las principales razones por las que queremos cambiar nuestro enfoque actual es para que sea más fácil personalizar los componentes usando css también. el uso de una biblioteca como jss nos permitirá usar las funciones css mientras aprovechamos los estilos js. Y dado que convierte esos estilos en CSS, se pueden anular fácilmente con un nombre de clase adicional sin el feo truco !important .

@alitaheri ¡Es genial escucharlo! Tengo muchas ganas de ver material-ui adaptarse a un enfoque basado en className.

Nuevamente, es fantástico escuchar sobre el enfoque className. Con esto en mente, tengo algunas preguntas sobre cómo podría implementarse:

• ¿Cómo cree que sería la convención de nomenclatura de nombres de clases?
• ¿Todos los nombres de clases tendrán un prefijo "mui-" u otro prefijo?
• ¿La clase será una notación de guiones del nombre del componente?
• ¿Se aplicará un nombre de clase al elemento raíz de cada componente?

@rvbyron

Idealmente:

Prefijo personalizable. Una notación de guión de algún tipo para una mejor experiencia de desarrollo y un sufijo hash que también se puede establecer en una cadena fija (por lo que no cambiará si se cambia la configuración del tema) usando un ID de tema personalizado. Incluyendo una opción de producción menos detallada, o incluso una función de devolución de llamada para personalizar. Y supongo que una clase sobre la raíz siempre será necesaria de todos modos.

Creo que se enumeran muchos requisitos y se ofrecen sugerencias. Entonces, ¿hay algo para quitar de toda esta discusión? ¿Cuál es el próximo curso de acción? ¿Se está trabajando en la implementación de react-jss en este material-ui?

@rvbyron Sí, estamos experimentando con un par de ideas aproximadas entre bastidores. Actualizaremos este número cuando tengamos algunas ideas más concretas.

En mi humilde opinión, creo que CSS y lo que sea que lo compile no son parte del futuro. Creo que todos estamos de acuerdo en que los estilos en línea nos hicieron la vida mucho más fácil. Honestamente, la única limitación que veo con los estilos en línea es: ¡hover!

El problema es que: hover es una parte muy básica y vital de los estilos. Dejando a un lado el futurismo, podría ser prudente evitar un compromiso prematuro con una solución que deba recurrir a trampas y soluciones para volver a implementar una característica nativa.

@wtgtybhertgeghgtwtg estamos trabajando hacia una solución que use hojas de estilo reales para que se admita funcionalidades como :hover .

Dado que se han decidido los puntos principales (estilo JSS a través de className y classNames del elemento raíz), ¿existe alguna hoja de ruta y línea de tiempo para el lanzamiento de material-ui v0.16.0?

@rvbyron No tenemos una línea de tiempo prometida, pero a partir de ahora, el enfoque de estilo y el rendimiento son nuestro enfoque principal para la versión v0.16.0 y algo en lo que estamos trabajando activamente ahora. Es probable que utilicemos este problema en un futuro próximo para los comentarios de la comunidad una vez que hayamos decidido la dirección correcta en algunas otras áreas en lo que respecta a los aspectos internos, API, migración, etc.

@newoga ¡ Gracias Neil! Agradezco la actualización. En cuanto a los otros problemas, me gustaría agregar que simplemente ir a un sistema basado en className puede ser un cambio visualmente rompedor para muchos y sugeriría limitar esta versión a eso. Otros cambios además de eso realmente podrían impedir una migración. Sin embargo, sé que su equipo elegirá el mejor equilibrio.

@newoga aquí jss ha sido llamado como el futuro del sistema de estilo para material-ui. ¿Es este un plan lo suficientemente concreto como para que otros puedan comenzar a incorporar jss en nuestros proyectos ahora, en previsión de la versión 16.0?

@sorahn todavía no

@sorahn Este problema está diseñado para obtener comentarios de la comunidad sobre lo que todavía es un problema realmente difícil de resolver. No se han tomado decisiones oficiales. A partir de ahora, todos deberían elegir y utilizar una biblioteca de estilos o un enfoque que hayan evaluado que sea mejor para ellos y su proyecto.

Para el registro, el objetivo de este cambio de estilo no es migrar a todos a un estándar diferente, sino facilitar el uso y el estilo de los componentes de Material-UI, independientemente del enfoque de estilo que use con ellos.

tl; dr ¡No! Haz lo que sea mejor para ti, no lo que digan los demás :)

@nathanmarks @newoga ¡ Gracias por la actualización!

Nos encontramos con las limitaciones del diseño receptivo + la representación del lado del servidor con todos los estilos en línea, por lo que estamos investigando las alternativas. No hay opiniones particularmente sólidas sobre los módulos css o csx o lo que sea, pero nos encanta material-ui, así que sería genial seguir lo que sea que vayan a hacer :)

Me encontré con consultas de medios, leí este hilo (y otros). Me sumergí en algunas de las posibles soluciones y artículos.

Realmente me gusta la solución JSS + CSX (desde la perspectiva de un desarrollador _joy_).

Beneficios y rendimiento de JSS

Al igual que @sorahn , me complacería adoptar un estándar de material-ui, espero que @nathanmarks funcione en esta dirección y valide este enfoque. Además, parece que los desarrolladores de CSX / JSS están ansiosos por ayudar y promover la adopción de sus bibliotecas.

@rosskevin Trabajando en ello mientras hablamos, hay cosas a considerar aquí que no se han cubierto en ninguna de las soluciones hasta la fecha.

Nuestros requisitos son mucho más amplios de lo que las soluciones existentes son capaces de soportar debido a limitaciones de diseño u opiniones. Esto se debe en gran parte a que las soluciones existentes se han desarrollado teniendo en cuenta las aplicaciones en las que tiene un control total sobre el consumo de las API de sus componentes frente a una biblioteca en la que tiene un conjunto diverso de usuarios que desean diseñar sus componentes con diferentes herramientas.

@sorahn Pregunta rápida: ¿qué está haciendo con los prefijos de proveedor con la representación del lado del servidor? ¿Está renderizando todos los prefijos en el servidor? ¿O estás pasando la UA?

@nathanmarks Estamos enviando el agente de usuario al navegador, pero personalmente no me gusta confiar en eso. ¿Qué tal simplemente ponerlos todos de forma predeterminada y permitir que las personas los anulen a través de accesorios en el objeto muiTheme, o lo contrario, no hacer ninguno de forma predeterminada y permitir que las personas opten por participar?

muiTheme: {
  // other stuff...
  stylePrefixes: ['webkit', 'moz', 'ms']
}

@sorahn Podrás hacer lo que quieras, prefijo, no prefijo, pasar all , pasar un UA, etc.

@nathanmarks Acabo de publicar [email protected]. Cambio más importante: generación de identificación determinista, aquí hay un ejemplo de ssr con react http://jsstyles.github.io/examples/index.html

Solo agrego mi $ .02 aquí ... aunque realmente me gusta la idea de estilos en línea y afrodita me atrae, casi parece que sería más fácil si los estilos estuvieran basados ​​en un formato de biblioteca en scss como bootstrap 4.

Lo que suelo hacer es copiar literalmente el archivo bootstrap.scss y el archivo _variables.scss mientras creo un archivo _mixins.scss ... con esa copia en ./lib/style, actualizo el archivo bootstrap.scss local para hacer referencia al archivo local variables y mixins, mientras usa la ruta a las versiones de node_modules de todo lo demás ...

Luego configuro mi configuración de paquete web para hacer ./lib/style parte de la ruta de búsqueda para la configuración de sassLoader.

De esta manera, puedo tener un archivo main.scss que carga bootstrap, etc ... Desde allí puedo hacer referencia a variables y / o mixins dentro del resto de mi proyecto, y cuando construyo / agrupo la salida, los estilos apropiados son incluido.

El lado negativo de esto es que prescribiría el uso de material-ui como fuente (no precompilado) y paquete web para incluir scss en los paquetes. Dicho esto, probablemente sería la ruta más sencilla de usar variables, clases y combinaciones de estilos existentes.

Nuevamente, me gusta mucho la idea del estilo JS, y tbh me gusta lo que Aphrodite tiene para ofrecer ... Estaba trabajando en algo similar (lo iba a llamar derma) como una biblioteca de estilos para estilos en línea, pero Aphrodite ya hace todo lo que planeado y más.

¿Está finalizada la solución de peinado?

¿Hay alguna actualización sobre esto?

Sí, la sucursal next está usando jss

Acabo de encontrarme con este proyecto y estaba muy emocionado porque se veía genial, la página de ejemplo hizo que fuera muy fácil descubrir cómo usar los componentes y parecía que se usaba ampliamente; sin embargo, estoy muy decepcionado con los montantes en línea y me alegra ver que ustedes se están alejando de ellos. Una de las cosas que me gustaría señalar es que todo lo que tenga que ver con el diseño fuera de estos componentes debe eliminarse y dejar que el estilo del componente principal lo maneje. El componente de nivel más bajo no debería tener márgenes o relleno en él de ninguna manera que alejara los elementos circundantes ... especialmente porque es casi imposible de anular sin interferir con los montantes en línea, lo que significa que necesito investigar y descubrir cómo hacerlo. ese. Realmente no he profundizado mucho en este proyecto porque, lamentablemente, lo encuentro inutilizable. Ciertamente leí muchas de las discusiones sobre el estilo en línea versus el estilo CSS. De todos modos, me perdiste en TextField. Hay un margen en la parte superior de 14 px y en la inferior de 16 px. No me importaría DEMASIADO escribir un estilo simple para anular eso, pero eso es imposible debido al estilo en línea y sería completamente loco para mí tener que crear un componente de nivel superior solo para revertir eso, como envolver su componente con un div y haciendo un margen: -14px 0 -16px o ajustarlo ligeramente con un cálculo de la forma que quiero, pero tener que corregir eso de alguna manera no debería ser realmente necesario. Preferiría mucho más si permitiera que un className se pase como un accesorio como ya lo hace para que el estilo de diseño se pueda aplicar al componente de la forma en que su comunidad quiere diseñarlo. De todos modos, ese es mi $ .02.

Solo para agregar a eso, crear componentes de tipo de diseño para estos o hacer accesorios adicionales para manejar las propiedades del diseño podría ser ideal, como usar un sistema de cuadrícula como foundation y bootstrap. Por ejemplo, usando accesorios como tamaño, canaleta, ancho, columnas, etc., pero comience sin estilizar el exterior de lo que es visible con el componente.

Estoy completamente con @ jbsmith969

Sería completamente loco para mí tener que crear un componente de nivel superior solo para revertir eso, como envolver su componente con un div y hacer un margen: -14px 0 -16px o ajustarlo ligeramente con un cálculo de la forma que quiero

@ jbsmith969 Estoy de acuerdo en que los componentes de bajo nivel no deberían tener ninguna lógica de diseño. Sin embargo, la creación de un componente de mayor abstracción para la especificidad de la aplicación no parece una locura.
En mi humilde opinión, ese es uno de los patrones más poderosos que permite React (gracias a las propiedades de aislamiento).

@oliviertassinari @ jbsmith969 ¡ Eso es exactamente lo que hicimos! Creamos nuestro componente CustomTextField que le paso como 2 parámetros a (nombre de campo y color), y solo hace un poco de lógica alrededor de ellos, luego genera un material-ui/TextField con lo que sea que desear.

¡Son componentes hasta el final!

Entonces, con react tomamos nuestro html y lo ponemos en nuestro js y eso está bien y excelente. ¿Pero tomando nuestro CSS y metiéndolo en nuestro HTML? ¿Eso no le sienta bien a nadie más?

¿Cuál fue la ventaja de alejarse del descaro?

Llámame anticuado, pero ¿qué hay de malo en mantener separados nuestro js / html y css?

Estoy buscando legítimamente algunas respuestas aquí ...

En relación con https://github.com/callemall/material-ui/issues/3614#issuecomment -249095805, el estilo simplemente se convierte en componentes.

Veo las clases de CSS como nuevos componentes: (por ejemplo, btn-danger -como de boostrap)

const DangerButton = ({ hoverColor, style, ...others }) => {
    return (
        <MUI.FlatButton
            hoverColor={hoverColor || Colors.pink100}
            style={{ color: Colors.black, ...style }}
            {...others}
        />
    );
};

Sin embargo, las transiciones son un dolor ...

(para @ jbsmith969 , MUI sigue la especificación de Material Design. Si no quisiera seguir la especificación, esperaría hacer una solución alternativa. Sin embargo, estoy de acuerdo en que MUI es difícil de piratear, pero se debe principalmente a una rareza inconsistente accesorios de componentes, no porque sus estilos estén en línea)

@vizath right Definitivamente tengo el mismo pensamiento. Pero, ¿cuáles son las ventajas de esta solución?

Si hubiera una solución que realmente funcionara al menos tan bien como CSS, consideraría darle una oportunidad. Sin embargo, dado que actualmente no existe una solución (que yo sepa) que pueda hacer eso sin advertencia, realmente no veo el atractivo.

¿Por qué este repositorio está tratando de adoptar lo que parece ser una idea de etapa alfa para una solución en una base de código que de otro modo sería muy útil? Simplemente no creo que estemos allí con el técnico todavía, ni creo que este sea el banco de pruebas adecuado para ese técnico.

@nathanmarks, ¿ puede aconsejarme sobre cómo anular los estilos de los componentes usando JSS? Estoy usando el último código en next

EDITAR: Está bien, solo descubrí que todavía no está completamente implementado. ¡Culpa mía! 😬

Todavía no encontré una buena manera de eliminar el código muerto en las claves de objeto, y con JSS hace que sea obligatorio usar objetos para almacenar estilos.

Ejemplo aleatorio en un componente de la rama next (que no está terminada): https://github.com/callemall/material-ui/blob/b372f6223ec2528dbe02f100e4802334f88445b7/src/IconButton/IconButton.js#L36
No puedo encontrar una manera de encontrar de manera confiable que las clases primary y accent no se utilizan.

Tampoco me gustó la forma en que MUI administraba los estilos en línea antes, por la misma razón (lint habría detectado variables no utilizadas si los estilos se definieran por separado, consulte https://github.com/callemall/material-ui/blob/ 60a202fdc9645aa00f20c52e5152f168a1b0031b / src / IconButton / IconButton.js # L26).

¿Cuál fue la ventaja de alejarse del descaro?

@gdaunton Depende del lado en el que se encuentre con respecto a no usar el enfoque inline-style / sass.

Desde el punto de vista del usuario , proporcionará la siguiente mejora:

• Método de renderizado de reacción más rápido, ya que vamos a confiar en hojas CSS generadas en caché.
• Anulación de estilo simplificado, ya que la precedencia de CSS es menor que la del estilo en línea y los usuarios pueden usar DevTools para identificar la hoja que se va a cambiar.
• Primera pintura más rápida al hacer renderizado del lado del servidor.
  
  
  
  • Los usuarios podrán alinear las hojas CSS críticas y solo la utilizada en la página. Eso es algo que NO PUEDES hacer con _Bootstrap_ ya que es un gran monolito 🙈.
  
  
  • Los usuarios deberían poder uglificar las claves de nombres de clases en producción.
  
  
• Sin dependencia de cadena integrada como _scss-loader_ o _Webpack_.

Desde el punto de vista de un

• No más linter CSS
• No más CSS de preprocesador
• No hay sintaxis CSS para aprender
• Un lenguaje mucho más poderoso para diseñar el componente: JavaScript
• Abre la posibilidad de abstraer el motor de estilo. Por ejemplo, usando react-with-styles

¿Por qué este repositorio está tratando de adoptar lo que parece ser una idea de etapa alfa?

Depende de lo que quieras decir con idea de etapa alfa.
Estamos lejos de ser los únicos en utilizar este enfoque. Por ejemplo, AirBnB, Khan Academy, ReactNative.

funcionó al menos tan bien como CSS

CSS fue diseñado desde el principio para diseñar documentos , no componentes .
Ese es un cambio importante en nuestra industria.

Desde mi punto de vista, es una
Las personas que están detrás de la especificación web son conscientes de este problema y están tratando de abordarlo con el estilo de ámbito local de _Componentes web_.
¿Ha notado todos esos nuevos proyectos desde que se lanzó React en torno a la mejora de CSS y la escritura de estilo basado en componentes?

Sí, la siguiente rama está usando jss

@nathanmarks ¿a dónde puedo ir para ponerme al día con este cambio?

Lo encontré: https://github.com/callemall/material-ui/blob/next/docs/customization/themes.md

@bramick parece que no se trata de next porque esto funciona a partir de 0.15.0

Ok, me estoy perdiendo las novedades ... ¿Alguien?

@bramick next aún no está completamente documentado (sin embargo, tiene un sitio de documentación). Por ahora, tendrá que leer el código fuente y puede hacer referencia al código fuente del sitio de documentación para ver cómo funciona. Solo tenga en cuenta que parte de ella aún puede ser un objetivo en movimiento.

@oliviertassinari ¡Guau! Gracias por la respuesta en profundidad.

No puedo decir que esté completamente de acuerdo, pero desafiante aclaraste algunas preguntas que tenía.

Estoy de acuerdo, deberíamos estar (y estamos) avanzando hacia un mundo donde nuestros estilos se basan en componentes, y css no es bueno para eso. Sin embargo, (en mi opinión) todavía hay algunas arrugas que resolver antes de que deberíamos adoptar esto a escala.

Sin embargo, tengo curiosidad, ¿alguien ha mirado para ver si hay una diferencia de rendimiento entre esto y el CSS estándar? Siento que css todavía podría tener una ventaja en javascript; después de cargarlo, todavía tiene que generar e inyectar sus estilos.

@gdaunton lea sobre el rendimiento de jss en https://github.com/cssinjs/jss/blob/master/docs/performance.md

Es css estándar como se representa, se agrega a la página, pero se crea dentro del componente. Estoy usando la rama next y está funcionando bastante bien.

@newoga, ¿puedes enviarme un enlace a lo que te refieres?

@bramick ¡ next mira aquí .

Entiendo el atractivo de poner CSS dentro del archivo JavaScript, después del éxito de JSX, pero no estoy seguro de si es una buena idea hacer lo mismo con todo el CSS de una aplicación. Sé que JSS tiene algunos buenos casos de uso, por ejemplo, cuando se trata de estilos dinámicos súper complejos.

Mi mayor preocupación es que la información de estilo terminará saturando la definición del componente . El CSS expresado con objetos JavaScript es mucho más detallado y más difícil de organizar . Por ejemplo, en el componente Button que se hace referencia en la publicación anterior, casi la mitad del código es información de estilo. Ya no hay separación de preocupaciones . Sé que puede mover el código de estilo a un archivo separado, pero entonces no tiene sentido tenerlo en JavaScript en primer lugar.

Para los desarrolladores, la mayor desventaja es que pierden toda la información del sentido de inteligencia para las propiedades CSS y sus valores. De hecho, me gusta toda esa agradable estructura de código y expresividad que un preprocesador CSS puede darte, si se usa correctamente.

No me importa agregar complejidad a mis proyectos, si eso aporta más valor. Así que nunca me importó el linter CSS adicional, el preprocesador, el cargador y la sintaxis adicional que tuve que aprender. También estoy tratando de permanecer abierto sobre JSS, es solo que después de la primera mirada no me convenció.

Mi mayor preocupación es que la información de estilo terminará saturando la definición del componente.

Esto depende completamente de usted, depende de cómo organice su código, si se adhiere a algunas reglas, no pasa nada malo (hablando de la experiencia de producción de 2 años).

El CSS expresado con objetos JavaScript es mucho más detallado y más difícil de organizar.

En realidad, es menos detallado porque tiene un mayor nivel de reutilización de código y menos repeticiones.

Para los desarrolladores, la mayor desventaja es que pierden toda la información del sentido de inteligencia para las propiedades CSS y sus valores.

Creo que el objetivo aquí es dar a los usuarios de material-ui la opción de usar lo que quieran para diseñar. Autocompletar para CSS es un argumento que escucho a menudo. En su mayoría, proviene de personas que no usaban mucho cssinjs y es solo miedo a perder algunas comodidades que solían usar.

No me importa agregar complejidad a mis proyectos, si eso aporta más valor.

Creo que el objetivo es reducir la complejidad y hacer que la base de código sea más consistente y fácil de usar y comprender, pero todos los escenarios complejos cubiertos al mismo tiempo.

Mi mayor preocupación es que la información de estilo terminará saturando la definición del componente.

En nuestro proyecto, extrajimos la información de estilo de los componentes en archivos separados y los cargamos con webpack. El principal beneficio es que todo está bien organizado y que el paquete web puede agrupar el código por componente, por lo que es posible dividir el código js y la información de estilo.

También se da la separación de preocupaciones, cuando separa la lógica para producir sus reglas de estilo. Un ejemplo es que introdujimos funciones de fábrica de estilos que producen stlying de manera muy similar a mixins en preprocesadores css bien conocidos.
Mi punto es que obtienes mucha más flexibilidad para modelar tus propios flujos de trabajo específicos y adaptarse mejor a las necesidades del proyecto y del equipo.

consulte esto https://styled-components.com/

Es bastante tarde en el juego para cambiar las tecnologías, pero estoy de acuerdo en que los componentes con estilo son muy prometedores. Maneja SSR, consultas de medios, una sintaxis bastante agradable, etc. En comparación con JSS, también maneja el prefijo automático y la tematización.

Hasta donde yo sé, usa postcss en el interior, que no dará un rendimiento aceptable cuando se use en tiempo de ejecución, porque es un analizador css completo con muchos complementos y manejo de casos extremos. Podría imaginarme preprocesar esto en JSS JSON, pero para ser honesto, no veo mucho valor en usar el lenguaje CSS y mezclarlo con variables JS y llamadas a funciones en lugar de simplemente usar JS hasta el final.

Solo para mencionar, la compilación actual de componentes con estilo es 250kb, ya minificada . Para ser justos, eso se debe a que combinan React y compañía, pero aún así, incluso el analizador PostCSS solo tiene 13kb (sin minificar, podría ser 2kb ~) que ya es casi del tamaño de JSS o Fela.

Sin embargo, es encantador para la creación de prototipos rápida y simple de componentes (de presentación), pero no veo ningún beneficio / característica que otras soluciones no puedan proporcionar.

Estoy de acuerdo, lo probé en una biblioteca que desarrollo y era demasiado pesado para publicarlo. Estoy seguro de que progresarán con eso, pero parece que el trabajo de JSS aquí está casi completo y ofrece la mayoría de los mismos beneficios.

He usado react-toolbox últimamente, usan módulos CSS para tematizar que básicamente solo se basan en sassLoader del paquete web. Para mí funcionó muy bien. Quizás valga la pena investigar.

Oye, tengo que respaldar la opinión de soporte de react-toolbox es simplemente asombroso: estoy cambiando ya que personalizar el aspecto de los componentes es el aspecto más importante de la historia del frontend.

No creo que nadie deba esperar que el buen estilo CSS antiguo sea un ciudadano de primera clase en Material UI, esa es la razón por la que se inició react-toolbox

Al menos esa es mi impresión después de leer muchos números y publicaciones sobre este tema. Puedo recordar vagamente cosas como que el equipo se esfuerza por mejorar la compatibilidad de React Native y muchos comentarios sobre el diseño de casos extremos que son mucho más fáciles de resolver con JSS.

Sin embargo, esa información se pierde entre muchas discusiones. Debido a que este es un tema tan controvertido, creo que sería de un valor increíble si uno pudiera tener una página Wiki sobre los objetivos y la filosofía del proyecto (escrita por los mantenedores principales) con un comentario fuerte sobre por qué el estilo de Javascript está tan arraigado en el marco de referencia.

Realmente me gusta Material UI porque es el marco de estilo de material más activo y pulido para React. Sin embargo, el JSS me causa muchos dolores de cabeza cuando quiero mantener un estilo unificado con componentes de terceros.

En lo que a mí respecta, aprecio la forma en que Material-UI hace el estilo en lugar de algo como react-toolbox, y he aquí por qué: En uno de nuestros proyectos, tenemos la capacidad para que el usuario seleccione temas dinámicos:

Debido a que el usuario puede seleccionar un par de colores que no podemos determinar de antemano, cualquier esquema de temática que usemos debe ser muy dinámico. Con, los cambios en el tema pueden ocurrir en vivo, porque todos los estilos se generan en línea: todo lo que tengo que hacer es darle colores primarios / de acento.

En react-toolbox et. al., esto parece ser más una tarea por lo que puedo ver.

@jrop sí, en este caso muy especial necesitas JSS dinámico, pero para muchas aplicaciones eso no es un requisito importante y la historia actual de personalización (ni siquiera hablando de pruebas de UI) material-ui simplemente no es aceptable. Estamos creando una aplicación altamente visual y diseñada que no puede usar simplemente el aspecto de material-ui predeterminado, ya que en su mayoría necesitamos / queremos las partes de comportamiento.

@DominikGuzei puede personalizar next branch usando jss. Esto no es lo que ves en la versión actual.

Amigos, siento que estamos derrotando a un caballo muerto aquí. La rama next ha elegido una ruta diferente (muy mejorada) con temas y permite anulaciones. Ya no utiliza estilos en línea y proporciona la flexibilidad que he visto solicitada. Para otros que deseen más personalización, pueden usar un HOC sobre los componentes next y escribir sus propias hojas de estilo.

@nathanmarks , dado que esta decisión se ha tomado (por lo que puedo decir, y funciona bastante bien 👍), le sugiero que escriba un resumen y cierre / bloquee este problema para que aquellos que lo encuentren entiendan el camino a seguir.

si uno pudiera tener una página Wiki sobre los objetivos y la filosofía del proyecto (escrita por los mantenedores principales) con un comentario fuerte sobre por qué el estilo Javascript está tan arraigado en el marco.

@fgarcia Hice una presentación en un evento local en París a principios de esta semana sobre la evolución del enfoque de estilo utilizado por Material-UI. Quizás le interese echar un vistazo a las diapositivas y las _notas_: Un viaje hacia un mejor estilo . Me enfoco en los Retos, Problemas y Soluciones.

el usuario para seleccionar temas dinámicos

El aspecto de generación de estilo estático de los módulos CSS tiene algunas consecuencias.
Inyectar estilo en tiempo de ejecución es menos rentable, pero nos permite:

• Nos da más flexibilidad con la implementación del estilo. Por ejemplo, el CircularProgress tiene un thickness fijo vinculado a cómo se implementa la animación de fotogramas clave CSS. Con el estilo dinámico, podemos agregar una propiedad de grosor para que los usuarios puedan cambiar el valor de forma dinámica. ⚠️ no ser abusado.
• En una aplicación a gran escala, permite inyectar solo los estilos necesarios para el componente mostrado en la pantalla. Reducir la cantidad de trabajo que necesita el navegador para iniciar la página. Por lo tanto, un tiempo más rápido para pintar por primera vez después de la interacción. Por ejemplo, insertando CSS crítico con SSR.
• Permita que los usuarios usen temas dinámicos y variaciones de componentes. Por ejemplo, cambiar el color de un botón con todas las variaciones de color necesarias.

@oliviertassinari Eso es increíble de escuchar. Puede que tenga un punto de vista no estándar con respecto a los módulos CSS, pero no creo que valgan la pena tanto alboroto. Estaba emocionado de escuchar sobre JSS a través de material-ui por esta razón. Parece mucho más acorde con la filosofía de JavaScript que los módulos CSS.

@oliviertassinari gracias por el resumen de beneficios. Definitivamente es interesante cuando miras estos aspectos. La desventaja de JSS y su ecosistema (también postcss) en este momento es que todo eso es de vanguardia y no se puede confiar en la cadena de herramientas bien establecida y la base de conocimientos como con simples módulos css + SASS. Pero ese es el precio que paga por la innovación, solo depende de si tiene ciertos requisitos / está dispuesto a pagar el precio de los errores y la ruta menos documentada.

JSS se creó antes que css-modules. Los módulos CSS se han vuelto populares más rápido porque resolvieron un problema para la mayoría de los usuarios sin cambiar la sintaxis de manera demasiado radical.

Dicho esto, estás usando react, que también es una tecnología "nueva". Si quieres SASS, quizás también deberías elegir vanilajs o backbonejs)

@kof React es una historia muy diferente, ya que es utilizada por cientos de miles de desarrolladores y es administrada por Facebook (no desaparecerá de la noche a la mañana), por lo que puede ser "nueva" pero muy sólida muchos problemas con él hasta ahora).

SASS es uno de los preprocesadores CSS más establecidos y se puede utilizar en cualquier proyecto; es muy sólido y aporta mucho valor a la mesa. Por lo tanto, solo elegiría algo como JSS si fuera absolutamente necesario (por ejemplo, debido a temas dinámicos) pero no me gusta tirar años de experiencia / frameworks / base de conocimientos, etc. en un proyecto de software comercial con varios desarrolladores. Entonces, incluso consideraría construir solo el aspecto del tema dinámico en JSS y el resto con sass / css-modules.

Entiendo esta forma de pensar, pero también la considero contraproducente y la culpo de ralentizar la innovación y la industria.

¿Por qué no apoyas a ambos? ¿Estilos escritos en JavaScript Y estilos escritos en módulos css? Si echo un vistazo a https://github.com/callemall/material-ui/blob/next/src/Button/Button.js, por ejemplo, sería bastante fácil usar nombres de clase pasados ​​por un prop ( https://github.com/javivelasco/react-css-themr) en lugar de usar:

const classes = this.context.styleManager.render(styleSheet);

¿No es así?

No parece que la discusión sobre el uso de JSS o CSS esté llegando a su fin (¿todavía?). A mí me parece una cosa del cincuenta por ciento en este momento.

Con respecto a SASS, react-toolbox se está migrando actualmente

El estilo en todo JS, y en React en particular, obviamente todavía está en un rápido estado de evolución. Entonces, hagas lo que hagas, trataría de evitar ser obstinado, simplemente encajar bien con un amplio conjunto de usos actuales.

Considere simplemente agregar un accesorio * className siempre que haya un accesorio de estilo *. Período.

Revelación completa: soy un usuario feliz de Aphrodite.

Agregar un className aún requerirá !important hacks porque los estilos en línea (de style propiedad) tienen prioridad.

@ligaz Por supuesto, tienes razón. Afrodita agrega !important a todo de forma predeterminada, por lo que quizás mi pensamiento sobre un "amplio conjunto de usos" esté muy sesgado.

@ligaz @estaub - next ya está codificado _without_ style y permite que los usuarios de los componentes anulen proporcionando className (y varios nombres de clase para las diversas partes de componentes complejos) .

La configuración del paradigma de estilo en la rama next por parte de los mantenedores está usando JSS. Es un placer de usar y fácil de anular de forma individual o temática.

Este caballo está muerto. Dejemos de vencerlo. @oliviertassinari Te sugiero que cierres y next .

Hola @rosskevin : ¿puedes señalarme algún ejemplo de cómo está funcionando esto en el próximo?

Actualmente estoy buscando marcos para un nuevo proyecto, me encantaría usar Material UI pero necesitaríamos los cambios que mencionaste a continuación. Agregué la siguiente rama a un proyecto de prueba y agregué un componente simple y veo un inspector lleno de estilos en línea, así que supongo que estoy haciendo algo mal.

¡Cualquier otro detalle sería de gran ayuda!

Gracias

@giuseppepaul next no se publica en npm porque es pre-alfa y aún no está completo. Puede clonar https://github.com/callemall/material-ui.git#next y ejecutar docs/site para ver que no hay más estilos en línea. También tiene una cantidad razonable de demos.

Estoy publicando mi propia versión privada de next (para poder controlar las actualizaciones) y estoy usando esto en una aplicación de producción que pronto será.

Este caballo está muerto. Dejemos de vencerlo. @oliviertassinari Te sugiero que cierres y

Ese caballo no está completamente muerto. Pero definitivamente en un aprieto 🔫.
Estoy de acuerdo, cerremos este tema.

¡Muchas gracias a @nathanmarks por su arduo trabajo en esa historia 👏!
He reunido más información sobre el camino que tengo por delante con el número 5718.

Hola,
IconButton tienen una propiedad CSS3 transition para el efecto dominó. En la compleja interacción del documento de Card @next , ha agregado un transition a la transformación para agregar una transición cuando el ícono se invierte.
Si hago lo mismo en mi aplicación, una transición (rizado o reversión) anula la otra (un elemento no puede tener dos propiedades, de lo contrario, una anula a la otra).
Sin embargo, su icono de chevron tiene dos transitions aplicados correctamente. Porque de alguna manera fusiona las transiciones proporcionadas por IconButton y la definida en su código. Cómo logras eso ?
Algunas otras cosas son oscuras para mí y no puedo encontrar documentos relacionados. theme tiene muchos métodos / propiedades como breakpoints (no se usa aquí) transitions (se usa aquí). ¿Ya existe un documento sobre la propiedad theme de lo que MuiThemeProvider.createDefaultContext() devuelve, ya que parece útil, especialmente porque se usa ampliamente dentro de su código?
this.context.styleManager.render(styleSheet) ? Qué ?
También usa jss-theme-reactor que todavía no entiendo el punto en comparación con react-jss .

@NitroBAY Este hilo ha terminado. Haga su pregunta en el canal correcto. Si nota un error o desea que se mejore la documentación, abra un problema. De lo contrario, puede usar StackOverflow de gitter.im.