React Native en todas partes

♪ Soy Taz Singh y hoy estoy aquí para hablar sobre React Native en todas partes. Y cuando digo en todas partes, sí, me refiero a todas partes, incluso aquí abajo, con estos adorables pingüinos.

Para aquellos de ustedes que no me conocen, soy el fundador de Gild. Es una nueva plataforma que está en beta en este momento y tiene como objetivo elevar comunidades en todo el mundo. Actualmente, nos enfocamos en eventos, como el que estamos presenciando ahora mismo, y presentaciones, como la que estoy dando, todas alojadas en la misma plataforma. Así que ven a hablar conmigo más tarde si tienes curiosidad sobre la plataforma.

Pero a estas alturas, es posible que hayas notado que mi acento ciertamente no es de aquí. Y eso se debe a que soy de Toronto, donde comencé la comunidad de Toronto JS en 2010. En aquellos primeros días, fui objeto de muchas bromas sobre JavaScript. Oh, no eres un verdadero desarrollador, solían decir, a menos que programes en C++ o .NET o Java. Y para mí, fue como un golpe, porque si alguna vez has construido una aplicación web en JavaScript, sabes cuánta diligencia se requiere. Alrededor de 2010, comenzamos a construir aplicaciones utilizando Backbone y Underscore, que eran bestias inmensamente complejas. Así que comencé Toronto JS para reunir a las personas y aprender unos de otros, para elevar la artesanía juntos. Y gran parte de lo que hicimos en aquel entonces sirve como mi impulso para comenzar Guild hoy. Eso se debe a que rápidamente descubrí que comunidades como Toronto JS están en todas partes. Estamos en una comunidad similar aquí en este momento. De hecho, muchos de mis amigos más cercanos son personas que conocí a través de la comunidad, algunos de los cuales están en esta misma sala.

Así que empacé mis maletas y me mudé a Londres en 2017 para explorar esas comunidades en todo el mundo. Y también fue entonces cuando me presentaron a React Native en todas las plataformas. Aquí me puedes ver dando una charla sobre eso en Londres justo después de mudarme. Este tweet es de Ellie, que está justo allí. Ella es una organizadora de ese evento donde hablé y ahora también es una muy buena amiga. Puedes encontrar esa presentación publicada en Guild yendo a mi perfil, haciendo clic en las presentaciones que he dado, o haciendo clic en 6 y 1, eso te llevará a un video de la charla que di en ese entonces. Así que siéntete libre de echarle un vistazo.

Pero para darte un resumen muy rápido de esa charla, básicamente el objetivo era tener código común en todas las plataformas. Por supuesto, cada plataforma es diferente y requiere consideraciones únicas para abordar adecuadamente las ventajas de cada plataforma. Esta es una de las fortalezas principales de React Native. Podemos llevar esa singularidad a los límites y mantener el núcleo de tu base de código común para todas las plataformas. Cosas como selectores de fecha, entradas de archivos, notificaciones, mapas y más pueden abordarse en los bordes, dejando que el interior de tu aplicación se enfoque en la experiencia común. Para nosotros, una startup en etapa inicial, es importante optimizar la eficiencia del desarrollador.

Queremos que cada cambio en nuestra base de código sea lo más impactante posible. No queremos equipos separados trabajando en cada plataforma que resultaría en ninguna compartición de código en absoluto. No queremos un bajo nivel de compartición de código donde tal vez algunos elementos se compartan, pero la mayoría aún está separada. En un mundo ideal irrealísticamente perfecto, querríamos que el 100% de nuestro código se comparta en todas las plataformas, pero eso no abordaría la singularidad de las plataformas individuales y en mi opinión, React Native lo hace fácil respetar la individualidad de cada plataforma y al aprovechar eso, puedes crear experiencias móviles verdaderamente únicas, o perdón, experiencias nativas. Realísticamente, lo que queremos es que la gran mayoría de nuestro código se comparta en todas las plataformas, apuntando a compartir más del 95% del código y hacer que nuestros desarrolladores sean lo más impactantes posible.

Por supuesto, siéntete libre de consultar mi charla de 2017, donde hablo más a fondo sobre esto y también incluyo toda la configuración de webpack para que suceda. Pero en estos días, todo eso está empaquetado con Expo. Echa un vistazo a lo que tienen. Recomiendo consultar su documentación y tienen excelentes guías para comenzar y ejecutar en cada plataforma. Haz cualquier aplicación, ejecútala en todas partes.

Hoy me gustaría centrarme en la siguiente etapa de mi viaje, la composición responsiva y la navegación. Comencemos con la responsividad. No es ningún secreto que existen múltiples factores de forma. Al construir una aplicación que funcione en todas partes, obviamente necesitamos tener esto en cuenta. Uno esperaría que una plataforma como React Native tuviera esto en cuenta, pero realmente solo proporciona los elementos básicos. Y lo más importante, no hay CSS, lo que significa que no hay consultas de medios, no hay cuadrícula CSS, no hay selectores CSS en absoluto. El estilo en React Native se inspira en CSS en el sentido de que utiliza nombres de propiedades CSS y tiene una implementación de Flexbox. Pero CSS en sí mismo no existe en React Native. Si alguna vez has construido una aplicación web responsiva antes, puedes empezar a ver lo desafiante que es construir esas mismas interfaces de usuario sin ninguno de los constructos basados en la web a los que estás acostumbrado.

OK, hablemos de la composición. Supongamos que tienes código de React Native que se ve así, con una interfaz de usuario renderizada a la derecha. Aquí estamos simplemente renderizando una lista básica de elementos. El diseño no se ve realmente genial. Así que agreguemos un color de fondo y algo de relleno a ese contenedor. OK, ahora los elementos están un poco apretados entre sí también. Agreguemos un poco de espacio entre ellos. Y puedes ver que los tres elementos inferiores tienen un relleno superior aplicado pero el superior no. Y eso se debe a que si aplicamos el mismo relleno, habría demasiado relleno con el contenedor también. Si eliminamos el relleno del contenedor, entonces afectaríamos la composición, donde si tenemos varios de estos renderizados dentro del mismo contenedor, el relleno estaría desalineado en todo el conjunto. Y el código también es bastante repetitivo. Realmente no escribiríamos código así en la realidad, así que lo refactorizaríamos a algo como esto, donde, como puedes ver, el array que estamos mapeando podría ser datos de un servidor o algo así. Y realmente estamos mirando el índice del array para determinar qué estilos aplicar. Entonces, fundamentalmente, me encuentro haciendo esto bastante seguido y tratando de pasar esa prop de estilo para cada componente individual. Descubrí que tenía que controlar el paso de la prop de estilo, lo cual es un poco molesto cuando tienes un equipo de desarrolladores y estás tratando de asegurarte de que la pasen correctamente. La composición simplemente no funcionaba.

Entonces, ¿qué hago? Bueno, afortunadamente, fui a consultar en Bangalore en 2017, y los organizadores de la comunidad de React Bangalore se pusieron en contacto conmigo y me preguntaron si quería presentar para su comunidad. Las comunidades están en todas partes, después de todo. Y así acepté, y aquí estoy hablando de un Pontiac Aztec. Es un coche realmente magnífico. Tuve el placer de conocer a los organizadores de esa comunidad. Uno de ellos es Sid Dart, quien está sentado a mi lado en esta foto, y en realidad está hablando en el otro escenario. No estoy seguro si esta es la primera vez que el orador está en ambos escenarios al mismo tiempo. Y gracias a Dios lo conocí, porque ahora es uno de los expertos más destacados en el espacio del sistema de diseño de React, a quien admiro por su conocimiento en esa área.

Alrededor de la misma época en 2020 en la que estaba buscando una solución para mi aplicación de React Native, Sid lanzó React UI. Esto se tomó del propio sitio web de React UI, donde dice que React UI viene con un conjunto de componentes que son accesibles, responsivos y personalizables. Eso suena exactamente a lo que quiero. Tiene una lista de componentes con los que se puede trabajar, como elemento, enlace, selección, texto, área de texto, y así sucesivamente, y lo más importante, en la parte inferior también hay stack y grid para ayudarte a construir un diseño con esos otros bloques de construcción.

Pero el problema era que React UI está diseñado para la web, y lo que yo estaba construyendo era para React Native en todas partes. Pero me pregunté si tal vez podría crear un sistema de diseño de React Native, tal vez esos constructos de diseño podrían ayudarme con la composición responsiva de mis aplicaciones de React Native, así que intenté hacer exactamente eso. Después de varios intentos y errores, logré que algo funcionara y decidí enviarle un mensaje a Sid. Le dije: `Hola Sid, ¿cómo va todo? ¿Disfrutando de Ámsterdam? Quería decirte que soy un gran fan de React UI, de hecho, soy tan fanático que terminé implementando gran parte de él para React Native de manera multiplataforma. Es un descarado plagio de React UI, pero por supuesto, React UI es para la web y lo que yo he hecho es para React Native. Por lo tanto, no hay emociones, no hay CSS, lo hice de manera un poco diferente, y así sucesivamente`. Sid amablemente respondió: `Eso es genial. React UI es un tema de plagio, plagios por todas partes`. Como siempre digo, los buenos artistas copian, los grandes artistas roban, ¿verdad? Mirando las fechas de esos mensajes, se puede ver que esto fue durante el confinamiento en 2020, cuando estaba trabajando en esto, y esta es una imagen de lo que construí en ese momento. Esto es código de producción directo, directamente de nuestro código base. Espero que al mirar el código a la izquierda, puedas ver cómo se mapea esencialmente a la interfaz de usuario a la derecha.

El constructo crítico que hace que todo esto sea componible es el componente stack. Solo tengo que establecer la propiedad de espacio y el resto se renderiza en función de eso. Ya no es necesario pasar un estilo como prop, y para establecer todo el espaciado, todo funciona automáticamente. En la parte inferior, renderizo un componente de elemento de usuario, donde si muestro el código de eso y lo resalto con una línea punteada roja, también verás lo que se está renderizando allí. Nuevamente, es solo un stack. Esta vez es horizontal, muestra la foto principal de un usuario y también muestra un componente de enlace con el nombre del usuario. Simplemente componiendo stacks, podemos escribir toda nuestra interfaz de usuario de una manera que se ajuste perfectamente. Creo que eso es lo que llaman ser un desarrollador full stack. Podemos tomar eso y colocarlo dentro de una cuadrícula, que puedes ver aquí. Podemos tomar el stack, que tiene una cuadrícula con columnas dentro de cada fila. Nuevamente, simplemente componiendo estos stacks en una cuadrícula con columnas, podemos construir toda esa página a la derecha. Como puedes ver, es completamente responsiva y también altamente declarativa. En este punto, estaba bastante contento.

Lo logré. Todo el Guild está construido de esta manera y parece funcionar bastante bien. Así que se me ocurrió un nombre llamativo. Mondrian. Está nombrado en honor al famoso ingeniero de sistemas de diseño neerlandés, Piet Mondrian, conocido por componer stacks en interfaces de usuario que se ven así. Así que creé un repositorio vacío en GitHub y comencé a prepararme para un lanzamiento público. Estaba realmente emocionado de compartirlo con todos ustedes. Pero justo en ese momento me enteré de Native Base. Así que comparemos Native Base con Mondrian, ¿de acuerdo?

¡Muy bien! Es un sistema de diseño de React Native para todas las plataformas. Es mucho más completo que lo que hemos construido. Estamos en la versión 0.0.0 alpha 3, ellos están en la versión 3.4.6. Tienen accesibilidad. También tienen documentación. Y lo más importante, fue construido en Bangalore, que fue la inspiración para Mondrian desde el principio. Así que en estos días, también recomendaría un sistema de diseño para ustedes, diría que simplemente usen Native Base. Han hecho un trabajo fantástico. Creo que algunos miembros del equipo están aquí hoy si quieren hablar con ellos.

De acuerdo, ¿qué sigue? Navegación. Bueno, hay navegación en dispositivos móviles y de escritorio. En estas plataformas, es más típico navegar utilizando la propia interfaz de usuario. Tocas un botón y navegas a otro lugar. Básicamente, la interfaz de usuario es la construcción de navegación principal sin mucho más en términos de controles externos para manipular esa interfaz de usuario. Existe el botón de retroceso de Android, que es una especie de excepción, pero no profundizaré mucho en ese tema en esta charla. Luego está la navegación basada en la web, donde el navegador tiene un botón de retroceso, un botón de avance, un botón de actualización, una barra de URL y pestañas. Cada uno de estos manipula la navegación externamente, esencialmente hacia la aplicación. No tengo que explicar cómo funciona un navegador, pero la diferencia de navegación principal es básicamente la barra de URL, donde deberías poder tomar esa URL y pegarla en una nueva pestaña, y simplemente funcionará. Para demostrar eso, aquí está la página de Instagram de mi gato. Es adorable, ¿no crees? Si navegamos utilizando la interfaz de usuario, si tocamos una imagen, se abre en un modal. Verás que hay un fondo en ese modal, porque tiene el contexto de qué poner en ese fondo. Sin embargo, si copias y pegas esa URL en una nueva pestaña, no hay fondo.

Se abre como una página completa para esa imagen. Y de nuevo, esta es una diferencia fundamental entre la navegación móvil y de escritorio, donde la navegación móvil y de escritorio pueden funcionar en el primer caso, pero la web tiene que funcionar para el segundo caso.

Entonces, ¿cómo construimos esto? Bueno, está React Router, que ofrece soporte para enrutamiento basado en DOM para navegadores, así como para React Native. Y aunque funciona muy bien, no está realmente integrado en dispositivos móviles para permitir cosas como arrastrar desde el borde de la pantalla para retroceder, como esa sensación nativa realmente elegante, no tiene eso integrado.

Luego está React Navigation, que es una experiencia de navegación completa y orientada a dispositivos móviles. Si has construido algo con React Native antes, es probable que hayas usado React Navigation. Utiliza pantallas de React Native de Software Mansion para habilitar esa funcionalidad de arrastrar desde el lateral de la pantalla. Y en dispositivos móviles, se siente increíble, se siente genial, se siente nativo, se siente adecuado. En los últimos años, han lanzado este soporte, como muestro aquí, y lo probamos, pero simplemente no funcionó muy bien. Si bien técnicamente funciona, varias cosas se sintieron pesadas y algo fuera de lugar. Cosas como la carga incremental de rutas, que obviamente quieres tener en una experiencia web. No quieres cargar todo en una carga gigantesca en la web. También hizo que la barra de URL se evaluara incrementalmente. La barra de URL simplemente se reescribiría a medida que se cargaban las rutas. Los botones de retroceso y avance tampoco funcionaban del todo bien, por lo que si hacías clic en retroceso, avance, retroceso, avance, toda la aplicación se ponía en un estado extraño y no podía recuperarse, así que tenías que actualizar y luego la barra de URL comenzaba a reescribirse nuevamente.

Entonces, para resumir, React Router tiene un gran manejo de estado, pero no se siente nativo en plataformas que no son web. El manejo de estado de React Navigation es un poco extraño, pero tiene esa sensación nativa, por lo que al construir una base de código compartido del 95% o más con la misma navegación para cada plataforma, elegimos React Navigation a pesar de sus defectos. La experiencia de usuario no será ideal, pero los usuarios tendrán que vivir con eso, y la extrañeza estará presente. Sé que el equipo es inteligente y está trabajando muy duro para mejorarlo. Intenté ayudar enviando solicitudes de extracción, pero rápidamente quedó claro que una biblioteca con el legado de React Navigation requiere más consideración de la que pude dedicar. Pero simplemente esperaremos. Nos actualizaremos. Estoy seguro de que están trabajando en ello. Y a medida que lancen nuevas funciones, esencialmente las tendremos también en Guild. Esperamos que la experiencia de usuario mejore con cada lanzamiento. Y eso es todo. Gracias a todos. Aplausos, aplausos, aplausos, aplausos.

Lorenzo es un mantenedor de formularios de React Navigation y está muy involucrado en los esfuerzos de la community de React Native. A menudo, cuando no sé cómo proceder en el espacio de React Native, simplemente le pregunto a él. Porque él suele saber sobre las cosas antes que el resto de nosotros. Y esta vez, cumplió. Me habló de una nueva biblioteca llamada React Native URL Router. Eso suena exactamente a lo que quiero. Un enrutador de React Native, pero con URLs. Así que eché un vistazo a la página de documentación y encontré este ejemplo. No estoy seguro si pueden ver el texto pequeño, pero en esencia combina las mejores partes de React Router con las mejores partes de las pantallas de React Native para proporcionar esa experiencia de navegación de arrastre desde el borde con una increíble gestión de estado. Se veía increíble.

Así que fui a probarlo y descubrí que no funcionaba en absoluto en la web. Todavía es experimental y solo está construido para dispositivos móviles. Pero agregar soporte web parecía bastante sencillo. Parecía que solo requería cambiar esos dos componentes allí. Cambiar un enrutador nativo por un enrutador de navegador. Cambiar un navegador de pila por un componente de ruta ambos de React Router y parecía que debería funcionar. Parecía muy simple y directo.

Pero no quería hacer todo el esfuerzo de enviar PRs solo para que los mantenedores los rechazaran porque no se alineaban con su dirección. Así que me puse en contacto con un mantenedor Alec de Software Mansion y le pregunté si podíamos tener una charla rápida antes de empezar a enviarle PRs. Y lo que obtuve realmente me sorprendió. Alec organizó una llamada con Christoph a quien busqué en LinkedIn antes porque no sabía quién era. Es el director de ingeniería de Software Mansion y yo estaba como oh no. Sé cómo va a ser esto. Va a ser una de esas charlas en las que es como, bueno, Taz, ya sabes somos una consultoría y si quieres nuestra ayuda puedes contratar a un consultor para que te ayude y al final te enviarán una gran factura. Pero en realidad no obtuve eso en absoluto. Fue sinceramente encantador y muy amable. Recibí mucho apoyo y amabilidad de ambos que sinceramente me sorprendió mucho. Me dijeron que estaban aquí para ayudar en cualquier aspecto de su biblioteca. No pidieron nada a cambio, solo amables comentarios sobre cómo podemos mejorar juntos. De hecho, estaban más interesados en la dirección de Guild como plataforma porque querían que también ayudara a sus esfuerzos de community. Y tengo que decir que llevo dos décadas en el negocio del software y no creo haber visto tanto amor y dedicación como el que he visto en estos dos. Fue sinceramente increíble. Solo puedo hablar de ellos en los términos más y también recomendaría que eches un vistazo a sus esfuerzos de community.

En resumen, acordamos asociarnos en React Native URL Router. Queríamos utilizar Guild como una aplicación de ejemplo para probar los paradigmas y asegurarnos de que funcionaran bien. Así que terminé removiendo toda la aplicación. Eliminé la navegación de React y la reemplacé por React Router como un paso intermedio para migrar a React Native URL Router. Estas son las estadísticas de esa solicitud de extracción. Puedes ver que eliminé más del doble de código del que agregué. En general, la aplicación se siente mucho más rápida y la navegación basada en el navegador se siente más natural. ¿Te diste cuenta? ¿Notaste que Guild está utilizando React Native Web? ¿Notaste que Guild está construido utilizando un sistema de diseño propio? ¿Notaste que también está utilizando un marco de navegación experimental? ¿O simplemente pensaste que era una aplicación web ordinaria construida de manera ordinaria? Hablé mucho sobre ejecutarse en todas las plataformas, aunque actualmente nos estamos enfocando en la web, pero esperamos lanzar de manera incremental una aplicación móvil y de escritorio en el futuro, ya que toda nuestra infraestructura considera todas estas plataformas diferentes y lanzar para ellas es mucho más fácil que comenzar una base de código completamente nueva.

Pero, si has aprendido algo de esta charla, debería ser que solo somos tan buenos como la comunidad que nos rodea. A lo largo de este viaje, tengo la suerte y el privilegio de haber conocido a las personas que he conocido a través de la comunidad. Sin ellos y sin su apoyo, no estaría en ninguna parte. No es que sea especial. Simplemente asisto a eventos, hablo con las personas allí y aprendo de las personas que me rodean. Esa es exactamente la razón por la que comencé TorontoJS en 2010. Esa es exactamente la razón por la que estamos trabajando en Guild en este momento. Porque al final del día, las comunidades están en todas partes. Y ahora tu tecnología también lo está. Gracias. ¿Estás seguro esta vez? ¿Puedo...? Me han decepcionado antes. ¡Eso fue increíble! Gracias. Hablemos de ello. Quédate ahí mismo.

¡Hola Taz! No, no. Vete. Bueno, la gente quiere saber. ¿Algún consejo para comenzar a compartir variables de diseño básicas entre web y móvil, colores, tamaños de fuente, etc.? Sí, una pregunta fantástica. Para mí, simplemente miré React UI para esto, así que te recomendaría que hagas lo mismo. Creo que Sid escribió una documentación fantástica sobre esto. En esencia, lo que ha hecho es tener todo un sistema de tokens definido para su sistema de diseño.

Luego puedes aprovechar esos tokens definidos de forma centralizada a través de una variante en cada bloque de construcción de tu aplicación, lo que te permite compartir de manera efectiva y aún centralizar este tipo de variables. Básicamente, lo que descubrí que no funcionaba muy bien es básicamente esa prop de estilo. Si pasas esa prop de estilo, permite una personalización excesiva en cada capa. Entonces, si te equivocas por un píxel, todo el design se ve mal. Al mantener todos esos tokens de manera más centralizada, te permite adaptar toda tu aplicación, todo tu sistema de diseño, de manera más centralizada también, y eso mantiene las cosas muy coherentes y bien gestionadas. Bien, siguiendo adelante. ¿Cómo eliges entre todas estas bibliotecas? ¿Obtienes consenso del equipo? ¿Lo escribes? ¿Hay pros y contras? Excelente pregunta. Nunca tengo una buena respuesta para esto, porque siempre es tan difícil. Para mí, a menudo pienso en la regla del 90-90. No estoy seguro si estás familiarizado con la regla del 90-90, pero básicamente, alguien que trabajó en creo que fue Xerox Labs, hace mucho tiempo en los años 70, de los cuales Apple robó todo. Terminaron inventando bastante. Así que él ideó la regla del 90-90, que es el primer 90% de tu tiempo trabajando en un proyecto, el último 10% del proyecto es el otro 90% del tiempo. Porque básicamente ahí es donde todo se desmorona, tus ideas, tus paradigmas, tu dirección, todo se desmorona en ese último 10%, requiriendo el otro 90% del tiempo. Así es como elijo. Simplemente voy y construyo algo. Construyo, construyo, construyo, construyo, construyo. Todo se desmorona. Aprendo mucho. Descubro cómo debo adaptar mi paradigma, descubro cómo debo adaptar el uso de mi biblioteca, y luego tal vez miro otra biblioteca, si eso se desmorona en ese último 10%. Así que para mí, sinceramente, simplemente comienzo a escribir código, simplemente comienzo a construir, simplemente comienzo a ver cómo funciona. Con el tiempo y la práctica, puedes comenzar a reconocer patterns más temprano, y luego, con suerte, no necesitas el 100% del tiempo la próxima vez. ¿Estás preparado, crees, en el futuro para reescribir? ¿O cambiarlo todo? ¿Emocionalmente? Emocionalmente, nunca. Como dije, queremos ser lo más impactantes posible. Entonces, por ejemplo, con Guild, pasé alrededor de dos años construyendo esa architecture. Solo probando cosas, reescribiéndolo, probando algo más, reescribiéndolo, probando algo más, reescribiéndolo. Creo que ahora estamos en la reescritura número cuatro. ¿Está bien ahora? Espero que esté bien ahora. Espero, cruzo los dedos, que esté bien ahora. Lo descubriremos. ¿Cuándo crees que será público público? Ahora mismo, puedes ir a beta.guild.host y estará allí. Vamos a quitar el beta en tal vez unos meses, veremos cómo va. Es simplemente cuando nos sintamos cómodos con ello. Cuando sea cómodo, cuando recibamos buenos comentarios de la community, quitaremos la etiqueta beta. Genial, una vez más, gracias Taz por unirte y iluminarnos. Gracias.