Saltar al contenido principal

Resumen del Meetup de San Francisco

· 9 min de lectura
Héctor Ramos
Héctor Ramos
Former Developer Advocate @ Facebook
Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

La semana pasada tuve la oportunidad de asistir al Meetup de React Native en la oficina de Zynga en San Francisco. Con alrededor de 200 asistentes, fue un excelente lugar para conocer a otros desarrolladores cercanos que también están interesados en React Native.

Estaba especialmente interesado en aprender más sobre cómo usan React y React Native en empresas como Zynga, Netflix y Airbnb. La agenda de la noche sería la siguiente:

  • Prototipado Rápido en React

  • Diseño de APIs para React Native

  • Cerrando la Brecha: Usando React Native en Bases de Código Existentes

Pero primero, el evento comenzó con una breve introducción y un resumen de noticias recientes:

Si uno de estos meetups se realiza cerca de ti, ¡te recomiendo encarecidamente asistir!

Prototipado Rápido en React en Zynga​

Tras la ronda de noticias, Zynga, nuestros anfitriones de la noche, hizo una breve presentación. Abhishek Chadha habló sobre cómo usan React para prototipar rápidamente nuevas experiencias en móviles, mostrando un prototipo rápido de una aplicación similar a Draw Something. Utilizan un enfoque similar a React Native, proporcionando acceso a APIs nativas mediante un puente. Esto se demostró cuando Abhishek usó la cámara del dispositivo para tomar una foto de la audiencia y luego dibujó un sombrero en la cabeza de alguien.

Diseño de APIs para React Native en Netflix​

A continuación, la primera charla destacada de la noche. Clarence Leung, Ingeniero de Software Senior en Netflix, presentó su charla sobre Diseño de APIs para React Native. Primero señaló los dos tipos principales de bibliotecas en las que se puede trabajar: componentes como barras de pestañas y selectores de fecha, y bibliotecas que brindan acceso a servicios nativos como el rollo de cámara o pagos in-app. Hay dos enfoques posibles al construir una biblioteca para usar en React Native:

  • Proporcionar componentes específicos por plataforma

  • Una biblioteca multiplataforma con una API similar para Android e iOS

Cada enfoque tiene sus propias consideraciones, y depende de ti determinar cuál funciona mejor para tus necesidades.

Enfoque #1

Como ejemplo de componentes específicos por plataforma, Clarence mencionó DatePickerIOS y DatePickerAndroid del núcleo de React Native. En iOS, los selectores de fecha se renderizan como parte de la UI y pueden integrarse fácilmente en una vista existente, mientras que en Android se presentan modalmente. Tiene sentido proporcionar componentes separados en este caso.

Enfoque #2

Los selectores de fotos, por otro lado, se manejan de manera similar en Android e iOS. Existen ligeras diferencias —Android no agrupa las fotos en carpetas como iOS lo hace con los Selfies, por ejemplo— pero estas se resuelven fácilmente usando sentencias if y el componente Platform.

Independientemente del enfoque que elijas, es recomendable minimizar la superficie de la API y construir bibliotecas específicas para cada aplicación. Por ejemplo, el sistema de Compras In-App de iOS soporta transacciones únicas, consumibles y suscripciones renovables. Si tu aplicación solo necesita manejar compras consumibles, puedes prescindir del soporte para suscripciones en tu biblioteca multiplataforma.

Al final de la charla de Clarence hubo una breve sesión de preguntas. Un dato interesante que surgió fue que alrededor del 80% del código React Native escrito para estas bibliotecas en Netflix se comparte entre Android e iOS.

Cerrando la brecha: Uso de React Native en bases de código existentes​

La charla final fue impartida por Leland Richardson de Airbnb, enfocándose en el uso de React Native en bases de código existentes. Si bien es sencillo crear una nueva app desde cero con React Native, me interesaba especialmente conocer la experiencia de Airbnb al adoptarlo en sus aplicaciones nativas ya establecidas.

Leland comenzó diferenciando aplicaciones greenfield (proyectos nuevos sin restricciones previas) versus brownfield (proyectos que deben integrarse con códigobase existente, procesos de desarrollo y necesidades de equipos establecidos).

En proyectos greenfield, la CLI de React Native configura un único repositorio para Android e iOS que funciona inmediatamente. El primer desafío para Airbnb fue que sus aplicaciones móviles tenían repositorios separados. Las empresas con múltiples repositorios enfrentan obstáculos adicionales al adoptar React Native.

Para solucionarlo, Airbnb creó un nuevo repositorio para el código React Native. Sus servidores de CI replicaban los repositorios nativos en este nuevo espacio. Tras ejecutar pruebas y construir el bundle, los artefactos se sincronizaban con los repositorios originales. Esto permitía:

  • Ingenieros móviles trabajar sin instalar npm o ejecutar el packager
  • Especialistas en React Native enfocarse en su código sin preocuparse por sincronización entre plataformas

Este enfoque tenía desventajas, principalmente la imposibilidad de implementar actualizaciones atómicas. Cambios que requerían modificar código nativo y JavaScript necesitaban tres pull requests separados, que debían integrarse con extrema precisión. Para evitar conflictos, el CI cancelaba la sincronización si la rama master cambiaba durante la construcción, causando demoras en periodos de alta actividad (como lanzamientos de versiones).

Airbnb migró posteriormente a un enfoque de mono-repo. Afortunadamente, esta transición ya estaba considerada, y al ver los beneficios de React Native, los equipos de Android e iOS aceleraron voluntariamente este cambio.

Esto resolvió la mayoría de los problemas del enfoque multi-repo, aunque Leland destacó que incrementa la carga en los servidores de control de versiones, algo que podría afectar a empresas más pequeñas.

El problema de la navegación​

La segunda parte de la charla abordó un tema crucial: la navegación en React Native. Leland mencionó la proliferación de bibliotecas de navegación (oficiales y de terceros), destacando que NavigationExperimental parecía prometedora pero finalmente no se adaptó a sus necesidades específicas.

De hecho, ninguna de las bibliotecas de navegación existentes parece funcionar bien para aplicaciones brownfield. Una aplicación brownfield requiere que el estado de navegación sea completamente controlado por la aplicación nativa. Por ejemplo, si la sesión de un usuario expira mientras se muestra una vista de React Native, la aplicación nativa debe poder tomar el control y mostrar una pantalla de inicio de sesión según sea necesario.

Airbnb también quería evitar reemplazar las barras de navegación nativas con versiones JavaScript durante la transición, ya que el efecto podría resultar discordante. Inicialmente se limitaron a vistas presentadas modalmente, pero esto obviamente planteaba un problema al adoptar React Native de manera más amplia en sus aplicaciones.

Decidieron que necesitaban su propia biblioteca. La biblioteca se llama airbnb-navigation. Aún no se ha liberado como código abierto porque está fuertemente vinculada al código base de Airbnb, pero es algo que les gustaría publicar antes de fin de año.

No entraré en muchos detalles sobre la API de la biblioteca, pero estos son algunos de los puntos clave:

  • Se deben pre-registrar las escenas con anticipación

  • Cada escena se muestra dentro de su propio RCTRootView. Se presentan de forma nativa en cada plataforma (por ejemplo, se usan UINavigationControllers en iOS).

  • El ScrollView principal en una escena debe envolverse en un componente ScrollScene. Esto permite aprovechar comportamientos nativos como tocar la barra de estado para desplazarse al inicio en iOS.

  • Las transiciones entre escenas se manejan de forma nativa, sin preocupaciones de rendimiento.

  • El botón Atrás de Android tiene soporte automático.

  • Pueden aprovechar el estilo de barra de navegación basado en View Controller mediante un componente Navigator.Config sin UI.

También hay algunas consideraciones a tener en cuenta:

  • La barra de navegación no se personaliza fácilmente en JavaScript, ya que es un componente nativo. Esto es intencional, ya que usar barras de navegación nativas es un requisito fundamental para este tipo de biblioteca.

  • Los ScreenProps deben serializarse/deserializarse cuando se envían a través del puente, por lo que debe tenerse cuidado al enviar demasiados datos aquí.

  • El estado de navegación es controlado por la aplicación nativa (también un requisito fundamental), por lo que herramientas como Redux no pueden manipular el estado de navegación.

La charla de Leland también incluyó una sesión de preguntas y respuestas. En general, Airbnb está satisfecha con React Native. Están interesados en usar Code Push para solucionar problemas sin pasar por la App Store, y sus ingenieros adoran Live Reload, ya que no necesitan reconstruir la aplicación nativa tras cada cambio menor.

Palabras de cierre​

El evento finalizó con noticias adicionales sobre React Native:

Los meetups brindan una excelente oportunidad para conocer y aprender de otros desarrolladores de la comunidad. Espero asistir a más meetups de React Native en el futuro. Si asistes a alguno, ¡búscame y cuéntame cómo podemos mejorar React Native para ti!