React a gran escala con Vodafone

Buenos días, tardes o noches, dondequiera que se encuentren en el mundo, y bienvenidos. Estamos muy emocionados de unirnos a la cumbre de React este año y queremos darles la bienvenida a nuestro masterclass sobre Vodafone y cómo utilizan las tecnologías de React a gran escala. Pensé en tomar un minuto para compartir con ustedes un poco de contexto sobre Vodafone para aquellos de ustedes que aún no lo conocen.

Vodafone conecta a las personas en todo el mundo. Estamos presentes en 21 países y 52 mercados asociados. Es posible que no estén acostumbrados a ver a Vodafone y nuestra marca en eventos como este, pero eso ciertamente está cambiando y cambiará. Tenemos grandes ambiciones de transformar nuestra empresa en un proveedor de comunicaciones tecnológicas. Nuestra estrategia tecnológica nos lleva a aumentar nuestro equipo de ingeniería de software en aproximadamente 7,000 personas para 2025. Eso significa que en 2025 tendremos una fuerza laboral de ingeniería de software de alrededor de 16,000 personas. Todos construyendo a nivel mundial y reutilizando en esos 21 mercados en los que operamos. Estamos trabajando en un equipo de tecnología. Estamos en un viaje para trabajar en colaboración y evitar la duplicación para poder ser el equipo más eficiente que podamos ser.

Así que un poco sobre quién soy y por qué estoy lanzando el masterclass. Mi nombre es Jamie Van Hankens. Lidero un nuevo equipo en Vodafone llamado Digital Ventures. Si bien el nombre del equipo no significa mucho, somos responsables de la experiencia de los empleados de nuestros ingenieros de software. Estamos trabajando para implementar cambios que faciliten el trabajo en equipo de nuestros equipos. Si piensan en la defensa del desarrollo, estarán en el camino correcto, pero nuestros planes son empoderar a los desarrolladores distribuidos para construir productos y servicios que sean utilizados por todos nuestros clientes en todo el mundo. Vodafone está muy orgulloso de patrocinar la cumbre de React este año y pronto podrán conocer a nuestro equipo en este masterclass sobre cómo utilizamos la tecnología de React.

También podrán conocer a algunos miembros de nuestro equipo en el evento de React a finales de este mes en Ámsterdam. Enviaremos un grupo bastante grande de nuestros equipos de ingeniería de todo el mundo. Si están allí, no duden en pasar por nuestro stand. Tendremos el stand allí para que puedan hablar con nosotros. También podrán conocer a Spot, el perro robot, que es realmente genial si tienen la oportunidad de verlo y mucho más, así que esperamos verlos allí. Y por último, en cuanto a la introducción de hoy, estamos aquí para compartir nuestra experiencia utilizando React a gran escala en Vodafone. Nuestro equipo les presentará la aplicación My Vodafone. Ese es nuestro punto de contacto digital principal para los clientes y mostraremos su evolución en Vodafone. También les mostraremos algunos principios clave que aplicamos en otros lugares en la web para permitir la co-creación y la reutilización, al tiempo que garantizamos una experiencia de usuario y eficiencia de clase mundial. Hemos reservado algo de tiempo para preguntas y respuestas. No duden en utilizar la función de preguntas y respuestas en cualquier momento en Zoom. Responderemos en el chat y seleccionaremos algunas preguntas para responder en vivo con el grupo cuando lleguemos a eso. Estarán contentos de saber que hay un descanso para tomar café a mitad de camino, así que tendrán 10 minutos para refrescarse y luego pasaremos a la segunda parte. Y por último, si hay algo más que les gustaría saber sobre Vodafone y nuestro viaje de ingeniería de software, tenemos nuestro código QR en la pantalla al que pueden seguir el enlace y los llevará a una de nuestras páginas de destino para que puedan leer más al respecto. También estoy en LinkedIn y también lo están varias personas de nuestro equipo, así que si desean comunicarse con nosotros directamente, no duden en hacerlo. Pero creo que en cuanto a la introducción, eso es todo. Probablemente ya han escuchado suficiente de mí por ahora. Así que le cederé la palabra a Andrew para que los guíe en el siguiente paso.

Andrew, te cedo la palabra. Gracias, Jamie. Bien, déjame tomar el control de las diapositivas. Muy bien, mi nombre es Andrew Ferguson. Siguiendo lo que dijo Jamie, en realidad trabajo en lo que llamamos la organización del grupo. Tengo un rol global que abarca todos los diferentes mercados de los que habló Jamie. Mi equipo se enfoca en dos cosas. Por un lado, tenemos un rol en torno a la analítica digital y el marketing. Por otro lado, se trata de la aplicación My Vodafone. Eso es de lo que vamos a hablar hoy en la primera sección. Luego, a medida que avanzamos en las secciones web un poco más abajo con Pedro y su equipo, probablemente comenzarán a ver algunas sinergias entre el desarrollo de aplicaciones y el desarrollo web. Así que, la tecnología React Native y la historia de JS que Pedro y su equipo cubrirán más adelante. Una pequeña disculpa. Desafortunadamente, debido a razones personales, el equipo de Albania no pudo unirse a nosotros hoy, pero iban a hablar un poco sobre cómo estamos pasando del desarrollo en React Native y desarrollo nativo puro a un entorno más tipo aplicación web progresiva. Por lo tanto, llevando parte del código que estamos construyendo en React Native, trasladándolo a una experiencia de escritorio web y avanzando hacia una experiencia completa de aplicación web progresiva. Intentaremos retomar esos temas más adelante durante la conferencia y otras sesiones, y trataremos de mencionarlos a medida que avancemos. Solo voy a darles una breve introducción. Jamie estableció el escenario sobre quién es Vodafone, dónde operamos y algunos de los impulsores. Solo quería retomar algunos de esos puntos y hablar específicamente sobre qué es la aplicación My Vodafone. ¿Por qué estamos tan orgullosos de ella? Y luego pasar a explicar cómo está cambiando la aplicación My Vodafone desde una perspectiva tecnológica, y igualmente, cómo estamos comenzando a utilizar React Native para ayudarnos en ese viaje de transformación hacia una forma de desarrollo más eficiente, compartida y no repetida. Así que en una fuente, etcétera.

De acuerdo, desde el punto de vista del cliente, la aplicación myVodafone, como dijo Jamie, es nuestro principal punto de contacto digital. Es la forma más utilizada de interacción que tenemos con nuestros clientes, para que se autogestionen e interactúen con Vodafone. Está disponible en nuestros 19 mercados.

Entonces, Jamie mencionó 21 mercados. Tenemos dos empresas conjuntas. Por lo tanto, los 19 mercados de propiedad total de Vodafone en los que operamos, todos tienen una aplicación myVodafone en Play Store y Google Store. Y esas aplicaciones están allí para que los clientes interactúen. Desde una perspectiva histórica, se centraba principalmente en el cuidado. Facturación, uso y recorridos de autogestión. Los clientes querían interactuar, verificar su factura, pagarla y esas cosas. Pero en los últimos años, ha crecido mucho más, ya que las ofertas de servicios de Vodafone han crecido, como banda ancha fija, etc.

Y, a medida que ahora nos adentramos en nuevos servicios de valor agregado. Entonces, en los 19 mercados de Vodafone que tenemos, la aplicación se ha convertido en una propuesta más convergente. Si bien tenemos una referencia de diseño común, el aspecto y la sensación, el modelo de interacción, la marca, todas las cosas que esperarías que sean iguales. Si descargas la aplicación de Albania y la aplicación de Irlanda, se ven más o menos iguales. Pero en realidad, lo que ves dentro de esas aplicaciones es muy diferente. Están adaptadas a las necesidades del mercado local. Tenemos ciertos mercados. Italia es un mercado muy prepago. Entonces, lo que necesitan ofrecer en términos de recorridos dentro de su aplicación se centra mucho en la recarga de pago, verificar el saldo, ver por adelantado. ¿De acuerdo? Mientras que otros mercados, que se centran más en las ofertas convergentes, tienen un conjunto de recorridos adaptados muy diferentes. Igualmente, en un mercado como Turquía, ahora se está convirtiendo en el Amazon de Turquía y ofrece un mercado donde puedes comprar desde comestibles hasta bienes físicos. ¿De acuerdo? Tenemos 19 mercados. Una referencia de diseño común que abarca todos ellos para mantener la coherencia de la marca. Pero tenemos que reconocer que cada mercado tiene un conjunto de clientes muy diferente. Y por lo tanto, las ofertas, características y recorridos que obtienes en esos mercados son muy diferentes. ¿De acuerdo?

En cuanto a las características, están evolucionando mucho. Entonces, como dije, solíamos centrarnos mucho en ¿cuál es mi factura? ¿Cuál es mi uso? ¿Cómo pago? Tipo de recorridos. Ahora estamos entrando en una personalización mucho mayor. Tratando de hacer que los clientes vuelvan a la aplicación con más frecuencia. Tenemos necesidades en evolución en torno a pasar de SIEM físico a SIEM electrónico a autoaprovisionamiento. Queremos realizar la compra completa y los recorridos de adquisición y de incorporación con nuevos clientes. Y también estamos buscando otros servicios de valor agregado. Cosas como seguros, contenido, el mercado, lealtad y recompensas. Por lo tanto, el conjunto de características está creciendo mucho más allá del cuidado y el uso. ¿De acuerdo? Es un punto de contacto principal y está en constante crecimiento y es diferente en cada mercado. ¿De acuerdo? Desde una perspectiva tecnológica... Oh, Jamie, es posible que tengas que ayudarme con la página siguiente, ¿de acuerdo? Estoy de vuelta, ahí vamos. Oh, te falta una diapositiva, Jamie. Desde un punto de vista interno, lo que eso significa para nosotros en cuanto a cómo entregamos la aplicación es algo a tener en cuenta. Dos segundos. Solo necesito encontrar mi diapositiva. De acuerdo. Entonces, desde un punto de vista técnico, lo que esto significa para nosotros es que hoy tenemos 19 aplicaciones de mercado únicas, ¿de acuerdo? Entonces, cada mercado tiene su propia aplicación en su propia tienda de aplicaciones. Y esas aplicaciones han crecido a partir de los equipos locales. Y lo que hemos estado haciendo es buscar cómo comenzar a estandarizar la implementación de esas aplicaciones, ¿de acuerdo? Las aplicaciones están escritas en una variedad de lenguajes, tanto nativos, como Kotlin y Swift, principalmente. Y ahora, cada vez más, estamos comenzando a ver React Native también. De los 19 mercados que tenemos, actualmente tenemos cuatro mercados en vivo con React Native, tres mercados más que se están trasladando a React Native y el resto sigue utilizando implementaciones de aplicaciones nativas. Por lo tanto, tenemos un panorama muy diverso en términos de tecnología y las implementaciones de aplicaciones. Igualmente, a medida que esos mercados sirven recorridos para sus clientes locales, hay algunas variaciones en términos de herramientas, STK y aplicaciones de terceros que esos mercados utilizan dentro de su aplicación. Por lo tanto, hay una cierta divergencia en términos de algunas pasarelas de pago de terceros y servicios de pago. Igualmente, tenemos cierta estandarización en torno a la analítica y esas cosas. Por lo tanto, tenemos una variedad de STK incluidos en esos. Y luego, lo que hemos estado haciendo en términos de cómo comenzamos a impulsar una mayor estandarización en esos mercados es comenzar a mirar el inner sourcing. Entonces, con el equipo central, hemos estado trabajando en la estandarización de la implementación de la aplicación. Colaborando con los diferentes equipos de mercado para establecer estándares comunes para la implementación de la aplicación. Impulsando el intercambio de código, para que podamos comenzar a compartir no solo ideas, sino también código físico. Y comenzar a ayudar a los mercados en sus recorridos desde las implementaciones principales hasta React. Tenemos un catálogo de recorridos en el repositorio RGTHUB y trabajamos con los mercados para construirlos de manera colaborativa, eliminando la duplicación, para construir cosas una vez cuando sea posible. Por lo tanto, una versión de facturación que todos los mercados pueden tomar y usar, y luego promovemos esos mercados, ampliando esos recorridos a través de un enfoque de inner source o código abierto dentro de Vodafone. También hemos estado trabajando muy de cerca con los mercados que están pasando de tecnologías nativas a tecnologías React Native. Para nosotros, la clave en torno a React es obtener algunas eficiencias, por lo que en última instancia, construir una vez en lugar de construir dos veces con React. Y lo que estamos tratando de hacer es comenzar a ayudar a aprender a cambiar las habilidades dentro de los mercados y brindar más apoyo para cómo pasan de un desarrollo nativo a un desarrollo React Native. Hemos estado promoviendo versiones de código de React. Más adelante en la sesión, conoceremos a alguien que hablará sobre el puente, que es cómo hacemos que el código React Native funcione dentro de una aplicación nativa y, en general, tratamos de lograr eficiencias en todos los mercados. Vamos a la parte de React Native, aquí vamos. De acuerdo, desde una perspectiva de React Native, dije que ya hay cuatro mercados en React. Tres más se están trasladando de los 19 mercados que tenemos. En general, el objetivo principal que buscamos dentro de Vodafone es mejorar la experiencia mientras reducimos el esfuerzo para llevar los recorridos al mercado. ¿De acuerdo? Detener la duplicación, mejorar los plazos de desarrollo y también ayudar con el ciclo de vida continuo para la gestión y mantenibilidad del código una vez entregado, ¿de acuerdo? Con React Native, hemos visto que la promesa se cumple, que en lugar de construir las cosas dos veces, se construye una vez y funciona en ambos conjuntos.

Y aunque no obtenemos, como probablemente sepas, la funcionalidad completa, ahorra el 50% de tu tiempo porque tienes que ajustar el código de React para que siga funcionando dentro de las bibliotecas y limitaciones nativas y también dentro de los SDK con los que trabajamos. Hemos visto grandes eficiencias a través de la construcción única utilizando React Native. Igualmente, en términos de estandarización, tener una única base de código y una base de código moderna como React nos ha ayudado enormemente a comenzar a eliminar parte de la herencia que teníamos antes.

Entonces, ahora comenzaré a hablar un poco sobre nuestro pipeline y las herramientas que usamos, los frameworks que usamos dentro del espacio de React Native. El conjunto de código de React Native nos ha ayudado mucho a comenzar a estandarizar y brindar un entorno más nuevo para que nuestros desarrolladores trabajen. Y ciertamente, al comparar React con algunos de los lenguajes de codificación nativos que usamos, hemos visto grandes eficiencias y beneficios al poder hacer esa estandarización más rápido sin tanto legado detrás de nosotros.

El enlace a los canales más amplios. Entonces, hemos comenzado a utilizar el código que construimos en React Native para nuestros canales web nativos. Para la experiencia web de escritorio. Por lo tanto, los recorridos que hemos construido para servir en la web se han trasladado también a los recorridos web y estamos trabajando con nuestros equipos de desarrollo web para tratar de eliminar dependencias y duplicaciones, no solo dentro del espacio de la aplicación, sino también dentro del espacio más amplio de la aplicación y la web y los otros canales que servimos. Y como dije con Albania, ya estamos comenzando a pasar a aplicaciones web progresivas. Por lo tanto, pasando de una perspectiva de estandarización nativa, a la web y la aplicación, y finalmente a la aplicación web progresiva. Con todo esto, hemos tenido algunos desafíos.

Vale, entonces la transición de habilidades, hemos estado analizando cómo podemos llevar a nuestros desarrolladores con nosotros en términos de habilidades al pasar de su base de código nativo, donde todos nuestros mercados comenzaron, al conjunto de código y habilidades de React Native que necesitamos. Hemos tenido programas de reentrenamiento y también hemos incorporado a nuevas personas. Es justo decir que en algunos mercados hemos tenido más desafíos que en otros para encontrar desarrolladores capacitados en React Native, pero la transición de habilidades ha sido bastante efectiva gracias al trabajo que hemos estado realizando con nuestro centro de servicios compartidos en Egipto y otros mercados. Por lo tanto, la transición de habilidades es algo que hemos tenido que tener en cuenta. Ha causado algunos desafíos, pero igualmente creo que estamos avanzando. El último punto sobre la transición de habilidades es que también hemos mantenido a nuestros desarrolladores nativos, por lo que todavía necesitamos tener un buen entendimiento del conjunto de código nativo, las interacciones con Android e iOS para asegurarnos de que los SDK funcionen, de interactuar con el sistema operativo de manera adecuada y de empaquetar el código de React Native en consecuencia. Por lo tanto, ampliándolo un poco para trabajar con esos dos tipos de dispositivos con sistemas operativos ligeramente diferentes.

Desde una perspectiva de rendimiento, hubo cierta preocupación en ciertos mercados sobre el tamaño de las aplicaciones de React Native en comparación con las equivalentes nativas. Hemos realizado mucho trabajo para optimizar el código a través de los frameworks que utilizamos y mediante los métodos y pautas de desarrollo que proporcionamos y promovemos. No hemos tenido ningún problema real de rendimiento. Creo que esto es algo que ha sido más un temor de los mercados que aún no habían comenzado el viaje de React, pero basándonos en los mercados que se han trasladado a React Native y las comunidades que hemos establecido, hemos podido encontrar algunas optimizaciones para las aplicaciones de React Native y no se han observado problemas de rendimiento. Igualmente, en cuanto al enfoque de transición, hemos comenzado a utilizar el puenteo, que NoHel les explicará en breve, que es nuestra forma de asegurarnos de que el código de React Native que construimos también pueda ejecutarse en una aplicación nativa. Así que en lugar de tener que construir una versión de React Native para los mercados de React y versiones nativas para todos los demás, ahora hemos comenzado a construir componentes con los mercados para que construyamos solo en React y a través del uso del puenteo nos aseguramos de que esos recorridos y código puedan funcionar también en una aplicación nativa. Eso nos ayuda a que esos mercados que aún no se desarrollan completamente en React Native se acostumbren al código, a los frameworks que utilizamos y a obtener ese entendimiento para que puedan tomar una decisión sobre su camino hacia React en el futuro. Igualmente, desde nuestro lado, al mantener el código en todos los mercados, tener una única versión de código de React utilizado de manera consistente en todos los mercados significa que nuestros procesos de soporte son un poco más simples y fáciles.

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.

Estos dos archivos se agregan en cualquier aplicación nativa y obtendrás código de React Native en una aplicación nativa de inmediato. Ahora, un desafío adicional que enfrentamos en ese caso, que es el código de React Native en una aplicación nativa, es que teníamos la situación en la que queríamos pasar una vista completa de la aplicación nativa a los módulos de React Native, y lo hemos logrado utilizando los componentes nativos requeridos. Cuando agregas esta pequeña etiqueta encima de cualquier componente al describirlo en el código, esto significa que esta vista se puede pasar entre el código nativo y el código de React Native. Como puedes ver, es muy sencillo, definitivamente ahorra más tiempo, los errores se solucionan en un solo lugar y la eficiencia realmente aumenta. Espero que todos estén de acuerdo conmigo, gracias.

Y volviendo a Jamie para las partes de preguntas y el descanso para tomar café. Yo lo preguntaré en su lugar. Entonces, la pregunta de Peter es, ¿qué diseño de repositorio se está utilizando, Mono o Poly u otro? No sé si alguien podría responder eso por Peter. Así que puedo intentarlo. En este momento no utilizamos una configuración de repositorio único. Definitivamente es algo que estamos explorando actualmente en términos de cómo podemos estructurar un proyecto para poder utilizar un repositorio único, cómo podemos detectar dónde se están realizando cambios en ese repositorio único y activar un pipeline de compilación en función de eso. En este momento tenemos un repositorio por componente, efectivamente, por función. Entonces, en las diapositivas que cubrió Noha, habrá un repositorio para inicio de sesión, otro para incorporación, facturación. Para cada función específica, tenemos un repositorio y tenemos un pipeline de compilación asociado con eso. Esa es la configuración actual que tenemos en términos de herramientas, la principal herramienta que utilizamos en nuestros flujos de trabajo y pipelines de CI es Jenkins. Tenemos mucha automatización dentro del flujo de trabajo, tenemos muchos scripts que se ejecutan para facilitar cualquier cosa que se haga manualmente, mantener el código actualizado, enviar el código entre diferentes ramas. Entonces, tenemos una configuración bastante avanzada en términos de CI y estructura, pero actualmente estamos investigando los conceptos de repositorio único para ver cómo se aplicarían a nosotros y cómo los administraríamos en toda la organización. Genial. Gracias. Y hubo otra pregunta en el chat que probablemente podamos responder aquí de David. Y David pregunta, si se apunta a múltiples SDK o compilaciones de dispositivos en diferentes mercados, ¿cómo se alinean con los códigos compartidos que la API está disponible en función de cada dispositivo? Dice que esto es obviamente un problema mayor en el lado de Android, más que en iOS. No sé si tú, Neha o Emir, quisieran comentar sobre eso. Neha, ¿quieres encargarte de eso, o tenemos que pensarlo fuera de línea y volver con una respuesta escrita, creo? Sí, sí, déjame responder en el chat, David. Genial. De acuerdo. Tomaré nota de la pregunta y se la enviaré a Neha para que podamos tratarla después. Y solo una más que podemos responder antes del descanso para tomar café. Si está bien, antes del descanso para tomar café. Entonces, Pizza tiene otra pregunta, que es si hay alguna API para consumir una solución de contrato que se esté utilizando. Por supuesto, si no es así, ¿GraphQL, si no, qué? ¿Quieres que responda esta, Amir? Sí, claro. Sí, en términos de la interfaz con los mercados, sí, hay una estandarización de las API en el backend, tanto en términos del contrato de la API como del modelo de datos que se promueve en los mercados de Vodafone, cumpliendo con el estándar TMF, el estándar abierto de la Telco Management Forum para las API. Entonces, sí, estamos promoviendo la estandarización de las API desde una perspectiva de facturación del mercado, exposición de datos del cliente. Igualmente, dentro de la aplicación que tenemos, admitimos un cierto nivel de abstracción en la API para poder adaptarnos a las variantes de API por mercado también. Amir, Noha, ¿algo más que agregar? No, creo que eso cubre todos los puntos en términos de que intentamos promover la estandarización en los mercados, obviamente cada mercado tiene un backend diferente y una configuración diferente. Entonces, hay algunos desafíos para alinear los contratos de API, pero desde una perspectiva de front-end, intentamos abstraer el contrato de API de la implementación en el front-end. Por lo tanto, hay una capa intermedia para mapear la respuesta de la API a lo que el front-end necesita, lo que permite, obviamente, conectar diferentes backends y un nivel de abstracción, que es realmente clave en este modelo. Sí, exactamente, como mencionaste, Emir. Básicamente, nuestros componentes están construidos de tal manera que esperan ciertos datos. ¿De dónde vienen estos datos? Realmente no les importa y no se preocupan por dónde vienen los datos. Entonces, ya sea una API, una base de datos local, un archivo JSON seguro, en cualquier lugar, los componentes simplemente esperan ciertos datos y quieren que lleguen de cierta manera, y eso es todo. Y como mencionó Emir, estamos integrando algunos de nuestros componentes con algún backend. Pero nuevamente, debido a que cada mercado tiene un backend diferente, también tenemos la capa de mapeo, que es totalmente anulada por cualquiera de las aplicaciones móviles que se utilizan.

Entonces, si quieres usar nuestra capa de mapeo, que mapea la respuesta de la API a nuestros componentes, puedes hacerlo. Si tienes un backend diferente, puedes anular esta capa de mapeo y escribir tu propia capa de mapeo. Genial. De acuerdo. Gracias. Creo que solo hay una pregunta más que acaba de llegar de Jamie. Basándonos en la pregunta de Peter, ¿qué herramienta utilizas para mapear la respuesta? ¿Es algo personalizado, GraphQL u otra cosa? No, no utilizamos GraphQL. No... No, no, no. No lo utilizamos. Sí. Bueno, es solo codificación web. Básicamente, esperamos que la respuesta de la API esté en cierta forma, y luego la mapeamos para que se ajuste al componente de URL, los data que esperan estar en cierta forma. Así que no usamos GraphQL. Sí. Y creo que solo para la respuesta de David en la sesión de preguntas y respuestas. Y eso es correcto. David, ese es exactamente el enfoque que tomamos en términos de construir componentes flexibles para permitir que los mercados tengan un enfoque flexible en términos de integración, ya sea contra un backend específico y una API compartida o contra múltiples APIs en su lado. Por lo tanto, esa flexibilidad es clave para poder admitir múltiples mercados con enfoques diferentes.

Buenas tardes a todos. Soy Pedro Galán, gerente de ingeniería digital en Vodafone España para WebCMS e ID de Negocio. También soy miembro del Capítulo Web Global en Vodafone. En primer lugar, gracias por unirse. Es un gran placer para nosotros y un honor que hayan elegido esta masterclass y que estén aquí con nosotros.

Como pueden ver en la agenda, vamos a hablar sobre web y Vodafone. Lo haremos en tres bloques principales. El primero es una visión general de cómo Vodafone gestiona el desarrollo web en React. El segundo bloque será una sección en la que explicaremos un conjunto de bloques de construcción técnica que ya tenemos en Vodafone, realmente interesantes. Y finalmente, pasaremos a una sección que llamamos React en la Vida Real en Vodafone, donde mostraremos algunos de nuestros principales proyectos.

Así que vamos a la visión general. En términos de visión general, no quiero darles una introducción técnica o algo así. Mi objetivo es darles una visión general realmente breve porque más adelante mis colegas entrarán en detalles técnicos. Pero creemos que puede ser realmente útil que comprendan las circunstancias particulares, los desafíos, los requisitos y los objetivos que tenemos como empresa multinacional con un enfoque especial en nuestros canales digitales. Y en este momento, particularmente en nuestro canal web como el canal más poderoso en términos de ventas. Esto es realmente importante para nosotros.

Entonces, comencemos con un poco de información de antecedentes. Como mencioné antes, es realmente útil comprender nuestro punto de partida y nuestras necesidades. En Vodafone, tenemos excelentes equipos humanos con brillantes ingenieros de software. Tenemos muchos proyectos y soluciones técnicas en Vodafone. Nuestro gran tamaño nos brinda grandes capacidades humanas y técnicas, pero al mismo tiempo, esto ha provocado que tengamos diferentes marcos y también capacidades similares construidas en varios países. En este punto, la conclusión y la idea son muy claras. Aprovechemos todo este poder y enfoquémonos en una estrategia común, teniendo objetivos comunes que nos permitan ser más eficientes, más productivos, más colaborativos y enriquecernos mutuamente.

Entonces, como resumen, eso significa que no queremos tener más software construido de forma aislada, por lo que queremos construir una vez y reutilizar muchas veces. Esto es algo fácil de decir, pero no es fácil de promover, créanme, porque estamos en este proceso. ¿Cómo podemos aprovechar todas las cosas que ya tenemos? En primer lugar, claramente necesitábamos un conjunto de fundamentos para compartir y reutilizar, que son los más importantes para nosotros. Desde nuestro punto de vista, hay tres: tener un marco común, en este caso, React, esto es obvio; tener inner source, por lo que queremos construir en lugar de comprar; y necesitamos tener una base sólida de estándares. Si trabajamos de la misma manera, será fácil encontrar y reutilizar en el futuro.

La reutilización es realmente buena, pero también estamos teniendo en cuenta un punto importante que suele ser una preocupación para nuestros equipos técnicos y comerciales. Y esto es permitir cierta flexibilidad para la creatividad y la innovación. Nuestra ambición no es tener un modelo de entrega centralizado y pesado, y queremos reutilizar, pero también tener un espacio para la innovación y la creatividad. Tenemos los activos, tenemos nuestros principales fundamentos. ¿Dónde estamos ahora? Como dije antes, elegimos React como nuestro marco común y global, y tenemos un capítulo web global en su lugar con un claro objetivo, que es, por supuesto, impulsar la reutilización. Este es el primer objetivo inicial. Por esa razón, creamos un manifiesto web global donde estamos definiendo nuestros principales principios para reutilizar y co-crear. Por supuesto, la adopción de estos principios en una organización tan grande como Vodafone implica desafíos técnicos que explicaremos un poco más adelante. ¿De acuerdo?

Entonces... Perdón. ¿Por qué elegimos React? No quiero explicar todos los beneficios que React proporciona. No queremos hacer una especie de referencia porque seguramente ya conocen esta información. Nuestro propósito es simplemente resaltar tres de ellos que son realmente importantes para nosotros. En primer lugar, el rendimiento. React permite obtener un excelente rendimiento reforzado por el enfoque de MicroFrontend, y este enfoque está incluido en nuestra arquitectura web única y, como saben, el rendimiento es un factor clave para CO, experiencia del usuario, CRO y varias cosas que son realmente importantes para nosotros y para nuestros clientes. El segundo, realmente importante, es la curva de aprendizaje. Estamos planeando contratar un número importante de ingenieros de software como parte de nuestro plan Tech 2025. La curva de aprendizaje es un punto crucial para nosotros. Y finalmente, la adopción del marco. React ya era el marco más adoptado en diferentes mercados y ya tenemos algunos activos importantes como nuestra fuente de valor, que mostraremos más adelante. Por otro lado, las sinergias y la reutilización entre las SDAs para web y ser nativo para móvil, como ya explicamos antes en la sección de la aplicación, también son realmente relevantes para nosotros. Como les dije antes, tenemos un capítulo web global y creamos un manifiesto web. El manifiesto web es uno de nuestros pilares porque para reutilizar y ser geniales, debemos tener las mismas reglas, la misma forma de trabajar. Deberíamos pensar en compartir desde el principio, esta debería ser la razón y el propósito principal cuando comenzamos a construir algo. Deberíamos pensar en compartir desde el principio de nuestros desarrollos. El segundo es el inner source. Desde nuestro punto de vista, esta es la mejor estrategia para trabajar y colaborar de manera más efectiva. Un equipo de desarrollo que trabaja como un solo equipo es mucho más poderoso que una colección de individuos aislados. Y finalmente, los estándares como códigos. Buscamos compromiso, hechos y acciones. Eso significa que no queremos tener solo documentos y nada más que eso. Solo los documentos no son suficientes. Necesitamos acciones y hechos, como dije antes. Tenemos los principios, pero también tenemos habilitadores para facilitar la adopción. Nuestro Manifiesto Web debería ser fácil de adoptar porque si estamos impulsando la adopción global, debemos facilitarlo siendo realmente pragmáticos y realistas en el alcance. Y como el desarrollo web no es una pieza aislada en nuestras aplicaciones de extremo a extremo, debemos estar completamente alineados y coordinados con el resto de nuestros capítulos, DevOps, UX, UI y backends. Esto es crucial para nosotros. La biblioteca de software. Mencioné antes esta biblioteca, hablaremos más adelante sobre eso, pero esta es la piedra angular para reutilizar y crear.

Este es un muy buen ejemplo de los activos actuales que ya tenemos en Vodafone. Tenemos nuestros probadores dedicados para esta biblioteca, dirigidos por David Blaketon. Esto es realmente importante para nosotros. Y finalmente, la hoja de ruta y los proyectos en desarrollo. Conocer la hoja de ruta de los diferentes mercados de Vodafone es imprescindible. Pero, ¿cómo podemos compartir y co-crear si no conocemos la hoja de ruta y las capacidades que vamos a construir juntos? Esto sería imposible. Por lo tanto, es realmente importante conocer la hoja de ruta, leerla con anticipación, co-crear y reutilizar.

Y finalmente, nuestro tercer punto importante son los estándares de desarrollo. Nuestros estándares se dividen en tres categorías principales: prácticas generales de desarrollo de código, estándares de codificación de front-end web y arquitectura de aplicaciones. Es realmente importante tener un estándar, pero también es muy importante tener cierta flexibilidad. Por esa razón, todos nuestros estándares se consideran fijos, flexibles o libres. ¿Qué significa esto? Fijo es algo que debes adoptar si quieres cumplir con los criterios de los estándares. Flex es algo que se recomienda encarecidamente y debes tenerlo en cuenta. Lo siento, creo que puedes ignorar eso. Lo siento, Pedro, continúa. No te preocupes. Estaba a punto de decir que libre es algo que se recomienda, pero no es el fin del mundo si no lo haces. De acuerdo. Esos son los pilares principales de nuestro manifiesto web.

Entonces, vayamos a los estándares de desarrollo con más detalle. En aras del tiempo, porque estoy seguro de que están más interesados en los casos de uso que mostraremos más adelante. Permítanme mencionar algunos ejemplos de nuestros estándares para que puedan tener una idea de cómo los estamos gestionando. En cuanto a las prácticas generales, destaco la colaboración entre los capítulos, que es realmente importante, y también la ciberseguridad. Nuestra aplicación debe estar asegurada por diseño y los requisitos de seguridad deben ser respaldados por herramientas de seguridad automatizadas. Desde el punto de vista de la arquitectura, mantendré esto en nuestra biblioteca de software, como mencioné antes, y hablando de los estándares, aparte de la versión, que es realmente importante, leer y escribir versiones, también es importante destacar que tenemos plantillas para crear diferentes tipos de fronteras según el caso de uso que necesitemos. También incluimos en nuestros estándares la gestión de estado con Redux, y proponemos la arquitectura de micro front-end, pero como un estándar flexible, no fijo en este caso.

Entonces, y ahora, ¿dónde estamos, qué estamos buscando? Esto es como tratar de resumir lo que tenemos y hacia dónde seguiremos en el ejemplo de una casa. Los cimientos son los activos y capacidades que ya tenemos, nuestra comunidad de desarrollo realmente poderosa, nuestro marco común que es React, nuestros estándares y nuestro manifiesto web, que incluye todos nuestros proyectos y activos locales y globales. Y, por supuesto, nuestros bloques de construcción técnicos ya están en su lugar. Por cierto, nuestros bloques de construcción técnicos son realmente interesantes. Serán presentados más adelante. Sobre nuestros cimientos, tenemos los pilares para aprovecharlos con el propósito de trabajar como un gran equipo y ser más eficientes. Debemos adoptar nuestros estándares globales en los mercados, debemos tener la mentalidad de construir para compartir primero. Por supuesto, todos los nuevos desarrollos deben basarse en nuestro manifiesto web. Y como mencioné antes, debemos tener una idea clara y alineación en la hoja de ruta, en los diferentes mercados de Vodafone. Finalmente, en la casa de la regla, tenemos nuestro propósito, nuestro objetivo o en otras palabras, los beneficios que buscamos. Y esos son aumentar la calidad, reducir el tiempo de comercialización. Y debido a la reducción, podemos tener economías de escala, por lo que ahorramos mucho tiempo y costos. Y si queremos tener los estándares adecuados en nuestros propósitos, la reutilización es realmente más fácil en diferentes canales y mercados. Tener una reutilización adecuada alcanzará una economía de escala y aumentaremos nuestra calidad reduciendo nuestro tiempo de comercialización. Esta no es una tarea fácil, por lo que también enfrentamos algunos desafíos técnicos en el camino para lograr nuestra visión. Explicaré en la siguiente diapositiva nuestros principales desafíos técnicos. Lo siento. Tenemos tres desafíos técnicos principales. El primero, el más importante, son los diferentes marcos de desarrollo en Vodafone. Los mercados de Vodafone utilizan diferentes marcos de JavaScript, Angular, React o incluso Vue. Y esto limita la reutilización en el equipo de ingeniería web. Durante este taller, les mostraremos nuestra solución técnica basada en micro front-ends para la coexistencia de recorridos de Angular y React en una aplicación heredada de Angular. Esto es realmente interesante. El segundo desafío para nosotros es la coexistencia de desarrollos heredados y nuevos. Porque cuando hablamos de herencia, no se trata solo de diferentes marcos. También se trata de todo el código fuente o todos los diseños de UX/UI que no están alineados con nuestro manifiesto web y nuestros estándares. Nuestro compromiso de adopción es que todos los nuevos desarrollos deben seguir nuestros estándares globales. Pero, ¿qué pasa con los desarrollos heredados? Se pueden actualizar, pero siempre será opcional porque no queremos afectar la hoja de ruta del negocio. Y finalmente, el tercer desafío técnico que tenemos es la alineación de UX/UI. Como saben, los diseños de UX/UI son el punto de partida del desarrollo web. Y a veces esos diseños no se basan en estándares locales y esto también limita la reutilización y la estandarización. Por lo tanto, un punto clave para nosotros es tener un compromiso claro de las unidades de negocio para tener un diseño común, tener pautas de diseño comunes y adoptarlas, porque si no tenemos el UX/UI común, reutilizar ese componente de desarrollo de software será imposible. Y ahora le paso la palabra a Sam para que explique nuestros bloques de construcción técnicos. Gracias. Gracias, Pedro, intentando tomar el control rápidamente. Oh, aquí está. Ahí vamos. Hola a todos. Soy Sam Wenger, y soy un líder técnico de desarrollo en Vodafone Business IT. Voy a hablar un poco sobre los bloques de construcción técnicos que utilizamos cuando construimos aplicaciones React.

Así que hemos estado en un viaje en los últimos años. Hace un tiempo, cada equipo se centraba en ser el mejor en sí mismo y trabajar no exactamente en silos, pero centrados solo en sí mismos. Todos nos esforzábamos por utilizar las mejores herramientas y procesos para escribir el mejor código de React posible, pero no nos preocupábamos por lo que los demás estaban haciendo. Todo estaba muy aislado. Nos dimos cuenta de que este no es un modelo escalable. Ahora buscamos construir para compartir primero. Queremos que todos hablen el mismo lenguaje cuando se trata de React y los equipos deberían poder compartir su código entre ellos y cualquiera debería poder entender qué está sucediendo.

Para lograr esto, hemos creado tres entregables clave en los últimos años. Han surgido de forma natural y orgánica. Estos son algunos iniciadores de aplicaciones, constructores de aplicaciones y bibliotecas de componentes. Comenzamos queriendo tener un código y estándares consistentes. Como cualquier equipo, creamos nuestros propios estándares inicialmente y los codificamos en un sitio de documentación. Utilizamos Docasaurus, una de nuestras tecnologías favoritas para sitios de documentación. Nos gusta que toda nuestra configuración se base en el formato readme. Esto significa que podemos copiar y pegar el código entre nuestras aplicaciones nativas y también incluir documentación en las aplicaciones para los estándares. Además, es muy fácil agregar más documentación cuando sea necesario. Creamos esto y queríamos compartirlo con los demás. Primero, intentamos construirlo correctamente. Nos aseguramos de tener reglas de linting, las herramientas que usamos, como ESLint, Prettier, commitlint, Husky, Jest, todas esas cosas buenas para asegurarnos de que nuestro código sea de la mejor calidad posible. Y queríamos compartir eso con otros equipos. Como mencionó Pedro hace un minuto, decidimos hablar con otros equipos y juntarnos para hacer un manifiesto. Esto fue básicamente un acuerdo entre tantos equipos como pudimos reunir para definir estándares. Es algo así como un nivel por encima de los estándares de codificación reales, pero haciendo referencia a ellos para trabajar en la codificación de una aplicación React y cualquier otra aplicación en realidad. Acordamos cosas como cómo construir tu código, cómo intentar hacer que las cosas sean abstractas para que se puedan compartir, cómo sincronizar con otros equipos. Creamos un gremio de desarrollo front-end para invitar a cualquiera a venir y compartir lo que están haciendo y cómo están trabajando para que todos podamos colaborar juntos. Y luego cosas más obvias como algunas de las herramientas que usamos. En nuestras canalizaciones, intentamos utilizar cosas como Lighthouse para la accesibilidad y SonarQube y Whitesauce para la calidad del código y la seguridad. Nuevamente, intentamos que las personas se alineen en estas herramientas. Así que incluimos todo eso en los estándares. Ahora, no queríamos dictar a los equipos cómo trabajar. Era bastante importante que esto fuera algo que hiciera la vida de todos más fácil y mejor en lugar de que un solo equipo viniera y dijera: así es como debes trabajar, porque sabíamos que la gente se rebelaría contra eso.

Entonces, una de las cosas que comenzamos a construir fueron los esqueletos de aplicaciones. Estos son simplemente proyectos de inicio de aplicaciones estándar que cualquier líder o desarrollador senior debe crear al comienzo de un proyecto de todos modos. Es solo la estructura básica de código lista para que cualquier miembro del equipo la use. Incorporamos en eso tantos estándares como pudimos. Ya tiene cosas como nuestros ganchos de Husky en confirmaciones y envíos, configuración de jest, configuración de ESLint y Prettier. Todas esas cosas buenas se incluyen desde el principio. También agregamos cosas como archivos Docker con configuración de seguridad adecuada dentro de Docker porque no todos los equipos saben cómo usar contenedores y sí, todas las configuraciones y cosas que pudimos incluir las incluimos. Esto fue bastante útil para que los equipos lo tomaran y lo revisaran. Es solo un repositorio de GitHub como una plantilla. Cualquiera puede clonarlo en su propio repositorio, pero decidimos llevarlo más lejos y también creamos el proyecto inicial del iniciador de aplicaciones. Es solo una aplicación React en sí misma con una pequeña API de Java detrás. Y todo lo que hace es tomar esas plantillas exactas, esos iniciadores de proyectos de GitHub, pero agrega una capa adicional para permitir que un desarrollador elija las opciones que desea al crear su iniciador, para que puedan seleccionar ciertas bibliotecas o si desean un monorepo, se creará automáticamente el monorepo listo para usar. Lo mismo con la federación de módulos. Algunos equipos han encontrado muy difícil hacer que la función de federación de módulos de webpack funcione en un monorepo, mientras que otros equipos como nosotros lo han hecho varias veces y saben cómo hacerlo. Así que construimos un iniciador para eso que permite a cualquiera obtener un modelo de trabajo de inmediato y luego solo tienen que preocuparse por agregar su propio código. Eso fue lo que creamos inicialmente para que cualquier persona lo use, ya que la herramienta está disponible internamente para cualquiera que la use. Luego queríamos centrarnos en cómo podemos mejorar la forma en que construimos nuestro código. Descubrimos que especialmente en Vodafone Business, construimos muchos formularios repetitivos. Hay muchos componentes que son básicamente una configuración diferente con diferentes etiquetas. Queríamos acelerar este proceso. Creamos lo que llamamos el lenguaje de viaje dinámico. Todo lo que es, es solo una configuración JSON. Puedes verlo aquí. Es solo una configuración estructurada que describe una aplicación React. Mencionamos los componentes, tienes hijos, tienes props y luego hay claves personalizadas en ellas que usamos para otras cosas. Es un esquema JSON estándar muy básico, pero se combina con algo que creamos llamado el renderizador de viaje dinámico para construir automáticamente la capa de interfaz de usuario de tu aplicación React. El renderizador de viaje dinámico es una pequeña biblioteca muy simple por sí sola. Solo tiene 75 líneas de código. Te permite iterar sobre este esquema JSON y renderizar los componentes de React. Y te permite extenderlo con complementos para realizar la lógica empresarial que has codificado en tu aplicación. Dentro de tu código, colocas ganchos como mapeos de datos, props de API y codificas esa lógica empresarial en tu aplicación. Luego usas este esquema para definir cómo debería verse. A continuación, aparecerá un ejemplo de nuestra versión original del constructor de aplicaciones, una especie de prueba de concepto. No estábamos buscando una plataforma de bajo código como tal. No queríamos crear una herramienta que hiciera todo por ti desde el principio, porque a veces las personas realmente necesitan acceder a su lógica empresarial. Además, no era responsabilidad de nuestro equipo hacer eso, pero te permite crear ese esquema JSON muy, muy rápidamente y generarlo listo para enviar a una API, por ejemplo.

Lo que esto hará es permitirte implementar tu aplicación y apuntarla al esquema JSON para que todo lo que maneje la vista esté dentro de una API. Eso significa que no tienes que hacer todo el ciclo de implementación si solo quieres cambiar el orden de algunos elementos en la pantalla o las etiquetas, cosas así. Esto se convirtió en la base de lo que ahora se conoce como el constructor de aplicaciones, del cual Marwan y el equipo de Retail 10 hablarán en un minuto durante los casos de uso.

Y finalmente, teníamos nuestras bibliotecas de componentes. Así que comenzamos con una guía de estilo. Tenemos lo que se llama Web Simplicity. Ha estado presente en Vodafone durante un tiempo, se moderniza cada año y se espera que todos los equipos sigan la guía de estilo de Web Simplicity. Como cualquier equipo de elementos reactivos, lo primero que hicimos fue convertirlo en una biblioteca de componentes para facilitar su reutilización. Intentamos hacer las cosas de la mejor manera posible. Utilizamos principios de diseño de cómics, hicimos que los componentes fueran lo más simples posible, solo capas visuales de la interfaz de usuario. Y cuando terminamos, estábamos muy orgullosos de nosotros mismos. Así que comenzamos a hablar con otros equipos para ver si querían reutilizarlo. Sin embargo, descubrimos que otros equipos ya tenían la misma idea. El primer equipo con el que hablamos ya había construido el suyo propio. Y de hecho, lo habían estado construyendo antes de que comenzáramos nosotros. Y luego, mientras trabajábamos con ellos para ver si deberíamos unificar, encontramos que otro equipo también había construido uno. Y cada vez que hablábamos con otro equipo, descubríamos que también habían construido su propia biblioteca de componentes, siguiendo en su mayoría los mismos principios, con algunas variaciones. Y a veces, el estilo se había personalizado para ese mercado, pero en concepto, todos estábamos haciendo lo mismo. Y había mucho reuso de código y duplicación de esfuerzo en los mercados. Así que decidimos unirnos. Como parte del Gremio de Desarrollo Web, intentamos que la mayor cantidad de equipos posible se unieran y acordaran una biblioteca para gobernarlos a todos. Una única fuente de verdad, todas las bibliotecas de componentes. Y esto es lo que se convirtió en la Biblioteca de Componentes Fuente. No entraré en detalles sobre esto porque David Lindley está a punto de hablar sobre esto en los casos de uso. Y creo que eso es todo para mí. Ahora le devolveré la palabra a Pedro para que les hable sobre estos casos. De acuerdo, gracias Sam. Ahora vamos a explicar seis iniciativas de proyectos que tenemos en BoraFone. Y comenzaremos con nuestra Biblioteca Web Fuente. La hemos mencionado varias veces en la presentación. Ahora es el momento de detallar Source Web. Después de eso, veremos las páginas de marketing en el Reino Unido basadas en un CMS sin cabeza y la forma en que permitimos que un contenedor inicie su contenido de desarrollo sin necesidad de implementaciones. Esto también es muy interesante. Y en tercer lugar, veremos Retail10. Retail10 es nuestra plataforma para construir e integrar micro aplicaciones React, especialmente para el canal minorista, pero también se puede utilizar en otros canales. Después de eso, veremos el portal para pymes en Budaphon, España. Intentaré explicar la forma de garantizar el ecosistema entre Angular y React basado en la arquitectura, la federación de módulos o los micro contenidos. Después de eso, revisaremos un proyecto muy importante en Budaphon, que es el Marketplace en Turquía que utiliza React para crear una vista web integrada en nuestras aplicaciones móviles. Y finalmente, desde Italia, veremos la nueva arquitectura para un nuevo proyecto basado en el manifiesto web. Y están definiendo una nueva arquitectura en Budaphon, Italia, tratando de aprovechar todas las capacidades en la nube y mejorar el rendimiento utilizando la adopción en la nube. Así que ahora, David, cuando quieras, comienza a explicarlo un poco más.

Gracias. Muy bien, muchas gracias, Pedro. Buenas tardes a todos. Mi nombre es David Lindley y soy gerente de ingeniería de software aquí en Budaphon. También soy el propietario técnico del producto SourceWeb, del cual se ha hablado bastante. Así que comenzaremos nuestro viaje hacia lo que es SourceWeb y por qué lo usamos. Genial. Entonces, ¿qué es SourceWeb? Bueno, como señaló Sam y Pedro ya mencionó, es nuestra biblioteca global de componentes, que reúne todas las demás bibliotecas de componentes, trabajando en las mejores prácticas y asegurándonos de tener una única fuente centralizada de verdad para la apariencia de la interfaz de usuario web. Se basa en nuestro sistema de diseño llamado Fuente. Es grande, echa un vistazo a las estadísticas en la diapositiva. Tiene 220 componentes construidos utilizando principios de diseño atómico, desde los átomos más pequeños, como los botones, hasta los organismos y las estructuras de página. Es utilizado por alrededor de 350 desarrolladores. Ese número crece diariamente en todo el mundo, básicamente, en Vodafone. Y eso es solo en un año, solo hemos estado trabajando en este proyecto durante aproximadamente un año. Este producto, como me gusta llamarlo, ha tenido alrededor de 27,000 descargas únicas. Es decir, pipelines, máquinas individuales descargándolo para usarlo. Y es utilizado por seis mercados y sub-marcas en Vodafone. Y cuando digo sub-marcas, me refiero a marcas propiedad de Vodafone, pero que no se parecen a Vodafone. Y eso es bastante importante cuando llegamos a ver la pila tecnológica en el futuro. Si observamos la pila tecnológica, pasemos a la siguiente diapositiva, por favor. Gracias. La pila tecnológica aquí, como era de esperar, utilizamos React para construir nuestros componentes, ya que esto es el React Summit. También utilizamos TypeScript, junto con React, similar a la forma en que lo hace la aplicación. Principalmente lo usamos para las props. Permite una integración muy fácil si estás utilizando TypeScript en tu aplicación. Por lo tanto, puedes ver las props muy fácilmente.

Utilizamos componentes de estilo. Eso nos permite tematizar nuestros componentes para proporcionar una capa de color, una capa de espaciado, una capa de fuente, lo que permite que sea utilizado por sub-marcas. Similar a cómo funciona Material UI. Tenemos un sitio de documentación público que está disponible públicamente internamente, lo que permite a las personas ver lo que está disponible, y mostraré una demostración de eso en un segundo.

Hay un mono repositorio. Por lo tanto, utilizamos Lerner para la gestión de paquetes con cada componente publicado individualmente y versiones, para poder mantener fácilmente el control de lo que está cambiando y cuándo, porque es de código abierto dentro de Vodafone, queremos que las personas contribuyan a él. No solo mi equipo desarrolla esto. Son 350 desarrolladores los que pueden ingresar y modificar esta base de código.

Le damos un enfoque real a las pruebas. Por lo tanto, utilizamos jest y enzyme. También estamos utilizando la biblioteca de pruebas de React. Tanto para las pruebas de unidad. Como para las pruebas de interacción e integración, utilizamos Cypress, Cypress X y una herramienta llamada aptly tools para hacer regresión visual. Y gran parte de eso está automatizado. Automatizamos nuestra regresión visual. Por lo tanto, si creas un nuevo componente, generamos una nueva prueba de Cypress para ti para poder verificarlo fácilmente en nuestros pipelines. Así que aquí hay un pequeño video de cómo se ve SourceWeb. Nos hemos enfocado en convertirlo en una ventana de exhibición. No solo para desarrolladores, sino también para propietarios de productos y partes interesadas, cualquier persona interesada en lo que está disponible para la web. La idea es que si facilitamos a las personas ver lo que hay, pueden hacer clic en las cosas y echar un vistazo. Por ejemplo, aquí tenemos una tarjeta de accesorios. Podríamos usarla para vender accesorios para teléfonos. Y puedes ver ejemplos en vivo de cómo cambia el código en vivo. Incluso podrías construir una aplicación en el sitio de documentación utilizando esto. Esto utiliza una guía de estilo que está detrás de escena pero la hemos personalizado mucho para que se vea como puedes ver en la pantalla ahora.

También mostramos props y documentación y también enlazamos a Figma, que es nuestra plataforma de UX para que las personas vean cómo debería verse el componente y cómo se debe usar desde el punto de vista de UX para que los diseñadores de UX también puedan interactuar con esto. También tenemos temas. Como dije antes, puedes usar esto con sub-marcas. Ya tenemos algunos temas en Vodafone pero voy a mostrar rápidamente aquí, este es un tema que tenemos que se llama Voxy, Voxy es una sub-marca en Vodafone UK y utilizan algunos de nuestros componentes para desarrollar rápidamente aplicaciones. Tienen un equipo de desarrollo mucho más pequeño que el equipo de desarrollo de Vodafone UK y utilizan esta biblioteca para desarrollar rápidamente y poner en producción. También puedes ver aquí, tenemos dos temas en Vodafone también. También nos aseguramos de hacer una buena documentación. Como Sam mencionó, una buena documentación es realmente importante cuando se trata de ingeniería global por lo que dedicamos mucho esfuerzo en escribir una documentación realmente completa. Nos aseguramos de que se actualice regularmente y esto es para fomentar que las personas contribuyan a esta biblioteca. Como dije, esto podría ser utilizado por 350 personas de diferentes mercados en todo el mundo por lo que debemos asegurarnos de que haya una documentación realmente sólida detrás de ella.

¡Hola a todos! Soy Anna y soy gerente de ingeniería de software en WebAppOne UK, y estoy a cargo del equipo que está construyendo esta plataforma de la que voy a hablarles, que es la integración con Contentful, que básicamente es una plataforma que tiene un CMS y permite a nuestros editores de contenido crear, por ahora solo páginas de marketing, pero el plan es integrar esto con todas las demás partes de nuestro sitio web. Así que prácticamente guardamos contenido para cada parte del sitio web de Vodafone sin necesidad de hacer despliegues.

De acuerdo. Aquí les voy a mostrar lo que ven en la pantalla de lo que construimos. Y solo para entrar en detalles de dónde usamos realmente React y cómo logramos integrarlo con Contentful es, después de obtener el contenido de la aplicación de Contentful, construimos un proceso que pasa por algunas lambdas y algunos mensajes. No les voy a hablar de esa parte, pero tenemos esta lambda que prácticamente agrega en todas esas páginas que renderizaremos en el sitio web, agrega un componente raíz que combina el contenido real de Contentful con nuestra aplicación, con nuestro código para nuestros componentes.

Lo que hacemos entonces es combinar todo y guardar los activos estáticos, el código JavaScript real en buckets de S3. Así que guardamos nuestras páginas estáticas, el bucket solo tiene HTML y algunos campos de data en los que incluimos los datos de Contentful y luego tenemos un bucket de activos de página que incluye todo el JavaScript, imágenes y todo lo demás necesario para renderizar. Ahora, estamos renderizando todo en el lado del servidor pero utilizamos componentes de SourceWeb y por eso puedes ver aquí que tenemos los componentes de SourceWeb. Entonces, lo que David acaba de presentar, nuestra plataforma de CMS está construida completamente con componentes de SourceWeb para que no construyamos nada personalizado y eso también es principalmente para la alineación. Aquí les voy a mostrar les hablé sobre el componente raíz que agregamos en la página. Así que aquí pueden ver cómo lo hacemos. Cada vez que recibimos estos mensajes sobre nuevas páginas publicadas o desde Contentful por los editores de contenido, nuestra aplicación agrega y crea esta página agregando su envoltorio raíz compartido. Tiene un equipo como han visto en lo que compartió David como, tenemos dos equipos para nuestros componentes de web source. Tiene la configuración de ubicación de activos que es el bucket donde obtenemos el código real para los componentes, el entorno porque construimos en diferentes entornos para que los desarrolladores puedan probarlo en entornos inferiores o entornos de desarrollo. Y luego tenemos un proveedor de CMS que obtiene todas esas propiedades que nuestros editores de contenido colocarán en Contentful y las mapea con las propiedades de source web. Y a continuación, el proveedor de CMS carga esos data de los que les hablé antes. Luego quería mostrarles cómo mapeamos esas props. Así que aquí pueden ver que para Content Block que es un componente en source web, obtenemos los data de CMS y luego los enviamos como propiedades que se envían al componente de source web. Entonces, el componente de source web recibe los data en las propiedades con las propiedades que esperan y hacemos el mapeo desde las propiedades de content full. Y el último, el último componente que quiero mostrarles es el banner cursor. Es un componente que usamos en muchas de nuestras páginas. Y lo que hacemos es asegurarnos de obtener los datos del CMS como se especifica en los campos de su CMS, obteniendo los datos y mapeándolos con los campos o propiedades reales que el banner espera de source web. Y además, pueden ver que el banner se importa desde el paquete source de esta publicación cuando realmente publican esos paquetes. Y eso es todo para las páginas de marketing. Si tienen alguna pregunta, háganmela saber y le cederé la palabra a mi colega, Marwan.

Hola, buenas tardes a todos. Mi nombre es Marwan Druby y soy el Gerente de Producto Técnico de Retail10 trabajando en el departamento de Retail y Web IT dentro del grupo Vodafone. Creo que nuestro caso de uso, vamos a trabajar en torno a lo que es Retail10 para que puedan entender por qué construimos el App Builder. Retail10 se trata de transformar la experiencia de nuestros agentes y tiendas en todos nuestros 22 mercados y permitirles tener una experiencia adicional con la venta en paralelo para los agentes pero también permitiendo la movilidad en tabletas y habilitando el autoservicio en quioscos. Y construimos la interfaz de usuario utilizando React pero tenemos un desafío que es necesitamos trabajar para, construir para todos nuestros mercados. Voy a pasar a la siguiente diapositiva, sí, necesitamos construir para todos nuestros mercados pero queremos permitir que todos nuestros mercados configuren y construyan sus propias aplicaciones. También queríamos establecer el desafío para nosotros mismos donde algo construido en Alemania pueda ser utilizado por otro mercado como Grecia y España y sepan que este componente funcionaría. Así que construimos el App Builder que es un ecosistema que tiene en cuenta todas las cosas de las que Pedro, Sam y David hablaron anteriormente. Así que tomamos el source web, tomamos el DGR y los iniciadores de aplicaciones, tomamos el DevOps y el manifiesto web y los combinamos en un ecosistema para construir aplicaciones. Así que, la forma en que lo describí es como una fábrica. Así que tienes tus materias primas que son tus componentes de web source y un mercado de widgets funcionales configurables que son aplicaciones React. Son aplicaciones React desarrolladas como cualquier otra aplicación. Pero también necesitas, esta es la capa de presentación que es lo más simple posible. Tienes tu biblioteca de catálogo de API de ABIs a la que quieres importar el archivo swagger y necesitas tu propia lógica personalizada y saggers para unirlos todos. Y lo que el App Builder te proporciona es una capacidad común para que todos estos componentes se arrastren y se suelten y se construyan en páginas, elijan un reproductor de calderas para su aplicación principal ya sea un BWA simbólico o incluso puedes usar react native como tu aplicación principal para iniciar sesión en todos tus componentes. Y cada componente está construido para ser configurable porque los mercados son diferentes. Les doy un ejemplo de eso. Es solo una búsqueda de clientes en Grecia que se basa en un número de impuestos en España se basa en un ID de facturación. Así que no quieres construir dos componentes separados. Solo quieres cambiar la apariencia y la sensación de los componentes y el mapeo de ABI para el mismo componente para los dos mercados. Y pueden hacerlo a través del App Builder y a través del pipeline, mapea e integra todos estos componentes juntos e implementa la aplicación ya sea en un bucket de S3 o incluso en compañías de productos. Entonces, ¿por qué hicimos eso? Simplemente nos permite tener un tiempo de comercialización más rápido. Nos permite tener una configuración realmente rica. Podemos mostrarles a través del video cómo pueden cambiar los componentes sobre la marcha utilizando el DGR del que habló Sam. Ese mercado permite a todos los desarrolladores ver lo que otros mercados tienen. Así que puedes ver todos los componentes del Reino Unido y puedes usarlos en Alemania. Los construyes una vez y los implementas muchas veces y todo facilita la estandarización. Aunque decimos que es de bajo código, tiene dos modos. Por lo tanto, puedes construir todo desde cero como arrastrar y soltar. Pero también puedes crear una plantilla desde una plantilla para un componente, crear una aplicación React con un desarrollo de ciclo completo e integrarla en el App Builder. Por lo tanto, permite ambos modos de desarrollo. Voy a pasarle la palabra a mi colega, Muna, que es una arquitecta técnica para el App Builder, que hablará sobre el ciclo de vida del desarrollo de widgets, y luego veremos un breve video sobre la creación e implementación de una aplicación. Muy bien, gracias, Mehran. Hola a todos, soy Muna Youssef, Líder Técnico Senior en Retail Tan. Bien, aquí simplemente voy a guiarlos a través de los principales componentes en Retail Tan. Como dijo Mehran, el App Builder es una herramienta de desarrollo de bajo código que permite al usuario crear y diseñar páginas arrastrando y soltando componentes de interfaz de usuario en las páginas, maximizando así el alcance de lo que se puede hacer a través de la interfaz de usuario. Pero el objetivo nunca fue prescindir de la necesidad de código real. Un mercado local podría desarrollar componentes y compartirlos con otros mercados locales para su uso. Para facilitar esto, tenemos una plantilla de widget con el diseño y la estructura para los widgets. Se encuentra en un repositorio de plantillas de GitHub. También tiene el código de boilerplate necesario para que el widget funcione correctamente, como un archivo de configuración, un archivo de props, un ReduxReducer para el widget. Además, tenemos otro archivo que imita o simula las acciones de otros widgets que podrían integrarse con nuestro widget. Cuando se construyen nuestros widgets, los empujamos a un repositorio Nexus. Para asegurarnos también de la misma apariencia que otros canales digitales, estamos reutilizando la biblioteca source web de la que David nos habló en diapositivas anteriores. La interfaz de usuario del App Builder obtiene los widgets del repositorio Nexus. Y muestra los widgets junto con otros activos digitales en el mercado. Estos activos digitales podrían ser componentes atómicos. Tenemos este editor gráfico en el que el usuario podría diseñar BPMN, que significa Business Process Modeling y Notation Diagrams, que representa un subconjunto mínimo viable de conceptos de Saga que podrían despachar una acción o llamar a una API. Luego, la aplicación se generará con las Sagas correctas producidas para ella. Para esto, estamos utilizando la biblioteca BPMN JS. Hay una API del App Builder para almacenar y recuperar las aplicaciones junto con sus configuraciones y traducción. La aplicación React es una PWA de React, que se genera en función de una plantilla de aplicación que se encuentra en un repositorio Git. El proceso de construcción de la aplicación es iniciado por un constructor, el backend invoca un pipeline de Jenkins que recupera la plantilla de la aplicación y luego llama al mecanismo de generación de código. Este mecanismo de generación de código llama a la API del App Builder para recuperar las aplicaciones junto con los programas y configuraciones antes de generar estos archivos. Estamos utilizando Handlebars que es un motor de plantillas para construir los archivos JavaScript para nuestra aplicación y los archivos de recorrido dinámico para las páginas con las que Sam nos mostró en diapositivas anteriores también, que finalmente se implementarán en un clúster de Kubernetes. Muy bien, a continuación, hay un video de demostración. Muy bien, solo, muy bien, a continuación. Muy bien, así que comenzaremos con el ciclo de vida del desarrollo de widgets. Este es el repositorio de plantillas de GitHub del que hablamos que tenía el diseño y la estructura y el código de boilerplate necesario para los widgets. Solo estamos creando un nuevo widget. Muy bien, a continuación, actualizaré en el archivo package JSON del widget. Estableceremos el nombre y la versión del widget. Así es como el App Builder identifica los widgets. También vamos a establecer una categoría para él. Creo que el App Builder agrupa los widgets por categoría y los muestra en el mercado. Muy bien, y comenzaremos a desarrollar localmente en nuestro widget e implementarlo. Ahora pasamos al App Builder. Muy bien, crearemos una aplicación. Seleccionaré el tipo de aplicación y la plataforma y el nombre de la aplicación. También seleccionaré y el tipo de autenticación.

Especificamos un grupo de seguridad para nuestra aplicación. En este caso, es un grupo de seguridad de agentes de Vodafone Store, pero podría ser cualquier otro grupo de seguridad para cualquier tipo de usuarios. También puedes especificar la escena. Así que lo que David mencionó anteriormente sobre Voxy. Muestra la escena correcta para la biblioteca correcta, también.

OK. Ahora comenzaremos a diseñar las páginas. En este caso, estamos arrastrando y soltando un componente de imagen en esta página. Lo agregaremos en las propiedades de este componente de imagen. Estamos configurando la fuente y la proporción. El App Builder también nos permite previsualizar las páginas sin tener que salir del portal del App Builder.

OK, en esta parte, en el App API Manager, seleccionamos la API y la versión para la API que vamos a utilizar. Además, este es el editor de diagramas gráficos, del que hablé en la diapositiva anterior. Promovemos la aplicación al desarrollo. Y cuando se completa la fase de pruebas, podemos promoverla a producción y luego estará disponible en la web. En este caso, esta es una aplicación que verifica la disponibilidad de televisores en una región específica.

OK, a continuación, lo que intentaremos hacer es arrastrar y soltar el widget que creamos al principio de este video en una aplicación existente. Seleccionaremos el nombre del widget. Lo buscaremos. Y lo encontrarás agrupado en el mercado según la categoría que especificamos en el package.json. Este widget de pago aparece cuando el agente de Vodafone Store intenta pagar el carrito de compras de un cliente específico. Así que ahora ve al carrito de compras para poder pagar el carrito de compras de un cliente y poder ver nuestro widget, el widget de pago.

OK. También podemos actualizar las configuraciones de nuestros widgets de pago. Pero en este caso, estamos agregando un nuevo paso completo en nuestro widget. Es un paso de descarga de contrato. Y es un paso en el que podemos actualizar un paso y lo colocamos al principio de nuestro stepper. Así que cuando volvamos a nuestro widget, veremos que es el primer paso. Puedes hacerlo sin ningún cambio de código. Así que estás haciendo la sección de configuración y se entregará a una API REST. Se llama API de configuración. Por lo tanto, puedes cambiar, por ejemplo, en este ejemplo, puedes cambiar el número de pasos en el subcomponente del flujo de pago y verlo en vivo en tu aplicación sin ningún cambio en el código. Sí, eso es todo. Creo que el video ha terminado. Creo que hay otras secciones que mostramos, así que para cada componente, todas las etiquetas en los componentes son traducibles. También tenemos otra sección donde puedes traducir todos los valores si estás en un mercado diferente. Lo que también mostramos en la aplicación que construimos para la disponibilidad es que tomamos el componente web de origen, creamos un símbolo de verificación de disponibilidad de ABIs y a través del mapeador de procesos, asignamos el ABI al componente web de origen, creamos el SAC automáticamente a través del flujo de procesos y lo implementamos en la aplicación. Y eso es como el primer ejemplo donde estamos usando un código completamente local. Por lo tanto, construyes todo desde cero. Pero el segundo ejemplo es el componente de pago que en realidad es un microfrontend, es una aplicación React. Que se construye e integramos como un componente dentro de una página en el App Builder. Creo que ahora pasaremos a Josipa para el portal de pequeñas y medianas empresas.

Hola a todos, mi nombre es Josipa Alonso y trabajo en el equipo de plataforma web dentro de la ingeniería digital en España. Me gustaría hablarles sobre la solución que hemos implementado en la aplicación web de pequeñas y medianas empresas y corporativas, anteriormente conocida aquí en España como EBC. Esta aplicación se desarrolló originalmente con el marco de trabajo Angular. Luego necesitábamos una solución que nos permitiera coexistir con React para que las nuevas unidades pudieran desarrollarla utilizando este marco de trabajo. La migración a React se presentó como un gran desafío porque el objetivo era comenzar la migración al mismo tiempo que se mantenía la aplicación heredada. Para abordar este problema, una solución inicial fue incrustar la aplicación React en la aplicación Angular principal y ser una directiva que manejara todo el ciclo de vida de las aplicaciones y lo renderizara directamente utilizando react-dom.render. Esto, por supuesto, fue una mala solución y tuvo varios problemas. Uno de ellos fue el rendimiento, que se vio afectado en gran medida porque todo el código necesitaba estar en eso y necesitaba presentarse cuando se cargaba esa parte. Siguiendo las pautas de WebManifesto, decidimos pasar de una aplicación monolítica a una arquitectura de microfrontend. Para lograr esto, utilizamos el camino de Webpack, utilizando el complemento de federación de módulos que nos permitió federar nuestra aplicación en diferentes módulos más manejables. OK, para permitirles el uso de cualquier tipo de cliente que producimos, lo siento, para permitirnos usar sus módulos, utilizamos este puente de Angular. Colocamos una pestaña, un componente que actuaba como ese puente y cargaba el Excel del reactor. Este conjunto contenía el almacén de reductores globales, el enrutamiento y otras dependencias como la biblioteca de ventas y nuestra antigua biblioteca principal que contenía todo lo que estaba compartido entre todos los diferentes remotos. OK, lo siento. Aquí hay una explicación técnica más detallada. Básicamente, cuando el usuario realiza una solicitud a la URL de ambos, la aplicación Angular heredada se sirve desde nuestro CMS. Por ejemplo, todos los módulos de React también son estáticos, pero están en Apache y sus entradas de archivos remotos son todas explosivas. Entonces, cuando Angular quiere cargar una parte de la aplicación React, carga este puente de Angular, que luego consume el remoto de las celdas. Así es como el contenedor de nuestra aplicación React carga todas las secciones. OK, finalmente, esta aplicación shell consume las urnas y los datos presentados también tienen entradas remotas. Esto puede sonar un poco complejo. Así que les mostraré un video que explica más detalles al respecto. Lo veré más tarde. ¿Cuáles fueron los beneficios de utilizar este tipo de arquitectura? Para nosotros, es más fácil implementar nuevas funciones o utilizar nuevas tecnologías porque no dependes del resto de la aplicación. Si una aplicación puede ir con una versión diferente o una versión de las dependencias, y necesitamos, por ejemplo, actualizar una parte a una versión más nueva de React, no tenemos que migrar toda la aplicación a esta nueva versión de React o agregar nuestra dependencia.

¿De acuerdo? Esto es más o menos como las microarquitecturas de backend. Nosotros... ¿Qué? De acuerdo. Lo siento. No, no, esto es el video. De acuerdo, lo siento. Tenemos también las bases de código entre remotos porque cada remoto es un estándar. Aunque creo que esto puede ser bueno. Esto puede ser problemático para escalar y mantener porque estás buscando escalar un componente individual de funcionalidad, necesitarás escalar todo agregando más capacidad de servidor. Por ejemplo, en Modifyedition, se reduce a qué remoto quieres mejorar. También no podemos reducir la complejidad que surge de un acoplamiento no intencional entre componentes que no deberían conocerse. Otro beneficio es la implementación independiente. Cada remoto, como dije, puede tener su propia integración continua basada en sus necesidades. El beneficio más importante que creemos que los microcontenedores no son ideales para proyectos o equipos pequeños, pero sí para proyectos grandes y cosas distribuidas, de acuerdo. En las aplicaciones monolíticas, tienes equipos horizontales que, además de trabajar en sus características, también trabajan en componentes seguros, estilo, lógica, dependencias. En los microcontenedores, te ves obligado a trabajar en equipos verticales en los que un equipo supervisa una característica, el otro supervisa un conjunto de componentes utilizados, y así sucesivamente. Ahora les mostraré el video que nuestro colega y desarrollador Paul Colomet les mostrará los detalles del código de cómo se realiza esta integración entre React y Angular. Con suerte... Hola, soy Paul de Vodafone España. Estoy aquí para contarles mucho sobre nuestras soluciones para nuestra migración a React. Como hemos visto en las diapositivas anteriores, tenemos dos aplicaciones que se fusionan en una. Aquí está el microfrontend de React. Lo primero que se expone a Angular es el puente Angular, que es un componente web que consume la raíz de la aplicación y también maneja todo el ciclo de vida entre Angular y la aplicación de React. Además, define este puente en los elementos del cliente de la ventana. Así es la raíz del puente. Es un componente sencillo. Tiene un objeto como sonda llamado angular que recibe todos los datos y referencias de funciones necesarios para que la aplicación funcione. Luego carga la shell de la aplicación de forma perezosa. Podemos ver la shell ahora. Así es el arranque de la shell. Recibe las propiedades de Angular recibidas en el puente Angular. Las distribuye entre los proveedores para que podamos consumirlas más tarde. Aquí tenemos el componente que crea el diseño principal y maneja el enrutamiento con los remotos cargados de forma perezosa. Para que la historia de Angular y React se considere, también estamos escuchando los cambios de ruta de Angular y los estamos enviando a una historia de React. Desde el lado de Angular, estamos ampliando la base web para consumir el puente Angular. Luego, en nuestro arranque, estamos definiendo el componente web. Por lo tanto, este componente actúa como el enrutador de la aplicación de React. Como podemos ver aquí, está sobre el enrutador de Angular y las propiedades son una propiedad del componente que se establece para cambiar a lo largo del ciclo de vida del componente de la aplicación. Ahora que hemos visto cómo funciona todo esto, para crear un nuevo remoto en Vodafone España, hemos creado un nuevo generador propietario. Para crear un nuevo remoto, solo tenemos que ingresar el nombre. Así que podemos configurar un nuevo remoto. Luego pedirá el puerto. Se ejecutará localmente, así que podemos decirle 3009. Esto nos configurará el nuevo remoto, solo tenemos que resolver los conflictos. Luego podemos ver esta configuración. Configurará una página simple. Para que el remoto funcione, solo tenemos que agregarlo al enrutamiento de la shell. Este es un componente cargado de forma perezosa. Luego podemos ir a la aplicación de Angular y ver si el componente funciona. Anteriormente lancé ambas aplicaciones. Esta es React y esta es Angular. Para comprobar si funciona, podemos ir a Chrome. Carguemos la aplicación. Así que podemos abrir la herramienta de consola de desarrollo. Abramos la red, volvamos a cargar. Este es el punto de entrada remoto. Eso es Webpack cargando la aplicación de React. Iniciemos sesión y si vamos a la ruta que acabamos de crear, veremos la página principal del remoto. Creo que es bastante bueno en realidad. Esto es React incrustado en Angular. Esta es la aplicación principal. Esto concluye para mí. Espero que hayan aprendido algo nuevo. Que tengan un buen día. De acuerdo. Esto es todo. Ahora, Orkan de Turquía nos hablará sobre nuestros proyectos clave para el marketplace de este año.

Soy el gerente de desarrollo de front-end. Tenemos casi seis proyectos de React en Vodafone Turquía en este momento. Pero hoy voy a explicar nuestro proyecto de marketplace. Cuando comenzamos el proyecto, decidimos codificar con React-JS y nuestra otra decisión fue utilizar este proyecto con WebView en nuestra aplicación, la aplicación My Vodafone. En primer lugar, lanzamos este proyecto en octubre y por ahora estamos utilizando una biblioteca local. Y este proyecto solo funciona en nuestra aplicación con WebView. Por ahora no hay versión web, pero la haremos. Y este proyecto funciona en un servidor Apache. Por ahora hay 2 millones de productos, 600 vendedores y 200,000 pedidos al mes en este proyecto. La segunda parte son nuestros próximos objetivos. En primer lugar, utilizaremos Next.js para SSR y SEO. Y utilizaremos nuestra biblioteca web de origen con Next.js. Y utilizaremos el mismo proyecto en el entorno de la aplicación y la web. Y este proyecto funcionará en el entorno de OpenShift, por supuesto. Y finalmente, ahora Gizem está aquí de nuestros capítulos y Gizem explicará más detalles sobre este proyecto. Y gracias.

De acuerdo, Gizem. Hola a todos. Mi nombre es Gizem. Trabajo como desarrolladora de front-end en un proyecto de marketplace. Quiero mostrarles algunas características clave de nuestro proyecto. Nuestro proyecto, como dijimos, se abre solo en la aplicación nativa, lo que significa que no hay inicio de sesión ni funcionalidad de registro de clientes en la aplicación del marketplace. En realidad, no es necesario porque hemos construido un mecanismo que nos proporciona comunicación entre la aplicación nativa y nuestras vistas web. Cuando un cliente inicia sesión en la aplicación nativa, la información se guarda con su nombre de campo único. En nuestro ejemplo, como pueden ver, cuando un cliente inicia sesión en la aplicación nativa, la aplicación nativa guarda esta información para enviárnosla utilizando nombres de campo únicos. En ese ejemplo, podemos decir que estamos guardando las variables del cliente con un nombre de campo llamado variables del cliente. Y cada vez que nuestra vista web especial, que es creada por la aplicación nativa, se abre, utilizamos el almacenamiento de sesión para obtener la información del cliente que va a iniciar sesión en la aplicación nativa. Y luego capturamos los datos de nuestro cliente utilizando el almacenamiento de sesión. Depende de nosotros cómo utilizamos estos datos, cómo implementamos nuestras vistas web según estos datos. Por ejemplo, supongamos que un cliente de teléfono no modelo inicia sesión en la aplicación nativa. Luego también podemos obtener los datos utilizando el almacenamiento de sesión y determinar qué páginas o qué diseños deben verse para este tipo de clientes. Porque en nuestro proyecto, tenemos diferentes tipos de diseños para diferentes tipos de clientes. Por ejemplo, teléfono no modelo, teléfono modelo, pospago y prepago, etc. Gracias a este flujo de datos, podemos personalizar nuestras páginas web utilizando los tipos de clientes. Por otro lado, también hay una ventaja significativa de este flujo de datos. Como pueden ver en la segunda imagen, cuando necesitamos una funcionalidad basada en el dispositivo en las páginas del marketplace, trabajamos en paralelo con la aplicación nativa. Ellos implementan una función especialmente para el tipo de dispositivo, me refiero al sistema operativo del cliente. Luego utilizamos estas funciones que se desarrollan en el sistema operativo del cliente. En nuestro ejemplo, como pueden ver, hay una función en la parte inferior. Esta función es escrita por los desarrolladores nativos. Necesitábamos esta funcionalidad porque al intentar abrir los enlaces externos fuera del alcance de nuestra vista web, hay algunas limitaciones para iOS. Entonces, al intentar realizar esta operación, debemos conocer y actuar según el sistema operativo del cliente. Así que estamos tratando de trabajar y desarrollar la función que necesita especialmente el sistema operativo del cliente, estamos trabajando en paralelo con los desarrolladores nativos. ¿Podemos pasar a la siguiente diapositiva? De acuerdo, gracias.

El marketplace es una aplicación muy dinámica y activa, lo que significa que siempre hay campañas, ofertas, descuentos y clasificación de los productos que se muestran en la página de inicio para nuestros clientes. La primera imagen se toma de nuestra página de inicio. Hay un widget variable según los días especiales en Turquía, días festivos o campañas especiales para nuestros productos y tenemos muchos. Por esa razón, construimos una estructura para gestionar estos widgets utilizando nuestro sistema de gestión de contenido. Por ejemplo, todos los widgets especiales como en la primera imagen tienen un tipo en el CMS, cuando cualquier usuario técnico o no técnico, por supuesto, que tiene permiso para agregar productos o widgets, crea un widget utilizando el CMS, agrega un tipo especial en ese widget y agrega el producto para ese widget. Luego, nuestra implementación detecta automáticamente el widget y su producto y los muestra en la página web de responsabilidad llamando a servicios y APIs de back-end. Por lo tanto, cuando haya necesidad de cambiar el nombre del widget, los productos o el título, incluso el color de fondo de ese widget, la única operación es gestionar los widgets en el CMS. Eso significa que no habrá desarrollo ni esfuerzo de implementación para nosotros en el proyecto si el diseño es el mismo para el widget. En la segunda imagen, pueden ver nuestra página de categorías con las categorías principales y sus subcategorías. Esta página también funciona con la misma metodología. Todas las categorías y sus imágenes y sus subcategorías, incluso si son marcas populares para esa categoría, se obtienen utilizando el CMS. Luego, nuestro equipo de negocios decide agregar, eliminar o editar cualquier categoría. Solo editamos la página del CMS para esa categoría. Por otro lado, a veces podríamos necesitar una página estática con el componente estático para los clientes. En la tercera imagen, pueden ver nuestra página de perfil. En esa página, hay algunos componentes que son texto estático, como en la cuarta imagen. Estos componentes también funcionan de la misma manera. Cada vez que nuestro equipo quiere agregar un nuevo campo en la página de perfil, agregan un componente que contiene un texto para ese componente y agregan un tipo específico utilizando el CMS para que, como desarrollador de front-end, pueda entender el tipo de ese componente y pueda colocar ese componente en la página de perfil automáticamente. Otro punto clave es el uso de herramientas analíticas, por supuesto. Estamos utilizando Omniture, que funciona como una base de datos para Tillium. Recopila los datos de nuestros clientes según los eventos actuales del cliente y los envía a Tillium para utilizar cualquier otra herramienta analítica. Mostraré el ejemplo de código para esa herramienta basada en eventos. Pero funciona mediante eventos utilizando la información del cliente que se toma de la parte nativa. Y por último, pero no menos importante, está nuestra página de búsqueda. Como pueden ver en la última imagen, estamos utilizando Elastic Search. Cuando un cliente escribe caracteres en nuestra barra de búsqueda, mostramos el último texto de búsqueda o términos de búsqueda populares y sugerencias para ese cliente según los últimos términos de búsqueda y el texto de ese cliente actual.

¿Podemos pasar a la siguiente diapositiva, por favor? De acuerdo, gracias. Y quiero mostrarles el ejemplo de código de lo que expliqué. En la primera imagen, pueden ver los widgets y la estructura de componentes de la página de categorías utilizando CMS. Al llamar a las API del backend, obtenemos las categorías, subcategorías y marcas populares para esa categoría, y las colocamos en los componentes que se implementan solo para la página de categorías. En la segunda imagen, pueden ver una función llamada uTagView. Esta función es la llamada que recopila los datos requeridos y los envía a Tilium, evento por evento. Por ejemplo, llamamos a esta función cuando un cliente agrega un producto al carrito, o cuando realiza un pago o compra cualquier producto, etc. La tercera imagen muestra la separación de entornos mientras implementamos nuestras funcionalidades. Tenemos tres entornos diferentes en Marketplace, cuatro en realidad. Uno de ellos es de prueba, otro es de preproducción y finalmente producción. A veces necesitamos alguna configuración específica del entorno, por ejemplo, CDN. Estamos utilizando Medionova para recortar las imágenes en diferentes tamaños para cada tipo de componente. Y como sabemos, por problemas de rendimiento, no podemos recortar ni modificar imágenes en el front-end. Sin embargo, la URL basada en CDN es diferente para cada entorno. Por eso tenemos archivos de configuración para cada entorno. Estos incluyen las URL o nuestras variables de configuración en él. La última imagen es un ejemplo de cómo obtenemos datos del CMS para nuestras páginas, especialmente para los componentes estáticos como vemos en la página de perfil. Eso es todo en realidad. Gracias por escuchar. Genial. Muchas gracias por mostrarnos los detalles. ¿A quién pasamos ahora? Hola, soy Ruperta. Soy la líder desarrolladora y parte del equipo de Ingeniería Web en Vodafone Italia. Estoy aquí para mostrarles nuestro largo camino a través de nuestra nueva arquitectura. El primer paso de la transformación de la arquitectura fue la identificación de acciones clave de mitigación con el objetivo de simplificar las diferentes capacidades de la arquitectura y aumentar el rendimiento definiendo una estrategia de servicio de imágenes optimizando el campo JS y el tamaño del paquete, y adoptando capacidades de CDN y CMS sin cabeza. Basándonos en la solución de ganancia rápida, implementamos una prueba de concepto que mejoró drásticamente los KPI vitales de Google de nuestra aplicación web seleccionada. Sobre todo, en lo que respecta al rendimiento web y la interacción del cliente con el sitio web. Así que hicimos LCP y FID de los KPI vitales de Google. La solución de prueba de concepto del manifiesto web de Vodafone nos permitió definir la arquitectura objetivo. Basada en React y TypeScript, donde aprovechamos por completo las comunidades de ingeniería digital de Vodafone para capacidades específicas como la gestión de monocompos, la generación de sitios estáticos y los scripts de construcción. Antes de entrar en detalles, seleccionamos el caso de uso y la descripción de la capacidad. Me gustaría resaltar la importancia del manifiesto web no solo para la selección técnica, sino también para la estandarización y calidad del código con reglas de linting y seguridad predefinidas. El uso de bibliotecas de UI y la experiencia de la comunidad de Vodafone en la adopción de CMS sin cabeza nos permitieron acelerar la definición y desarrollo de la arquitectura. Ahora centrémonos en algo de código, como podemos ver aquí. Bajemos el volumen. Como pueden ver, esta es nuestra aplicación web. Aquí pueden ver los paquetes y aquí hay algunos comandos y luego los comandos obviamente son para un proyecto diferente. Nuestra arquitectura se basa en Nx, que es nuestro gestor de paquetes monorrepo. Bajo la carpeta 'app', como pueden ver, hay todos los diferentes proyectos que alojamos en nuestra aplicación, por ejemplo, CYM landings, RICE, etc. Y cada proyecto tiene su propia personalización. Veo que el video parece bloqueado. Déjame ver. De acuerdo. Lo siento. Lo siento por las molestias. Tal vez retrocedamos una diapositiva y luego volvamos a esta, a ver si funciona. De acuerdo, sí, se está moviendo, parece que sí. Luego, en 'leaves', como pueden ver, hay un pequeño decodificador que se puede compartir, así que en nuestro caso, solo queríamos mostrar los temas. Los temas incluyen todo lo relacionado con el estilo, como los colores, las fuentes, etc. Así que creamos un componente, el proveedor de temas, que se engloba a sí mismo. El video está, no sé qué está haciendo. No es correcto. A veces se mueve hacia atrás y adelante. No sé por qué. Así que simplemente decimos que el proveedor de temas está incluido en la aplicación personalizada, por lo que cada proyecto puede tener dentro ese proveedor de temas que se puede compartir o personalizar para el proyecto. Luego, avanzando, podemos ver cómo Next crea la generación de sitios estáticos. En nuestro caso, tenemos el pre-renderizado HTML. Esto es muy importante para nosotros porque, como podemos ver, el BIF creado por Next también tiene un campo de caché y DIR-Nexting, que también proporciona la ruta del navegador para ese recurso, y una actualización rápida en el desarrollo. De acuerdo. Lo siento, solo estoy tratando de detenerlo porque no sé por qué se mueve hacia atrás y adelante. Ahora, en este video, pasamos a la parte de UI. En la parte de UI, solo queríamos mostrar cómo decidimos manejar las imágenes. Creamos un componente, un componente de imagen de leads, que importamos desde la biblioteca Next Image. Decidimos usar Image, que es un componente de la biblioteca Next porque maneja muy bien todo lo relacionado con las imágenes en Next. Por ejemplo, siempre sirve imágenes de tamaño correcto para cada dispositivo, utilizando el formato .webp, lo que ayuda a mantener la estabilidad visual evitando cambios de diseño acumulativos, y además, es importante que las imágenes solo se carguen cuando entran en el viewport, lo que permite un desenfoque opcional para las imágenes. Y, obviamente, es muy importante tener un redimensionamiento de imágenes bajo demanda, incluso para el almacenamiento de imágenes en servidores remotos.

Como podemos ver aquí, importamos en el carrusel de diapositivas nuestro componente de imagen, que recibe como prop un array de imágenes. Estas imágenes, como podemos ver, son simplemente cargadas. Detuve el video debido a lo que está haciendo. Lo siento. Aquí estoy mostrando una imagen diferente. Toma el array y luego en el navegador web, podemos ver que la imagen se carga, en primer lugar, un marcador de posición. Por lo tanto, son bastante livianas para cargar en la página. Lo siento, no sé por qué el video se mueve hacia atrás. Todo el tiempo. De acuerdo, en esta parte, podemos ver que, en primer lugar, solo cargamos el marcador de posición de la imagen. Y luego, cuando la imagen entra en el viewport de la página, se carga en el lado correcto para ese dispositivo. Por lo tanto, es muy útil y práctico para manejar imágenes. Sí, este video no es muy bueno. Bueno, sigo adelante yo mismo. Como podemos ver cerca de ellos. Por último, queríamos mostrarles cómo decidimos manejar nuestra CI y CDN. Integración continua y entrega continua con Amplify. Este es el archivo de configuración que, obviamente, apunta a la carpeta dist ya creada por Next con la generación de sitios estáticos de HTML. Como podemos ver cerca. Y la característica más importante es que Amplify nos ayuda porque realmente puedes crear para cada rama de características que generes, puedes crear un entorno de desarrollo personalizado. Por lo tanto, cada función puede tener su propio entorno. Esto es muy útil para los desarrolladores porque para cada función que estás desarrollando, puedes tener tu propio entorno personalizado y también puedes continuar con tus pruebas de depuración para acelerar el desarrollo del proyecto, el proceso. Y eso es todo. La mayor parte de eso es nuestra arquitectura. Entonces, ¿cuál es el siguiente paso para Vodafone Italia? El siguiente paso es implementar esta nueva arquitectura en producción y continuar con el desarrollo. Espero que hayan disfrutado de la presentación, aunque fue un poco extraña con el video y la búsqueda útil. Gracias por ver. Que tengan un buen día. Genial. Muchas gracias, Roberta, y disculpen el problema técnico con el video. Tengo la sensación de que podría ser culpa de mi computadora portátil. Así que disculpen si eso interrumpió su seguimiento de la presentación. De alguna manera pude seguir adelante. Así que gracias por guiarnos. Creo que eso nos lleva al final. ¿Había algo, creo, Pedro, eso fue todo? ¿Querías hacer un resumen después del grupo web? Sí, Amy. Sí, creo que podemos hacer un resumen para resumir nuestra presentación web. En primer lugar, buscamos eficiencia, buscamos reutilización y buscamos una gran comunidad de desarrollo que nos permita crear capacidades realmente increíbles con mucho menos esfuerzo que en el pasado. Como pudieron ver en esta presentación, estamos trabajando en varios casos de uso o aplicaciones reales en las que estamos trabajando actualmente. Así que esos son solo algunas de las aplicaciones en Vodafone, tenemos muchas más capacidades brillantes para compartir y realmente buscamos los mejores desarrollos, la mejor forma de trabajar y nuestra mejora continua es la forma en que intentamos lograr esto. Así que gracias por unirse y si tienen alguna pregunta adicional sobre la presentación web, estaremos encantados de responder. Genial. Muchas gracias. Y gracias a todos nuestros panelistas por guiarnos en las demostraciones hoy. Realmente fue rico en contenido, así que fue muy bueno verlo presentado como una gran pieza de trabajo. Y también gracias a todos los que han visto los talleres. Sé que está disponible en vivo, pero también se verá después. Así que muchas gracias por la participación del grupo al hacer muchas preguntas realmente buenas sobre el contenido que hemos presentado. Si hay alguna otra pregunta, como dice Pedro, pueden comunicarse directamente con nosotros. LinkedIn probablemente sea el más fácil porque la mayoría de nosotros estaremos allí de todos modos. Y creo que hay un servidor de Discord del propio React Summit en el que podremos publicar algunos resultados de preguntas y respuestas también. Así que lo haremos después de la llamada. Por último, si desean obtener más información sobre Vodafone, he dejado ese código QR en la pantalla nuevamente, es un excelente enlace a una página de inicio sobre nuestro viaje como ingenieros de software en Vodafone. Y no olviden que estaremos en el React Summit. Habrá un gran stand de Vodafone allí. Muchos de nosotros estaremos allí y estamos realmente emocionados de interactuar con algunas personas de la comunidad. Además, habrá un lugar, el perro robot estará allí. Si no lo han visto, es realmente genial. Así que vengan, echen un vistazo. Creo que les gustará. Pero por ahora, solo quiero decir gracias nuevamente a todos los que se unieron y estuvieron en el panel. Ha sido genial trabajar con ustedes en esto y espero verlos a todos pronto. Que tengan una excelente tarde.