Material-ui: Soporte Reaccionar Nativo

Acabo de descubrir este repositorio: https://github.com/lightningtgc/react-native-material-ui
Aunque no sé si es bueno.

Gracias @chadobado - Hemos hablado de eso con seguridad y sería un proyecto divertido para comenzar. Sin embargo, tenemos las manos llenas con este proyecto en este momento. Mantendré este problema abierto y lo actualizaré si alguna vez creamos una biblioteca nativa.

Esto es realmente una gran idea. He intentado probar la transferencia de material-ui a React-Native. Solo necesitamos hojas de estilo un poco, cambiar todo div a View , cambiar todo h1 , h2 , etc. a Text y funcionará muy bien. El único problema que encontré es que React Native no es totalmente compatible con boxShadow por lo que es difícil implementar el componente Paper en este momento. Además, sería genial si pudiéramos crear un script para transferir automáticamente el código a React-Native, ya que no es muy diferente.

cambie todo div a Ver, cambie todo h1, h2, etc. a Texto y funcionará muy bien

¿No podríamos usar un babel-plugin-transformer para hacerlo?

Esta es realmente una gran idea.

¿Tienes un proyecto de demostración?

@oliviertassinari

¿No podríamos usar un babel-plugin-transformer para hacerlo?

No estoy seguro, ya que la hoja de estilo de React Native es bastante diferente de CSS, por lo que será bastante complicado hacer el transformador.

¿Tienes un proyecto de demostración?

Todavía no porque estoy bastante ocupado, pero intentaré mostrarles una pequeña demostración pronto.
Pero esto es lo que tenemos que hacer

hojas de estilo

let styles = {
      root: {
        zIndex: 5,
        width: '100%',
        display: '-webkit-box; display: -webkit-flex; display: flex',
        minHeight: themeVariables.height,
        backgroundColor: themeVariables.color,
        paddingLeft: spacing.desktopGutter,
        paddingRight: spacing.desktopGutter,
      }
}

a

let styles = StyleSheet.create({
      root: {
        // zIndex: 5, (not supported)
        //width: '100%', (number only)
        //display: '-webkit-box; display: -webkit-flex; display: flex', (React Native always use Flex)
        minHeight: themeVariables.height,
        backgroundColor: themeVariables.color,
        paddingLeft: spacing.desktopGutter,
        paddingRight: spacing.desktopGutter,
      }
})

solución de índice z

JSX

<div {...other} style={this.prepareStyles(styles, style)}>
  <h1 style={styles.text}>Hello world</h1>
</div>

a

<View {...other} style={this.prepareStyles(styles, style)}>
  <Text style={styles.text}>Hello world</Text>
</View>

También necesitamos modificar styles/transition.jsx (React Native usa object lugar de string ), mixins/style-propable.jsx ya que no necesitamos lidiar con múltiples navegadores, etc.

Acabo de publicar una bifurcación WIP para reaccionar nativo en https://github.com/lenaten/material-ui-native.
Actualmente solo funciona Card y RaiseButton, pero sin estilo (WIP, ¿recuerdas?)

@lenaten ¡Interesante!
También quería comenzar a trabajar en un envoltorio entre este proyecto y mrn (https://github.com/oliviertassinari/react-material).
Parece que su bifurcación solo funciona con react-native, ¿cómo haría que funcione también con el navegador?
Creo que es el punto más difícil y debería abordarse ahora, ya que dices que tienes dos componentes de trabajo. Puedo ayudarte si quieres.
Como dije antes, también quería investigar https://github.com/binggg/mrn para nuestra implementación nativa.

Cuando se responda, creo que podríamos fusionar su bifurcación aquí.

Material-UI es un proyecto maduro contra un proyecto mrn que pierde muchos componentes materiales. Si mi POC funciona como excepción, fusionarlo con la estructura de archivos multiplataforma debería ser fácil. No tengo tiempo para reinventar la rueda y empezar de cero el proyecto.

De todos modos, su ayuda en pensamientos y código es muy bienvenida.

@oliviertassinari Yo también.

Mi idea para hacer que material-ui funcione tanto con el navegador como con el nativo es usar una estructura de nombre de archivo, similar a la forma en que react-active maneja iOS y Android al mismo tiempo.

app-bar.native.jsx
app-bar.browser.jsx
common.jsx

o aún podemos usar los mismos componentes tanto para el navegador como para el nativo y luego escribir un contenedor para manejarlos. Por ejemplo, react-native usa View , el navegador usa div luego lo hace así:

div.navegador.jsx

export class ... {
  render() {
    return </div>
  }
}

div.nativo.jsx

export class ... {
  render() {
    return </View>
  }
}

app-bar.jsx

import {div} from "div"

De hecho, podemos crear un proyecto separado para este contenedor.

@ quanglam2807 Me alegra escucharlo.

Con respecto a la organización del código, me gusta la idea de tener extensiones de archivo separadas.
Tomaría el ejemplo https://github.com/benoitvallon/react-native-nw-react-calculator/tree/master/src/common/components como la forma de hacerlo.

En cuanto a la organización del proyecto, puede que haya cambiado de opinión.
Creo que es mejor seguir el enfoque de Google y trabajar en un gran repositorio único. Por lo tanto, trabajar en una sincronización de bifurcación con material-ui o aquí podría ser una buena manera de hacerlo.

Para comenzar con nuestros archivos .native , podemos depender de

• https://github.com/binggg/mrn
• o https://github.com/xinthink/react-native-material-kit

componentes

@oliviertassinari También me encanta la idea del modelo de "extensión de archivo". Lo más importante para mí ahora es trabajar con componentes nativos. Si desea ayudar con la abstracción de código, bienvenido. Me comprometo a eliminar el sufijo "nativo" del nombre del repositorio :)

@lenaten es compatible con material-ui-native con tcomb-form-native, o si no, ¿qué tan grande sería ese proyecto?

@mvayngrib Me detuve a trabajar en este proyecto por un tiempo...

@lenaten que pena, gracias por responder

Muy bien, comencé a trabajar en este https://github.com/callemall/material-ui/pull/2611.
¡Eso va a tomar algún tiempo!

@oliviertassinari increíble! muy muy emocionado

Entonces, ¿el esfuerzo portuario sigue abierto? Si es así, ¿cuál fue el proceso establecido para implementar los componentes?

@dorthwein Todavía está abierto.

Desde mi punto de vista, el proceso es el siguiente:

• [ ] Actualice a la última versión de react-native y elimine react-native-webpack-server . Ya lo he hecho en este proyecto . https://github.com/callemall/material-ui/pull/3829
• [ ] Juega con react-look y mira qué tan bien podemos usarlo para el muiTheme que proviene del contexto. https://github.com/callemall/material-ui/pull/3829
• [x] Espere en la reorganización de la
• [ ] Comience a trabajar en la aplicación de documentación que usaremos para mostrar el nuevo componente.
• [ ] Empezar a trabajar en la versión nativa de los componentes.

@oliviertassinari : puedo contribuir con un poco de tiempo en la transferencia de algunos de los componentes una vez que se establezca el camino a seguir. Al mirar su lista, lo único desconocido en este momento es el aspecto de reacción, ¿verdad?

@dorthwein estamos felices de escucharlo.
Estoy usando reaccionar-mirar aquí #3829. El único problema que tengo es menor. React Native muestra una advertencia sobre el uso incorrecto de la API StyleSheet . No lo he mirado en detalle pero creo que se puede solucionar.

@oliviertassinari @dorthwein Estoy feliz de que este esfuerzo (es decir, llevar material-ui a react-native ) no esté muerto. Solo quería señalar que también hay otro proyecto nuevo de material-ui a react-native que no se ha mencionado en este hilo: https://github.com/react-native-material- diseño/reaccionar-nativo-material-diseño . Ese proyecto parece estar basado en https://github.com/binggg/mrn.

@oliviertassinari Vi en otro hilo si la compatibilidad con iOS tenía sentido para este puerto; creo que sí, especialmente cuando observa cómo Google Maps y otras aplicaciones de Google Material + iOS están disponibles. Cuando tenga sentido y haya un fuerte componente preexistente de iOS (p. ej., interruptores), debe usarse para encender iOS. La implementación de Android e iOS tampoco es una gran carga.

@oliviertassinari La estructura de archivos component.native.js, component.android.js, component.ios.js también parece tener más sentido para mí.

@oliviertassinari Traté de poner en marcha los documentos sin suerte. Algunos problemas:

• package.json: a react-native no le gusta el nombre del paquete material-ui; cambiar a materialUI resolvió el problema
• La rama material-ui/react-native actual tiene un problema con el empaquetador react-native y no crea el archivo mainjs.bundle. No he sido capaz de averiguar lo que estaba pasando aquí.
• Parece que no puedo obtener una aplicación nativa de reacción que funcione además del repositorio material-ui existente. Si alguien ha tenido suerte en este frente, obtengamos una descripción estable de cómo contribuir/desarrollar un conjunto de componentes nativos.

@dorthwein Gracias por los comentarios. La rama react-native es altamente experimental. Necesitamos resolver esto.
Por otro lado, no tengo ningún problema de mi parte (https://github.com/callemall/material-ui/pull/3829).
Debería intentar comenzar desde un git clone .

Sí, la próxima etapa de mi proyecto actual es trabajar en una aplicación móvil usando Material Design. Me gustaría usar esto, ya que todo nuestro material web también está en esto. Si podemos lograr un ambiente de trabajo, comenzaré a eliminarlo junto con nuestro proyecto.

Estaba leyendo sobre algunas cosas y noté este dato de la página nativa de FB React.

"El componente más fundamental para crear una interfaz de usuario, View es un contenedor que admite el diseño con Flexbox, estilo, algunos controles táctiles y controles de accesibilidad, y está diseñado para anidarse dentro de otras vistas y tener de 0 a muchos elementos secundarios de cualquier tipo. View se asigna directamente a la vista nativa equivalente en cualquier plataforma en la que se esté ejecutando React, ya sea una UIView,

También encontré este recurso, pruébalo ahora. Parece bastante sencillo y tal vez valga la pena echarle un vistazo

https://github.com/necolas/react-native-web

@dorthwein ¡ Gran idea! Pero si seguimos este camino, creo que sería mejor desarrollar una versión solo para React Native.

Podemos reescribir todo el proyecto bajo las API React Native en lugar de códigos separados para Native y DOM. ¡Increíble! Nunca he pensado en esto.

@quanglam2807 sí, de esa manera, nuevas funciones, etc. Manténganse en línea entre sí. Creo que el mayor desafío es que los estilos y las animaciones funcionen. Otra gran ventaja es que podemos agregar gradualmente soporte para diferentes componentes.

El lado negativo es que todo necesitará usar cajas flexibles.

Dado que se trata de una refactorización importante de la base de código, ¿quién debe firmar esto para seguir adelante? Todavía necesito jugar y ver qué tan robusto es también el material de react-native-web.

@quanglam2807 @oliviertassinari otra ventaja con este enfoque es que material-ui también se transferirá fácilmente a https://github.com/ptmt/react-native-desktop .

@oliviertassinari está usando react-native-web, ¿algo que los mantenedores de este proyecto pueden respaldar si funciona como se esperaba?

@dorthwein Me encanta la idea detrás de este proyecto. Pero no creo que ayude en un futuro próximo.
¿No necesitamos primero escribir una versión nativa de nuestros componentes antes de poder usar react-native-web ?

@oliviertassinari no, lo que hace react-native-web es usar el componente más "nativo" según la plataforma. Entonces, por ejemplo, dada una etiqueta View, usaría un div en el navegador, un UIView en iOS y el equivalente a UIView en Android.

Entonces, el proceso sería, en lugar de escribir versiones nativas de cada componente, que solo tendríamos que convertir las existentes para usar View en lugar de div y estilo Text en lugar de usar cosas como h1 y label.

Definitivamente no es una tarea pequeña, pero el proceso sería actualizar los componentes existentes en lugar de intentar crear y mantener múltiples versiones.

Entonces, el proceso sería, en lugar de escribir versiones nativas de cada componente, que solo tendríamos que convertir las existentes para usar View en lugar de div y estilo Text en lugar de usar cosas como h1 y label.

Eso suena exactamente como escribir una versión nativa que, con suerte, también funcione en el navegador. Por lo que sé, react-native-web trae una reacción nativa a la web y no al revés.
Aún así, eso puede ser muy útil para compartir el mismo código :+1:.
He visto un pequeño problema con esta biblioteca hasta ahora. Su implementación StyleSheet.create no admite valores dinámicos (necesarios para muiTheme). Podríamos usar react look para este caso de uso.

@oliviertassinari tienes razón, lo estaba entendiendo al revés. Parece que el paso 1 todavía está construyendo versiones nativas de reacción de los componentes. El paso 2 sería potencialmente fusionarlos en una sola base de código usando algo como la web nativa de reacción.

@wordyallen : se ve bien 👍

@pgangwani Acabo de empezar a jugar con él... Aún no está listo.

He estado usando https://github.com/react-native-material-design/react-native-material-design para llenar el vacío, pero también es muy tosco y no tiene un desarrollo activo.

Donaría financieramente a este esfuerzo, si pudiera.

Hola tios,

Trabajo en react-native-material-ui , que está inspirado en esta biblioteca. Siéntase libre de probar - Me gustaría escuchar sus comentarios ;)

@xotahal et. Al, en lugar de crear desde cero, en mi humilde opinión, lo que deberíamos estar haciendo es bifurcar esta biblioteca y portar los componentes existentes en lugar de recrearlos. La necesidad de las entradas de estilo material es muy necesaria en el espacio de RN, si me preguntas. Gracias a todos por sus esfuerzos de OSS.

No creo que haya mucho código común, creo que crear desde cero tiene sentido. El estilo en RN será un 90% diferente a este. Y hay bastantes mecánicas específicas de la plataforma, como animaciones...

Parece que adoptar la estructura de componentes, accesorios (y documentos) y tener un upstream claro, incluso si cambian muchas cosas, sería beneficioso a largo plazo para aquellos que cambian de web a nativo y es de suma importancia. El resto se convierte en un detalle de implementación.

Estoy de acuerdo con @jhabdas ; cuanto más similares puedan verse las API para cada componente, menos molesto será para los desarrolladores cambiar de proyectos web y proyectos nativos. Cuanto menos discordante sea la experiencia, más productivas pueden ser. Espero que los detalles específicos de la plataforma se abstraigan detrás de escena del componente.

@chadobado o mantenedor, ¿podría cambiar el nombre de este problema a "Support React Native" para aumentar la visibilidad al buscar en este repositorio? La búsqueda actual de "React Native" entierra esto en la lista porque el término está separado con guión en el título.

FWIW, esto me llamó la atención.

@necolas en soporte web para react-native-material-kit :

Es poco probable que necesite portar mucho si la implementación web de React Native proporciona alguna hoja de estilo como compatibilidad.

@jhabdas si juegas un poco con reaccionar nativo verás que no es tan sencillo. La API StyleSheet es increíble, pero tienes que volver a escribir algunas cosas;)

Punto justo @antoinerousseau. Sigo pensando en una cita de James Long en RN:

Piense en ello como un prototipo para una dirección diferente para la web.

Si entiendo el propósito de la biblioteca @necolas está funcionando, parece que un enfoque sensato sería React Native Material Kit ya tiene un buen salto sobre el problema.

Dado que react-native-web parece increíble, solo voy a crear archivos material-ui.android.js , material-ios.ios.js y material-ui.web.js en mi propio proyecto personal y llamarlo bueno. Si sigo la API de material-ui envuelvo todo lo demás, eventualmente funcionará. Si material-ui me sorprende y funciona, solo tendré que eliminar los .web de los .web.js y eliminar los demás archivos. De esta forma, puedo hacer una transición selectiva a material-ui por componente.

@oliviertassinari Así que agregué la rama react-native como una dependencia de NPM e instalé todos los complementos de Babel. Recibí este mensaje al importar cualquier componente:

EventPluginRegistry: Cannot inject event plugin ordering more than once. You are likely trying to load more than one copy of React.

Mi objetivo es usar material-ui lo antes posible por componente. De acuerdo, hice un git rebase master y debería haber hecho un git rebase next todo caso. ¿Todos los componentes individuales de react-native bloqueados por la preparación del trabajo de la sucursal de next este momento?

Y escribí un código que me permite consumir react-native-vector-icons exactamente de la misma manera que consumo material-ui íconos:

// <strong i="19">@flow</strong>

import React from 'react'
import {
  Text,
  View
} from 'react-native'
import Mui from './app/material-ui'
import Icons from './app/material-ui/icons'

export default React.createClass({
  render: function() {
    return (<View>
      <Icons.AccountCircle />
      <Mui.IconAccountCircle />
    </View>)
  }
})

Aunque por el momento react-native-vector-icons y material-ui tienen una sintaxis de importación incompatible. @oblador Tuve que importar glyphMap e iterarlo y exportar la lista completa como un objeto grande.

import { glyphMap } from 'react-native-vector-icons/MaterialIcons'

Sería bueno si react-native-vector-icons Los iconos de materiales se agruparan por categoría como material-ui permitiría exportaciones individuales desde dentro de una categoría:

import ActionHome from 'material-ui/svg-icons/action/home'

¿Deberíamos trabajar en una solicitud de incorporación de cambios para que react-native-vector-icons compatible con las convenciones de importación de material-ui ?

@mattferrin La react-native es bastante antigua ahora. No está destinado a ser consumido por los usuarios. Fue una prueba de concepto sobre el camino a seguir.
Por lo que he analizado este problema, uno de los enfoques prometedores sería reescribirlo para apuntar a react-native . Entonces react-native-web haría la parte difícil por nosotros.
Sin embargo, existen algunos desafíos:

• ¿Cuánto _react-native-web_ está listo para la producción? Por ejemplo, no he visto pruebas visuales.
• ¿Cómo manejas las consultas de los medios?
• ¿Cómo maneja una solución de tematización compleja?

También vale la pena mirar reaccionar con estilos .

¿Qué cantidad de react-native-web está lista para la producción?

@oliviertassinari Actualmente estoy react-native-web y siento que vale la pena aceptarlo. Le falta un componente href de etiqueta de anclaje multiplataforma y es posible que le falten otras sutilezas, pero el ReactDOM subyacente está listo para la producción y eso es lo que necesitamos.

¿Cómo manejas las consultas de los medios?

¿Debería importarle a material-ui ? Hay formas de encontrar las dimensiones de un componente o una pantalla en todas las plataformas. Siempre que los componentes de material-ui se puedan pasar accesorios que controlan el estilo, lo que hacen, creo que somos oro.

¿ material-ui realiza consultas de medios? ¿Necesitamos hacerlo?

¿Cómo maneja una solución de tematización compleja?

¿No podemos simplemente verificar Plataforma para omitir o cambiar el nombre de los accesorios no compatibles de React Native, ya que (si la memoria no me falla) el relleno y el margen están esencialmente invertidos en React Native. Todo lo que tendríamos que hacer es envolver el método equivalente createStyleSheet para transformar/filtrar el resultado en estilos compatibles que no sean específicos de la plataforma "web".

Todavía no lo he usado, pero Fela pretende ser multiplataforma, y ​​creo que eso es importante. Dado que el autor de Fela escribió React Look y dado que parece haber sido una elección previa, se siente como una elección natural.

Tampoco lo he usado, pero algo como react-tunnel parece bueno para el contexto temático. Podríamos simplemente usarlo y exponerlo, nuevamente solo porque se siente más compartible con la comunidad. Podría haber un equivalente más popular.

¿Qué cantidad de react-native-web está lista para la producción? Por ejemplo, no he visto pruebas visuales.

Hay ejemplos interactivos aquí: https://necolas.github.io/react-native-web/storybook/

¿Cómo manejas las consultas de los medios?

En JavaScript, usando matchMedia (o usando Dimension ) para determinar qué estilos y componentes representar.

Falta un componente href de etiqueta de anclaje multiplataforma

Sí, no estoy seguro de cuál debería ser una solución "adecuada", pero puede usar View y Text como enlaces por ahora (solo soporte web, por supuesto):

<Text accessibilityRole='link' href={href}>{text}</Text>

¿Cómo maneja una solución de tematización compleja?

A React Native no le importa cómo haces esto. Todavía puede usar context para determinar qué objetos de estilo aplicar. Me gusta bastante la API de Fela dentro de los componentes, pero la implementación y la API del complemento parecen exageradas si tuviera que usar react-native-web .

Todo lo que tendríamos que hacer es envolver el método equivalente createStyleSheet para transformar/filtrar el resultado en estilos compatibles que no sean específicos de la plataforma "web".

¿El problema es que expone una API de estilo que no es compatible con RN? Si es así, le sugiero que exponga una API de estilo compatible con RN y deje que react-native-web convierta a estilos DOM.

@necolas

¿El problema es que expone una API de estilo que no es compatible con RN? Si es así, le sugiero que exponga una API de estilo compatible con RN y deje que react-native-web la convierta a estilos DOM.

Buen punto. ¿Tiene react-native-web un sentido de :hover por ejemplo?

@necolas Y el trabajo particular que estoy haciendo solo necesita ser compatible con los navegadores perennes, pero ¿existe la posibilidad de que la migración a react-native-web costaría material-ui compatibilidad del navegador con versiones anteriores? No sé nada de eso realmente. Realmente creo que react-native-web es el enfoque correcto.

No proporciona nada especial para estilos flotantes (tampoco RN). Me pregunto si las implementaciones de escritorio para Windows y Ubuntu incluyen algo para las interfaces de mouse o se lo dejan a usted a través de eventos.

No estoy seguro de qué soporte de navegador necesita, pero puede adaptarse cuando surjan problemas

Creo que podría ser necesario inyectar un booleano en el contexto de la jerarquía de componentes a través de MuiThemeProvider para elegir entre una API de estilo de componente react-native-web versus una API de estilo de componente react-dom .

La mejor respuesta es simplemente cambiar a la API de estilo react-native-web , y eso es lo que recomendaría, pero eso probablemente causaría un malestar.

@oliviertassinari ¿Podríamos material-ui a una API de estilo react-native ? ¿Tal vez permitir que se filtren estilos específicos del mouse?

@necolas @oliviertassinari Solo como información. Es descuidado en este momento, pero he estado trabajando en la migración de una rama (https://github.com/mattferrin/material-ui-build/tree/mine) para que sea multiplataforma durante los últimos 2-3 días porque realmente lo necesito (para reducir mi trabajo total a largo plazo).

He estado transfiriendo todo a la sintaxis de react-native-web y comentando estilos que no se adaptan, pero creo que terminaré comentándolos nuevamente y usando Platform.OS == 'web' para retener el código original esencialmente sin cambios una vez que termine de portar el sitio web en el que estoy trabajando. En ese momento, solo las cosas que personalmente necesito serán portadas y de manera imperfecta.

Es un desastre total (hasta que lo retoque más adelante) porque presiono para saltar entre las máquinas Mac y Windows sobre la marcha.

Para aquellos que no pueden esperar a que MUI llegue a RN, hay alternativas, y algunas muy bonitas. Mantengo una lista perenne aquí: https://habd.as/awesome-react-components/#react -native

Sabía que toda la solución de estilo estaba cambiando, pero me perdí la parte en la que la biblioteca se reescribía desde cero. eso es mi culpa Supuse, al mirar algún código, que los estilos finales permanecerían esencialmente iguales y que solo cambiaría la tecnología. estaba equivocado No ignoré por completo la hoja de ruta, solo hice suposiciones que están muy equivocadas. Supongo que tendré que abandonar mi intento aquí.

@mattferrin No del todo desde cero (aunque en algunos casos eso es cierto, por ejemplo Table ) aunque el cambio de solución de estilo requiere muchos cambios de API, pero además nos da la oportunidad de racionalizar la API en otras áreas para muchos componentes . Lo siento si sus esfuerzos fueron en vano. ¡Espero que no lo desanime Material-UI!

@mbrookes No lo ha hecho. Cometí el error de bifurcar master lugar de next y subestimar la diferencia (y el trabajo total en general). Fue mi culpa y sabía que había riesgo. Simplemente devolveré elementos Text vacíos como marcadores de posición hasta más adelante en mi fachada React Native material-ui . Cuando haya portado completamente mi sitio web a react-native-web , regresaré e intentaré reorganizar los nuevos cambios en next .

Liberando a este tipo hoy: https://carbon-ui.com

Inspirado en material-ui, funciona en la web y en react-native :)

@tuckerconnelly me

@tuckerconnelly guau, mucho potencial en este proyecto... ¡bien hecho! ¡Aquí está la esperanza de que la comunidad en general se una detrás de este esfuerzo! 🍻

@tuckerconnelly Estoy un poco confundido. Descubrí que en realidad es bastante fácil hacer material-ui condicionalmente multiplataforma (a pesar de mi error de ramificar master lugar de next y perder mi tiempo). Tengo curiosidad, ¿qué beneficios le ves a un proyecto independiente?

Lo probé en febrero y tuve dificultades, en particular con el componente de ondulación y con las consultas de medios multiplataforma.

A veces es más fácil empezar de cero.

para mí no tiene sentido tener componentes React que no funcionan en React Native... y dado que los desarrolladores de material-ui no consideraron RN una prioridad... es justo/lógico comenzar un nuevo camino

@tuckerconnelly No creo que importe cómo se implementan los componentes. Solo espero que ambos proyectos intenten implementar la misma API (y acuerden los mismos nombres) para sus componentes. Me alegro de que hayas trabajado en esto y lo hayas compartido.

Entonces, para 2017/2018 después de la v1.0.0, ¿será RN el próximo objetivo para material-ui?

Como visto de:

• La participación de la comunidad a v1
• El número de personas que quieren apoyo de RN
• El hecho de que muchos proyectos se hayan basado o inspirado en Material-ui para ofrecer componentes RN
• La experiencia de todo esto y el hecho de que ha pasado mucho tiempo desde que se abrió este número

Si comenzara (probablemente después del lanzamiento de v1) un proyecto para ofrecer componentes RN, mucha gente lo ayudaría. Solo necesitaría comenzar y definir un camino claro y estaría listo. Tienes una gran comunidad, usémosla para hacer el mejor producto posible.

@NitroBAY 1.0 usa JSS en lugar de objetos JS para diseñar, por lo que se basa en cssinjs/jss#368 para admitir React Native. Pero creo que es mejor desarrollar una versión paralela para React Native como esta: https://github.com/xotahal/react-native-material-ui. Entonces podemos ejecutar la versión de React Native en la web usando https://github.com/necolas/react-native-web

Entonces, ¿es esto una solución habitual? Si es así, ¿puede ser etiquetado como tal?

@jhabdas Me encantaría ver una buena biblioteca que traiga la especificación del material a React Native.
De los enlaces publicados en el hilo, ya hay una buena lista de candidatos.

Si mantenemos ese tema abierto, se trata de unificar la web y lo nativo. Proporcionar una API consistente entre las dos plataformas. Desearía tener tiempo para trabajar en eso, pero no lo tengo y dudo que vaya a cambiar.
Al equipo de @callemall/material-ui le encantaría ver a alguien que tome la iniciativa en ese tema.

Todavía soy compatible con carbon-ui :) Solo agrego componentes cuando los necesito (sin tratar de completar todas las especificaciones de manera proactiva), pero creo que hay un buen marco para que la gente se reúna.

• Genera automáticamente documentos a partir de los comentarios de los componentes.
• Tiene un sitio de documentos (carbon-ui.com)
• Soporta nativo y web con los mismos componentes

Ayudaría a cualquiera que quiera agregar componentes :)

@tuckerconnelly ¿Qué opinas sobre https://github.com/xotahal/react-native-material-ui? No funciona en la web debido a un error con Elevation, pero si aplicamos su código https://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.js , creo que trabajaría. @oliviertassinari destaca que debemos decidir un proyecto principal para trabajar juntos.

@quangbuule espera, ¿dices que deberíamos desarrollar aplicaciones como aplicaciones RN y luego usar esa herramienta para transformar RN en una versión WEB?
Nunca había oído hablar de esa cosa, pero bueno. ¿Pero entonces significa que ya no usaríamos material-ui sino más bien una bifurcación RN?

@NitroBAY Básicamente,

Lo siento por todas las preguntas de novato, pero aterricé en ReactLand desde aproximadamente 1 semana.

¿Crees que tu paquete va a reemplazar a este?
Su enfoque parece ser multiplataforma y muy bueno. Material-ui se apega solo a la web porque no tienen tiempo pero tienen tiempo para el siguiente, ¿por qué?
Usted dice que next use un enfoque isomorfo en next pero si tomo cualquier componente, es decir, papel , funcionará solo para la web, ya que hay un componente div .
¿Quiénes son we , eres parte de este equipo?
Independientemente de las consideraciones técnicas, ¿no cree que usar MD en IOS puede molestar a los usuarios?

EDITAR: fuera de tema, pero nadie me respondió, ¿qué ventajas trae jss-theme-reactor cuando se trata de compararlo con jss-react ?

@NitroBAY :

1. No soy el desarrollador de este proyecto ni de ningún proyecto de React Native. Pero he visto este problema durante meses y, en este momento, estoy ansioso por comenzar a contribuir con react-native-material-ui .
2. paper o la cosita de la sombra ahora funciona en la web, iOS, Android. Así que no es gran cosa.
3. material-ui rama master usa objetos para definir las hojas de estilo, pero para mejorar el rendimiento (aumento del 30 %), los colaboradores cambian a JSS (CSS en JS) en la rama next . Por el momento, JSS no es compatible con React Native.
4. Google usa Material Design en iOS y no creo que a los usuarios les importe mucho. Por supuesto, debe modificar algunas partes para que encajen en la plataforma, como cambiar el color de la barra de estado, usar el icono para compartir de iOS, etc. Usé material-ui para mi aplicación de Windows 10 y macOS y no vi muchas los usuarios se quejaron (http://moderntranslator.com/). Algunos incluso dijeron que MD era más fácil de usar.

Pero todavía no entiendo de qué manera la rama next puede funcionar en RN si los componentes usan elementos HTML como span o div . Es posible que me haya perdido algo, pero para desarrollar en RN necesita usar componentes RN, ¿no es así?
Te estoy citando:

se convertirá en la versión oficial tanto para web como nativa. Creo que está bien considerando que material-ui está usando un enfoque similar con la siguiente rama.

Pero puede que no lo haya entendido correctamente. ¿Quiere decir que la rama next nos permitirá usar componentes en RN?

@NitroBAY : la next hará que material-ui menos compatible con React Native. Además, aunque el componente RN no es compatible con span o div, al usar reglas condicionales, puede hacer algo como esto:

if (platform === 'web') return <span/>;
else return <View />;

Puede consultar: https://github.com/necolas/react-native-web

Oh, está bien, pensé que querías decir que hicieron RN compatible.

¿Es el TL; DR que este proyecto no tiene interés en el soporte multiplataforma a través de React Native API, y ese esfuerzo debería trasladarse a https://github.com/xotahal/react-native-material-ui?

Los documentos para carbon-ui son mejores y ya funcionan en la web. ¿Cuál es el beneficio de react-native-material-ui?

Entonces, ¿todos están de acuerdo en que material-ui se dejará de usar y recomendará en un tiempo? Entonces, ¿es una pena que los propietarios de este paquete no quieran RN?

carbon-ui parece que tendrá problemas de rendimiento por no usar StyleSheet y por inyectar tantas fuentes web

¡Cálmense, muchachos! Todavía viene.

TL; DR: si crea un componente para React Native, funcionará en RN y web. Pero si crea un componente para la web, no funcionará en RN. Y material-ui está diseñado para web, optimizado para web => Para que funcione en RN, se debe sacrificar el rendimiento (al menos, por el momento). Por lo tanto, creo que es mejor mantener los dos proyectos separados hasta que RN esté más maduro.

optimizado para web => Para que funcione en RN, se debe sacrificar el rendimiento (al menos, por el momento)

¿Tienes algún dato para compartir al respecto?

Aquí están mis hallazgos para RNW hasta ahora:

• https://github.com/necolas/react-native-web/blob/89ad493ce5ef3b37998af397156903ade1ada34b/performance/README.md
• https://github.com/necolas/react-native-web/pull/343#issuecomment-279177085

@necolas #4066

Hmm, puedo considerar el uso de StyleSheet con Uranium. Diré que no he notado ningún problema de rendimiento relacionado con CSS, pero veré si puedo integrarme mejor con sus cosas de StyleSheet.

El mayor impacto en el rendimiento proviene de Animated: https://github.com/animatedjs/animated/issues/48 Pero eso afecta a todas las aplicaciones RNW.

¿La inyección de fuentes web disminuye significativamente el rendimiento? Los carga directamente desde las fuentes de Google, por lo que es probable que ya estén almacenados en caché en el sistema del usuario.

Creo que lo más importante es que todos se unan detrás de una sola biblioteca. Y no creo que material-ui sea compatible con React Native.

@necolas El TL; DR es que el camino a seguir no está claro .

A = reaccionar nativo
B = la web

1. La plataforma más restringida

Un enfoque posible es apuntar a la plataforma más restringida, por lo tanto, comenzando desde react-native . Luego, para extender las características a la web. Para extender las funciones a la web, podríamos estar usando:

• https://github.com/necolas/react-native-web
• https://github.com/taobaofed/react-web

Sin embargo, eso viene con una compensación, ganaríamos el código compartido. Pero espero perder en algunas dimensiones.

Llevando la API nativa a la web

La API debe volver a implementarse para que funcione con el navegador. ¿Cuál es la sobrecarga?

Manejo de la API web faltante en nativo

Como comenzamos desde la plataforma más restringida, necesitaríamos volver a implementar alguna función disponible en la web. ¿Qué pasa con las consultas de los medios? ¿Herencia CSS, animaciones CSS?
¿A quién implementaríamos eventos de accesibilidad y teclado sin inflar la versión nativa?

2. La plataforma menos restringida

Otra solución es comenzar desde la plataforma menos restringida, por lo tanto, la web. Luego, crear y volver a implementar las características nativas que faltan.

Sin embargo, eso viene con una compensación, ganaríamos el código compartido. Pero espero perder en algunas dimensiones.

Llevando la API web a lo nativo

Tendremos que hacer sacrificios, espero que alguna característica web sea realmente difícil de implementar en nativo, por ejemplo, las consultas de medios CSS, las animaciones CSS. (reglas CSS avanzadas)

Manejo de la API nativa faltante en la web

Algunas de las características de la API web que faltan son el manejo táctil, el desplazamiento y la vista de lista infinita, componentes nativos como DatePicker o Drawer.

3. Contrato compartido

Una tercera solución podría ser configurar una infraestructura para compartir API y pruebas y luego volver a implementar los componentes en las dos plataformas subyacentes. Desde mi percepción, es cómo reacciona-native se está acercando a iOS y Android.
Luego, utilizando un enfoque mixto de los dos anteriores para completar el contrato. Quiero decir, usar la bifurcación de código cuando tenga sentido y compartir el código tanto como podamos.
Por ejemplo:

• ¿Por qué usar animation.js en el navegador cuando podemos usar transiciones CSS?
• ¿Por qué implementar la lógica Drawer en react-native cuando podemos usar el componente nativo?

Creo que la opción 3 es la más prometedora. Así es como he tratado de resolver el problema en react-swipeable-views .

https://github.com/tuckerconnelly/uranium admite consultas de medios multiplataforma :)

La belleza de RN es que tiene una biblioteca simple de API y primitivas abstractas, y se cuidan las implementaciones de bajo nivel. Animado es lo mismo: biblioteca simple para animaciones, implementaciones de bajo nivel (animaciones nativas en iOS/Android, transiciones css en la web) son atendidas.

Creo que animation.js podría modificarse para usar transiciones css. Seguro que mejoraría el rendimiento.

@ quanglam2807 ese hilo es muy largo, ¿qué debo mirar?

Para extender las funciones a la web, podríamos usar: https://github.com/necolas/react-native-web , https://github.com/taobaofed/react-web

react-web está bastante lejos de ser funcional o funcionalmente correcto en mi opinión.

La API debe volver a implementarse para que funcione con el navegador. ¿Cuál es la sobrecarga?

Sobrecarga en que dimensiones? Difícil de determinar en términos del tamaño del paquete. Probablemente podría eliminar parte de su código existente; pero si tuviera que depender de algo más allá de las exportaciones principales de RNW, se sumará rápidamente. En los componentes con mucho estilo para mobile.twitter.com, he observado una reducción del 20 al 40 % en el tamaño de los componentes al convertir estilos de módulos css a RNW StyleSheet. En términos de rendimiento en tiempo de ejecución, actualmente no está

¿Qué pasa con las consultas de los medios?

Puede usar matchMedia para cambiar los estilos y la estructura de los componentes, aunque los beneficios de usar consultas de medios para modificar los componentes no están claros para mí.

¿Herencia CSS, animaciones CSS?

RNW admite animaciones CSS (aunque necesito agregar una API para definir fotogramas clave). ¿Cuál es la pregunta relacionada con la herencia CSS?

¿Cómo implementaríamos eventos de accesibilidad y teclado sin inflar la versión nativa?

No estoy seguro que significa esto. Sospecho que el umbral de "hinchazón" en una aplicación nativa es mucho más alto que el de una aplicación web.

así que tal vez comparar cómo reacciona-native-web maneja los estilos para representar el rendimiento de css con el rendimiento de los módulos css es menos pertinente ahora

¿Por qué sería eso?

Sería genial tener una especie de react-native-web que use algo como aphrodite o jss

Ambas bibliotecas son más lentas, más grandes y no son adecuadas para proporcionar estilos deterministas.

@necolas material-ui está haciendo un gran esfuerzo para cambiar de un método css-in-js a un método de hoja de estilo (css en <style> ). Han sido esfuerzos activos durante meses para cambiar los componentes. Las razones están aquí . Por lo que leí, usar jss es una gran ventaja y parece ser la solución más perfecta para manejar el estilo hasta ahora.

Por cierto, al leer Roadmap.md nuevamente, el soporte de RN está en Roadmap.

Estoy muy interesado en usar Material-UI con react-native, ¿alguna información sobre el progreso?

@wswoodruff Puede consultar este por ahora: https://github.com/xotahal/react-native-material-ui

Actualmente, tenemos tres bibliotecas increíbles para eso:

• react-native-material-kit ★3110 - Llevar el diseño de materiales a React Native.

• react-native-material-design ★2447 - Componentes de diseño de materiales nativos de React

• react-native-material-ui ★1040 - Componentes de diseño de materiales altamente personalizables para React Native.

¡Disfrutar!

También está la interfaz de usuario Carbon UI menos conocida si vas a ser universal. Pero por mi tiempo probablemente me quedaría con uno de estos .

Se ha mencionado un par de veces en este hilo, pero quiero mencionarlo nuevamente debido a cómo afecta mi interés en este cambio: el principal beneficio del soporte de react-native que veo no se trata realmente de react-native , sino que se basa en las primitivas que permiten que se usen los mismos componentes en _tanto_ nativo como en web.

si se usara ese tipo de primitiva, también se podrían habilitar otras herramientas como react-sketchup y react-pdf .

personalmente, esos son más interesantes para mí que los nativos, pero estarían habilitados por los mismos cambios.

@jhabdas ¿Cómo es tu experiencia con Carbon UI? Bcz para mí se ve bastante bien, pero aún no lo usé.

@deadcoder0904 aún no lo ha usado personalmente. probablemente intente comunicarse con uno de los muchachos en rojo infinito. ellos ejecutan el boletín RN y deben ser los expertos en la materia. si y cuando construya otra aplicación RN (está bien, cuando...) esta vez no estaré machacando las cosas ni construyendo otro repetitivo: en mi humilde opinión, el espacio se resuelve con los repetitivos y componentes existentes .

Estos son algunos de los obstáculos que se me ocurren que deberían superarse para que MUI esté disponible en React Native. Asumiendo v1 MUI y mantenemos JSS, el patrón classes y otras cosas que en este momento son partes clave del diseño de API de MUI.

• JSS necesita admitir RN, es decir, crear objetos de estilo de tal manera que withStyles simplemente funcione. Más sobre esto en https://github.com/cssinjs/jss/issues/368#issuecomment -376708219.
• Suponiendo que no haya un envoltorio hacky o una transformación babel, necesitaremos aumentar el patrón classes para que funcione igual, pero tenga en cuenta el hecho de que en RN debería pasar una matriz a style , y probablemente debería llamarse styles . Tal vez esto podría manejarse eliminando classnames y agregando ayudantes propagables que, en segundo plano, cambien entre el manejo de clases/nombre de clase y estilos/estilos.
  Quizás:
  js const styleProps = props.composeStyles( 'root', (raised || fab) && 'raised', fab && 'fab', fab && mini && 'mini', color === 'inherit' && 'colorInherit', flat && color === 'primary' && 'flatPrimary', flat && color === 'secondary' && 'flatSecondary', !flat && color === 'primary' && 'raisedPrimary', !flat && color === 'secondary' && 'raisedSecondary', size !== 'medium' && `size${capitalize(size)}`, disabled && 'disabled', fullWidth && 'fullWidth', ); return <ButtonBase {...styleProps} ... />
  composeStyles aceptaría una lista de nombres de estilo (e ignoraría los valores falsos). En la web buscaría en props.classes y generaría {classNames} . En nativo, buscaría en props.styles y generaría un {style} .
  Originalmente pensé en this.composeStyles con un decorador, pero en lugar de eso, withStyles podría simplemente pasar un ayudante de composición de estilo como parte de los accesorios.
• Como otros mencionaron después de todo esto para hacer que los componentes de estilo básicos funcionen, necesitaremos trabajo adicional para hacer que las animaciones, los elementos táctiles, etc... funcionen.
• Sin embargo, para las animaciones no lo considero algo malo. Es una pequeña pérdida para las transiciones simples, donde solo está transicionando automáticamente opacity , backgroundColor , etc. Es posible que deseemos ayudantes que las mantengan simples. Pero por lo que he visto, las implementaciones de transición de materiales reales que no sean esas parecen demasiado complicadas/crípticas y no se ampliarán bien. react-transition-group tiene algunos buenos ideales para manejar la parte de bajo nivel de las cosas (manejo de entrada/salida, etc.), pero es problemático/en el camino en otros. Además, en lugar del diseño basado en transiciones css, creo que el camino a seguir con visión de futuro sería usar la nueva API de animaciones web y requerir el polyfill para ello.
  En otras palabras, creo que hay espacio para la creación de una nueva biblioteca para manejar animaciones en React que use animaciones web en el navegador y la API animada en React Native y es una mejora general sobre cómo MUI maneja la animación.
• MUI necesita deshacerse de la expectativa de que el comportamiento en cascada está disponible. Y la configuración del tema debe mejorarse para admitir la aplicación sencilla de modificaciones al tema dentro de un subárbol.
  En este momento, cosas como AppBar + Iconos funcionan configurando el color del texto, usando un color = 'inherit' explícito y asumiendo que el color se reducirá en cascada. Y es posible que esto sea lo mismo en otras partes de MUI.
  No hay una cascada como esta en React Native. En su lugar, debe declarar sus estilos explícitamente para cada Vista. Para este tipo de cosas, AppBar y otros componentes deberán poder proporcionar fácilmente una versión modificada del tema que se les proporciona con una modificación como cambiar el tema dentro de ese contexto a dark para que los íconos obtengan el ícono de contraste correcto colores (y puede basarse en la especificación de colores del icono real en lugar del color del texto). Tenga en cuenta que esto puede tener implicaciones en elementos como los menús anidados en las barras de aplicaciones.
• Como una extensión de este problema en cascada. MUI también está diseñado en torno a cosas como <Button>Text</Button> , donde se supone que MUI solo puede diseñar la fuente, la cara, el color, etc. de la raíz del botón, permitirle insertar cualquier cosa en los elementos secundarios y simplemente dejar que React DOM inserte una mezcla de elementos y nodos de texto y los nodos de texto obtienen el estilo correcto.
  Esto se desmorona en React Native. Todo el texto debe ser parte de un <Text> , todos los estilos de texto deben estar en los estilos de ese componente y un elemento de texto no puede contener elementos secundarios que no sean de texto (es decir,).
  Hay algunas opciones:
  
  
  
  • El patrón <Button text='Text' /> funciona mucho mejor en React Native. Desafortunadamente, eso es fundamentalmente diferente del espíritu de MUI, por lo que no es una opción.
  
  
  • Podríamos mapear los elementos secundarios y reemplazar las cadenas con elementos de texto con estilo. Sin embargo, esto es frágil, en el momento en que envuelves la cuerda en cualquier cosa, se desmorona (incluso react-intl haría que se desmoronara). Puaj.
  
  
  • No es la forma más bonita de hacerlo, tendríamos que esperar y no entiendo al 100% las implicaciones de rendimiento. Pero podríamos usar la nueva API de contexto de React 16.3 y exponer un <MuiText>Text</MuiText> . Básicamente, los componentes de MUI como Button tendrían proveedores que proporcionarían información sobre los estilos del contexto actual (fuente, color del texto, etc.) y MuiText solo consumiría esos datos y los aplicaría a un elemento de texto.
  
  

Hoy se lanzó v1, ¿cuáles son los planes de React Native❓?

Para React Native Material Support, hay una hermosa biblioteca llamada React Native Paper que será mantenida y respaldada por el equipo de CallStack.

Pero, ¿hay algún plan para portar esto a React Native porque creo que Paper funciona perfectamente bien❓

Si no, entonces probablemente puedas cerrar este problema :)

Gracias por compartir @deadcoder0904. Agregué Paper a Awesome React Components . No he oído hablar de CallStack. Al principio lo leí como Call-Em-All. Supongo que no son los mismos tipos, ¿sí?

@jhabdas No, no son iguales

@dantman Aquí están mis pensamientos sobre la mejor manera de conseguir soporte nativo

• si apegarse a jss no es un requisito absoluto, creo que fela es una alternativa viable:
  
  
  
  • fela-native admite consultas de medios y usa StyleSheet.create correctamente
  
  
  • Es increíblemente extensible . Podríamos haber reescrito las reglas para las propiedades web en sus proxies nativos reactivos, quitar cosas como :hover reglas nativas y probablemente recuperar cualquier sintaxis que se haya perdido de jss.
  
  
• react-native-animatable tiene soporte para fotogramas clave, y probablemente también podría usarse en lugar de Transition-Group, que puede o no funcionar con native .
• Estoy de acuerdo con subvertir la vista sin cascada de react-native. Se puede optar por el proveedor y el consumidor con accesorios cascade y inherit .
  Todas las bibliotecas nativas de reacción con las que he intentado trabajar han sido dolorosas o inutilizables debido a API demasiado rígidas y estilos que no se pueden anular, con la excepción de las que usan @shoutem/theme para permitir anulaciones (como la base nativa) .

Sigo esperando este apoyo. ¡Uso maravillosamente en la Web pero también desarrollo en dispositivos móviles!

alguna actualización sobre el soporte reaccionar nativo?

@oliviertassinari Tengo la intención de bifurcarme y comenzar a explorar el camino de implementación que describí anteriormente. Mi prioridad será obtener los componentes que necesito para que funcione otro proyecto, por lo que probablemente no estaré PRing soporte sólido de React Native en el corto plazo, pero intentaré mantenerlo "sincronizado" con el maestro tanto como pueda. con la esperanza de que algún día sea útil (o posiblemente fusionado)

@micimize Gracias por avisarme. ¡Te deseo mucha suerte en este proyecto! :) En cuanto a por qué no hemos estado trabajando en react-native todavía. Creo que viene en diferentes sabores. Lo que es más importante, no tenemos ningún mantenedor principal interesado en hacerlo. Puedo entenderlo, el uso de react-dom crece más rápido que el de react-native y es difícil.

Actualización sobre esto: migramos una parte sustancial de la funcionalidad a un estado algo usable, incluidas listas, botones, tarjetas, íconos, controles de selección, campos de texto y fondo. Desafortunadamente, una vez que finalmente desarrollamos nuestra aplicación en React-Native, surgieron una multitud de problemas que nos obligaron a pasar a Flutter.

En algún momento, me gustaría regresar y recuperar parte del trabajo que hicimos, principalmente el puerto de la solución de estilo withStyles / classes que aprovechó las propiedades de taquigrafía de css y algunas otras cosas interesantes, sin embargo, ya no es una prioridad. para mí.

@rogerstorm financió este número con $200. Véalo en IssueHunt

Trabajar en el problema sería un costo de oportunidad para nosotros. estoy cerrando Redoblaremos el esfuerzo para brindar un mejor soporte a los casos de uso del navegador.

@oliviertassinari , ¿significa que el soporte nativo de reacción está fuera del alcance y en un futuro cercano (por ejemplo, 1 año) no estará en el radar?

sí

https://github.com/lightningtgc/react-native-material-ui No es más que otro paquete fraudulento de npm