Voy a pasar ahora a Nohar y Amir de mi equipo. Amir es el líder técnico del equipo de grupo en mi aplicación de Vodafone, y Nohar lidera nuestra capacidad de React Native en nuestro sitio offshore en El Cairo, y Nohar te guiará un poco sobre la arquitectura de la aplicación y específicamente sobre cómo hemos estado utilizando el puenteo para permitir que nuestro código funcione tanto en aplicaciones nativas como en aplicaciones de React Native. Nohar, ¿puedes tomar el control? Así que los tres temas principales de los que vamos a hablar en esta sección son una visión general de la arquitectura de la aplicación, cómo manejamos el puenteo y el viaje de React Native y más allá, de los que te hablaremos. Esperábamos tener un caso de uso de Albania que te guiaría a través del viaje que progresa de la aplicación a la web y cómo compartimos capacidades entre ambas. Así que creo que vamos a pasar directamente a la sección de arquitectura si tienes el control de eso, Nohar. Sí, sí lo tengo. Gracias. Gracias. Gracias, Andrew. Permíteme presentarme. Mi nombre es Nohar Magdy. Soy un líder técnico senior en Voice Egypt y voy a ampliar lo que dijeron Anir y Andrew. Echemos un vistazo más de cerca a uno de nuestros componentes, cómo lo construimos, cuál es la arquitectura y cómo lo construimos de forma modular. Así que tomemos, por ejemplo, un componente ABC y revisemos sus capas y arquitectura. La primera capa es la UI/UX, que se construye a partir de elementos comunes en la base. Entonces, ¿qué es la base? La base es un conjunto de módulos reutilizables y simples que facilitan la construcción de la UI/UX. Son elementos básicos que cumplen con las especificaciones de la interfaz de usuario como módulos, como nuestros campos de texto personalizados, botones, colores, redes básicas, y es una capa muy simple sin lógica ni funcionalidad. Luego, la segunda capa es la lógica de negocio. La lógica de negocio controla el flujo de los componentes y cómo funcionan. Proporcionan los controles y la configuración de soporte que ayudarán a llevar a cabo la lógica de negocio requerida por el componente. Y luego, en la parte superior, verás la aplicación móvil que utiliza este componente enviando la configuración y los datos necesarios para que funcione como se espera. Y como puedes ver, esta arquitectura de componentes reutilizables, cuando se inyecta en una aplicación móvil, resulta en menos tiempo de mantenimiento porque es un conjunto de código reutilizable. Así que tienes una única fuente para solucionar el problema y la vulnerabilidad, lo que definitivamente ahorra más tiempo y produce resultados más eficientes.
Ahora, como somos de código abierto y un código abierto sin hogar y estamos construyendo una biblioteca de componentes utilizables, dependemos mucho de la documentación. Como lo llamamos, es el corazón para compartir nuestro conocimiento. Y lo que hacemos es que siempre agregamos la documentación a nuestro tiempo de desarrollo en lugar de hacerlo al final del desarrollo o incluso peor, como una ocurrencia tardía. Pero nos enfrentamos a un desafío aquí, que el código cambiaba continuamente y teníamos que volver atrás y cambiar la documentación manualmente. Definitivamente, esto resultó en más tiempo necesario. ¿Cómo abordamos este problema? Tenemos nuestro código escrito en JavaScript y hemos agregado una capa de definiciones de tipo utilizando TypeScript. Y, por supuesto, uno de los errores que hay por ahí es que TypeScript y JavaScript no pueden coexistir en un solo proyecto de React Native, lo cual es totalmente falso. Entonces, lo que hemos hecho es utilizar una herramienta llamada Typedoc, que convierte los comentarios en el código TypeScript en un modelo HTML o JSON renderizado. Así que como ejemplo de un archivo Typedoc, que tiene una propiedad llamada nombre, que es una cadena y tiene otra propiedad llamada ejemplo, que como se especifica, es una propiedad opcional y tiene un valor predeterminado de falso, y luego tienes un método o una función en el ejemplo primero, tienes un tipo personalizado, que es un tipo personalizado de ejemplo. Cuando hemos utilizado Typedoc, ¿qué obtenemos? Obtenemos esta hermosa documentación que se extrae y se genera automáticamente a partir del propio código. Como puedes ver, consta de dos partes. La primera parte son las propiedades internas, la segunda parte es el método, y como puedes ver, la documentación se genera a partir del código. Utiliza los comentarios que hemos agregado en el código. También utilizó porque la propiedad de ejemplo, por ejemplo, es una propiedad opcional, por lo que agregó la etiqueta opcional y también porque hemos establecido un valor predeterminado, se agregó la bandera booleana opcional. Luego también dice que esta es una bandera booleana y el valor predeterminado es falso y también es opcional. Como puedes ver, cuando alguien mira esta documentación, de inmediato sabrá que para que este código funcione, necesito enviar la propiedad que se llama tal y tal y qué hace exactamente cada propiedad. Así que lo hizo realmente más fácil para todos los que usan nuestros componentes saber qué se espera para que los componentes funcionen y también porque esta documentación se genera en función del último código generado automáticamente en función del último código que tenemos en producción, esto nos permite acortar el tiempo de mantenimiento que teníamos que hacer para mantener la documentación que tenemos.
Ahora, basándonos en lo que Amir y Amber dijeron, veamos más de cerca cómo construimos y distribuimos nuestros componentes. Empaquetamos nuestros componentes utilizando npm y los distribuimos utilizando jfrog. Entonces, lo que estamos haciendo aquí es instruir a npm para que recupere los paquetes del artefacto jfrog en lugar del valor predeterminado, ya sea su registro npm. Entonces, si el paquete deseado es un paquete privado propio, lo alojamos en el repositorio jfrog, luego se recibirá directamente del repositorio jfrog y se instalará localmente en la carpeta de módulos de nodo. Luego, si el paquete deseado es un paquete público disponible en urn o npm, lo que sucede es que se recupera de allí, se almacena en la caché de jfrog artifactory y luego se instalará localmente en su carpeta de módulos de nodo. Luego, si se solicita nuevamente este paquete en caché, se recuperará automáticamente del repositorio jfrog, no del registro npm o la urn. Ahora, un vistazo más cercano a nuestro pipeline de CI/CD para la parte de integración continua. Tenemos código en la interfaz de Github. Tenemos Jenkins para ejecutar nuestro pipeline. Hemos integrado SonarQube, hemos integrado Jest, ESLint. Definitivamente, estamos usando Visual Studio Code para editar el código y luego, como parte de nuestro pipeline, tenemos muchos mecanismos de prueba agregados allí. Así que tenemos Jest, tenemos Widesource para verificar las vulnerabilidades de seguridad. Tenemos Detox para automatizar la regresión o cualquier escenario de extremo a extremo que tengamos y, por supuesto, si se encuentra algún defecto, lo informamos en JIRA. Luego, para la parte de implementación, como mencioné, alojamos nuestros paquetes en jfrog y tomamos etiquetas en GitHub Enterprise y como parte de la implementación, cuando movemos el código a producción, TypeDoc regenera toda esta documentación para asegurarse de que la documentación siempre esté actualizada con el último código. Ahora, como Andrew mencionó, hemos estado tratando de agregar código de React Native con código nativo y ha sido algo muy exitoso que hemos hecho. Hemos agregado el código de React Native en una aplicación nativa y también hemos agregado código nativo en una aplicación de React Native. Entonces, veamos cómo lo hicimos. Básicamente, para la primera parte, vamos a hablar de cómo agregamos el código nativo en una aplicación de React Native. Tenemos un SDK muy utilizado que mide la velocidad en todas nuestras aplicaciones My Vodafone. Lo que hemos hecho es que, debido a que este es un SDK muy utilizado que la mayoría de los mercados utilizarían, hemos elegido React Native utilizando el módulo nativo y el emisor de eventos nativo. Este SDK interactúa directamente con las capacidades del dispositivo y al envolverlo, definitivamente esto nos permite acortar el tiempo de mantenimiento para este componente muy utilizado. Y el costo de mantener este único componente se redujo en un 60%, lo que significa un gran ahorro de tiempo para nosotros. Ahora, uno de los desafíos que enfrentamos al agregar código nativo en una aplicación de React Native es que queríamos cambiar los modos a modo claro y oscuro y viceversa. Y hemos utilizado el emisor de eventos para manejar este cambio de modo. Entonces, escuchas el código cuando el cambio del código nativo de modo oscuro a modo claro o viceversa. Y en consecuencia, el código de React Native también se comporta. Ahora, ¿qué sigue para nosotros en este tema? Vamos a probar los módulos turbo, que deberían facilitar aún más la comunicación entre JavaScript y el código nativo. Ahora, yendo en la otra dirección, veamos cómo integramos el código de React Native en una aplicación nativa. Básicamente, tomas el código de React Native, ejecutas npm pack, luego obtienes el archivo .tgz, ejecutas el comando de bundle de React Native y luego obtienes el archivo .gs más el recurso. Aquí tienes un ejemplo de uno de los paquetes, aquí tienes un ejemplo de los scripts de cómo ejecutamos un paquete Android para Android. Simplemente ejecutas el comando, el bundle de React Native, dices que el indicador dev es falso y luego especificas dónde exactamente quieres que esté la salida, luego obtienes dos cosas, el archivo .gs y los recursos.
Comments