¿Cómo Usamos React Native en Mattermost? Arquitectura y Diseño

Bienvenidos a todos. Hoy estoy aquí para hablar sobre cómo usamos React Native en Mattermost. Mi nombre es Daniel Espino-Garcia, y soy un ingeniero de design software en Mattermost. Si quieres contactarme, no dudes en pasar por la oficina en el servidor de la community de Mattermost.

En primer lugar, quiero darles algunos descargos de responsabilidad sobre la charla de hoy. ¿Lo que voy a hablar, es la mejor solución para cualquier proyecto? No, por supuesto que no. Cada proyecto es diferente. ¿Entonces hay una solución para tu proyecto? Depende de tu proyecto, pero probablemente tampoco. Mi esperanza es que esta charla pueda generar ideas que puedas usar en tus proyectos. ¿Es esta la mejor solución para nuestro proyecto? Espero que sí, pero probablemente tampoco. No somos perfectos. No hemos evaluado todas las posibilidades. Cada día aprendemos algo nuevo, y de vez en cuando, aparece una nueva tecnología. Esto es solo lo que hemos probado hasta ahora, y nos ha funcionado. Si crees que algo puede mejorarse, por favor pasa por la oficina y házmelo saber. Siempre estamos contentos de hacer las cosas mejor.

Con eso fuera del camino, comencemos. Aquí está la agenda para hoy. Entonces, solo para ser tradicionales, comencemos con el primer punto. ¿Por qué esta charla? Comencemos explicando qué es Mattermost. Quizás solo mirando la imagen te hagas una buena idea de qué es Mattermost, pero aparte de una larga definición en nuestro sitio web, podemos obtener una descripción más mundana. Una alternativa de código abierto a Slack y Microsoft Teams. Esto es mucho más que eso, pero eso da una idea general de lo básico. Y por supuesto, tenemos una aplicación móvil escrita en React Native. Entonces, genial, Mattermost es una aplicación de chat. ¿Qué la hace interesante para hablar de ella? Bueno, en primer lugar, la aplicación React Native tiene un tamaño decente. Más de 100,000 líneas de código. Y por lo tanto, recientemente hemos hecho una revisión completa de la aplicación. La primera versión enfrentaba algunos desafíos, y rehicimos la aplicación. Nueva architecture, nueva interfaz, y la mayoría del código, revisado y reescrito.

Y creemos que hay mucho que aprender de eso. Pero también hay varios desafíos que esperamos hagan el proceso interesante. Uno de los más grandes es el soporte para multi-servidor. Trabajando con varias versiones, Mattermost es auto-gestionado, pero la aplicación se distribuye a través de las tiendas, por lo que la aplicación debe ser compatible con versiones anteriores. Y con varios servidores, el aislamiento de los data se convierte en un gran desafío. No quieres un mensaje destinado a un servidor familiar y a un servidor de tu trabajo.

Y nuestro gran desafío es el soporte offline. Las personas no esperan recibir mensajes cuando están en un avión, pero seguro esperan revisar los mensajes anteriores. Y el código fuente está abierto para contribuciones de la community, por lo que es aún más importante que los nuevos ojos puedan entender bien el código. Porque sí, la mayoría del código es de código abierto y eso incluye la aplicación móvil! El código completo de la aplicación móvil está en GitHub, por lo que todo lo que voy a hablar hoy es algo que puedes comprobar directamente en el código, aprender un poco más sobre él, e incluso jugar con él, ya sea en tu propio fork, o contribuyendo upstream. Espero que estas sean razones suficientes para permanecer en esta masterclass.

Ahora hablemos de la base. Aquí cubriremos algunas decisiones generales sobre el proyecto. Por ejemplo, ¿dónde estamos usando React Native? Permíteme empezar con qué es React Native. Tienes la descripción oficial, pero puede ser resumido crudamente a React Mobile. Una de las principales ventajas, como muchos otros frameworks, es que te permite escribir un solo código que funciona en iOS y Android. También te permite ajustar y extender tu aplicación en el lado nativo. ¿Necesitas una característica nativa super específica para tu aplicación? Puedes sumergirte en el código nativo y crearla. Otra cosa importante es que es bastante popular, y la community es bastante activa. La mayoría de tus respuestas están a una búsqueda de Google de distancia. Y finalmente, esto será importante más tarde, React Native está escrito en JavaScript.

¿Y por qué usamos React Native en Mattermost? Veamos nuestro stack. Si miramos el backend, el código del servidor está escrito en Golang. Pero en el lado del front, el código del navegador está escrito en React, que utiliza JavaScript. La aplicación de escritorio utiliza Electron y React, que de nuevo utiliza JavaScript. Y la aplicación móvil utiliza React Native, que utiliza JavaScript. Ya puedes ver un patrón. Podría hablar de alternativas con Native puro o Flutter, pero todo se reduce a una gran razón. Porque utiliza React. React Native tiene muchas otras cosas geniales que pasan por esto.

Pero la razón principal es que utiliza React. Usar una tecnología similar al resto del stack permite a cualquier desarrollador de frontend desarrollar características para mobile apps. De esta manera, un pequeño equipo móvil puede ser responsable solo de los detalles más técnicos del diseño native. Pero ha habido más decisiones en el camino.

Estas son algunas decisiones que enmarqué para hacer la aplicación más confiable. La más importante es el uso de TypeScript. ¿Qué es TypeScript? Resumiendo demasiado, es JavaScript con tipos. A todos nos encanta la flexibilidad de JavaScript, hasta que tenemos un gran proyecto y ya no nos gusta más. Con TypeScript, la comprobación de tipos, la refactorización, etc, se vuelve mucho más sencilla. Introduzco menos errores en el código. Prácticamente, todo el código de nuestra aplicación está escrito en TypeScript. Para seguir las directrices de REaD, también movemos muchos componentes a componentes funcionales. No es solo el enfoque recomendado por el equipo de REaD, hace más difícil hacer componentes enormes, incluso si es solo por la sensación fácil de ver una función de 1,000 líneas de longitud. También intentamos especializarnos, cuidar especialmente, ser especialmente cuidadosos con la organización de carpetas. Por ejemplo, las pantallas están en alguna carpeta, separadas de los componentes de uso común. Tener las cosas organizadas ayuda a encontrar cosas no solo para nosotros, sino también para los contribuyentes. Y finalmente, tenemos muchas reglas de codificación en todas partes, desde reglas básicas de Linting, hasta el orden de importación, hasta algunas directrices de estilo de componentes. Así que vamos a ver eso un poco.

Echa un vistazo a este componente de ejemplo. Nuestros componentes suelen tener las props, los estilos, el componente y la exportación siempre en ese orden. De esa manera sabes dónde buscar cosas. Además, el interior de un componente tiene un orden estándar. Primero, los hooks comunes, como obtener el tema, estilos, luego todas las asignaciones, como estados o variables auxiliares, luego todos los callbacks, y justo antes del render, todos los efectos. ¿Por qué esto? Porque tener las cosas ordenadas reduce la carga cognitiva al leer un componente largo. Cuando los efectos y los callbacks están mezclados, se complica mucho distinguir entre ellos y ver qué ha sucedido realmente, tanto al intentar entender el componente como al revisar el código del componente. Y eso es todo para los fundamentos. Pasemos a la gestión del estado. Como casi todos con un proyecto de React, usamos Redux para nuestro estado. Pero había un problema. En primer lugar, el estado completo tenía que estar en memoria.

Esto es genial cuando tienes un estado relativamente pequeño. Pero nuestro estado es enorme. Equipos, canales, publicaciones, los problemas de memoria estaban destinados a ser.

El siguiente problema está relacionado con el soporte offline. Toda la información tiene que ser persistida en la forma y luego cargada de nuevo. Y la aplicación no puede iniciar si ciertas partes del estado no están cargadas. Pero todo el estado tiene que ser cargado. Por lo tanto, la carga inicial tomará más tiempo.

Y el problema final era el multiservidor. No era posible implementar multiservidor. ¿Por qué? Porque los problemas que acabo de mencionar se multiplican por el número de servidores volviéndose completamente no escalables.

Así que decidimos movernos a WatermelonDB. ¿Por qué? El estado se almacena en una database similar a SQL, por lo que no es necesario tenerlo completamente cargado en memoria en ningún momento. Solo necesitamos obtenerlo de la database. ¿Pero no es eso más lento? Dado que el estado de la consulta es cache, tal vez sea más lento en la primera consulta. Pero siempre que se acierte en la cache, no debería dar problemas.

Luego toda la reactivity al estado usa RxJS. Y podemos crear bases de datos separadas para cada servidor, ayudando mucho con esa aislación. Al final del día, WatermelonDB nos trajo un sistema más escalable listo para multiservidor.

Pero no todo es maravilloso. WatermelonDB también tuvo desafíos. Entre otras cosas, RxJS es nuevo en el stack de Mattermost, por lo que necesita una curva de aprendizaje más empinada para los equipos de características del resto de la empresa. El modelo de data es un modelo de data relacional de database, por lo que es más rígido, y eso lleva a cuidar las migraciones de database, que en general suenan más como un problema de back-end que un problema de front-end. Y tristemente, WatermelonDB no soporta hooks, y tienes que confiar en componentes de alto orden.

Pero aparte de todo eso, usar WatermelonDB ha valido la pena. Y te mostraré un poco sobre ello. Acceder a la database es sencillo. Hemos puesto todas las consultas en la carpeta de consultas, y son mayormente tres. Obtener un solo valor de la database, observar un solo valor para cambios, y crear consultas más complejas que pueden ser obtenidas o observadas. Obtener el estado de la database en un componente tampoco es complicado.

Usamos este HighOrderComponent y RxJS para obtener los valores. Verás que usamos las funciones de observación de las que hablé antes, y luego compilamos estos observables para obtener otros valores. En este ejemplo, obtenemos el ID de usuario actual de Azure. A partir de eso y del nombre del canal, obtenemos el ID del autor. Y con eso, obtenemos el usuario actual.

¿Y qué pasa con la actualización de los data en la database? Para la modificación, hemos reunido lo que llamamos acciones. Y las separamos en dos tipos, remotas y locales. Para nosotros, las acciones remotas son aquellas que van al servidor para obtener información, y pueden o no pueden almacenar información en la database. Por lo tanto, tenemos la opción de solo buscar para asegurarnos de que solo almacenamos lo que queremos almacenar. Las acciones locales simplemente actualizan la database. Por lo tanto, muchas acciones remotas pueden llamar a acciones locales. Pero también, tenemos una opción para preparar solo los registros. ¿Dónde haremos eso? Para agrupar varias acciones de database en una. Y como puedes ver, tenemos las diferentes acciones correctamente separadas en diferentes carpetas, por lo que estás seguro de que las que estás importando van al servidor o se quedan locales.

Así que con la gestión del estado fuera del camino, echemos un vistazo a los hooks. Los hooks son algo que me gusta mucho. Así que lo siento si me pongo un poco apasionado. Espero que todos sepan qué son los hooks, pero repasémoslo un momento. Los hooks son un pequeño fragmento de código que permite alguna funcionalidad en los componentes de función. Por ejemplo, almacenar el estado, memorizar valores, agregar comportamiento, o lo más interesante de todo, un poco de todo. Así que veamos lo que hemos hecho con los hooks personalizados. Agregar y modificar el contexto. Con el proveedor de temas, servidor, o historial de internet, echemos un vistazo al proveedor de temas, por ejemplo. El hook personalizado es bastante simple. UseTheme simplemente devuelve el valor de useContext. Lo que tiene un poco más de interés es el proveedor de temas en sí. Basado en varios valores, nos aseguramos de pasar el valor correcto al proveedor. Con esto, cualquier componente que necesite ser estilizado en base al tema solo tiene que llamar useTheme, y toda esa complejidad está oculta para el desarrollador. Otra cosa que hacemos con los hooks es reducir el código repetitivo. Hay muchas acciones que no son especialmente difíciles de implementar, pero simplemente añaden mucho código repetitivo al código, así que hemos extraído ese código repetitivo a algunos hooks, por ejemplo, manejando el botón de retroceso en Android, o los botones de navegación presionados, o modificando useEffect solo para ejecutar después de montar, así que tenemos un div mount que usamos para tener en componentes de vidrio.

Como puedes ver, el código es bastante simple, pero tener que crear una nueva referencia y crear el if cada vez que quieres esta funcionalidad es aburrido, así que simplemente desenganchar y eso es todo.

Otra parte importante es facilitar la vida de nuestros colegas, ocultando toda la complejidad de algunas características para que no tengan que lidiar con ellas. Hay muchas características que tienen implementaciones complejas, como hemos visto allí, especialmente no deberíamos estar escribiendo esas soluciones una y otra vez para poder ocultar esta cantidad de complejidad que ves aquí con un hook que se usa simplemente así.

Vamos a nativo. Pero dijimos, una de las cosas buenas de React Native es que no tienes que preocuparte por los nativos. Simplemente escribes código JavaScript. Pero a veces es necesario ir a nativo. Una de las razones puede ser las limitaciones de recursos. En otras palabras, las razones porque quieres una mejor integración entre la funcionalidad nativa, como las notificaciones push con tu aplicación. ¿Pero por qué no usar las bibliotecas que existen por ahí? En algunos casos no había ninguna. Pero al menos no pudimos encontrar una que cubriera completamente nuestras necesidades. Otra razón es que en nuestro caso era demasiado específico. Y ninguna de las bibliotecas disponibles resolvió el problema de la manera que queríamos. Entonces, ¿qué hicimos? Realmente, encontramos algunas cosas para las que no encontramos ninguna biblioteca. Las creamos. Estas son algunas de las características que necesitábamos. Por ejemplo, EMM. Una forma de asegurarnos de que las sesiones estén separadas cuando se trata de varios servidores. Mejoramos la forma en que manejamos la entrada de texto, o incluso nuestros registros. Todas estas funcionalidades tienen fuertes componentes nativos. Pensamos que todas estas son lo suficientemente generales, así que hicimos bibliotecas de código abierto. Así que todos pueden usarlas si es necesario. Si estás interesado en alguna de ellas, no dudes en visitar nuestro GitHub y las encontrarás allí.

Pero también hay algunas características que no eran lo suficientemente generales. Por ejemplo, las notificaciones push. Teníamos mucha lógica que es específica para nuestro proyecto. Por ejemplo, tenemos algo que llamamos notificaciones cargadas de id. Dado que las notificaciones pasan por los servicios de notificaciones push, puede haber preocupaciones de residencia de data si se envía el contenido del mensaje. Entonces, ¿cómo solucionamos eso? Simplemente enviamos id, y cuando la notificación llega al teléfono, contactamos al servidor para obtener el contenido del mensaje. De esa manera, el mensaje nunca va a un tercero, y el móvil sigue mostrando el contenido del mensaje.

Con las extensiones compartidas, el problema era acerca de las restricciones de memoria. Queríamos hacer demasiado, y todo el marco de React estaba consumiendo demasiada memoria. Así que ir a nativo allí nos permitió hacer todo lo que queríamos.

Y finalmente, también agregamos alguna funcionalidad para poder ir a un estado de dispositivo portátil. No encontramos eso en nuestra biblioteca, así que simplemente lo agregamos.

Sí, eso es todo por hoy. Espero que te haya gustado la charla. Como dije al principio, esto es solo lo que hemos probado hasta ahora que funcionó para nosotros. Si tienes alguna sugerencia o idea, por favor envíamela. Muchas gracias. Y recuerda, si quieres contactarme, solo pasa por la oficina en community.modernmos.com. Muchas gracias.