Resumen de la Cumbre de Colaboradores Principales de React Native 2024
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →
Cada año, los colaboradores principales de la Comunidad de React Native se reúnen con el equipo de React Native para definir colaborativamente la dirección de este proyecto.
El año pasado no fue diferente, con una pequeña excepción. Normalmente nos reunimos un día antes de la React Universe Conf (anteriormente React Native EU) en la sede de Callstack en Wrocław. En 2024, aprendiendo de experiencias previas, organizamos la Cumbre durante dos días consecutivos para tener más tiempo no estructurado juntos.
Esta tradición anual se ha convertido en una valiosa oportunidad para que los colaboradores compartan perspectivas y expresen sus inquietudes, y para que el equipo central comparta sus planes y recopile comentarios de colaboradores clave del ecosistema de React Native, incluidas empresas socias, autores individuales de bibliotecas y amigos.
Dividimos la Cumbre en dos áreas que cubrían los siguientes temas:
En esta publicación de blog, queremos ofrecerte un adelanto de los resultados de este encuentro.
Lanzamientos
Mantuvimos una discusión extensa sobre el proceso de lanzamiento de React Native. El Equipo Central valora la participación de colaboradores externos a Meta en los lanzamientos y enfatiza la importancia de las versiones nocturnas, particularmente beneficiosas para plataformas Fuera del Árbol Principal como React Native visionOS, mantenedores de bibliotecas (Reanimated) y frameworks (Expo). Debatiemos la frecuencia de los lanzamientos: algunos pidieron versiones más frecuentes para implementar correcciones más rápido, mientras otros expresaron preocupación sobre el impacto en bibliotecas de terceros y esfuerzos de actualización.
También exploramos formas de reducir cambios disruptivos accidentales y mejorar la comunicación sobre compatibilidad entre React Native y dependencias de terceros.
Esta sesión demostró la complejidad de gestionar lanzamientos para React Native, y lo delicado del tema considerando todas las partes del ecosistema que deben tomarse en cuenta.
¿Qué viene después de la Nueva Arquitectura?
Ahora que la Nueva Arquitectura se ha publicado como estable, discutimos en qué enfocarnos después. ¿Cuál podría ser el próximo gran paso? Los temas giraron en torno a:
-
Compatibilidad web – se concluyó con la discusión sobre la dirección del proyecto React Strict DOM, que debe tratarse como un polyfill temporal mientras el equipo Xplat implementa funcionalidad multiplataforma adecuada en el núcleo de React Native.
-
Estabilización de la API central – resultó que necesitamos más consenso sobre lo que esto significa para desarrolladores de aplicaciones, autores de bibliotecas y plataformas Fuera del Árbol Principal. Por ejemplo, podría ser necesario extraer la lógica nativa de plataforma para iOS y Android de la base de código compartida en C++. Parte de esto se cubrió en la discusión de LeanCore 2.0.
-
Compatibilidad con la arquitectura antigua – como se esperaba, el equipo confirmó que las nuevas funciones de React 19 basadas en renderizado concurrente no funcionarán en la arquitectura antigua. Las nuevas funcionalidades están dirigidas principalmente a la nueva arquitectura. Debido a bloqueos en el calendario de lanzamiento de React 19, aún no está claro dónde establecer el límite entre la funcionalidad admitida por ambas arquitecturas.
-
Bibliotecas de terceros para React Native – actualmente los autores de bibliotecas podemos usar TurboModules, ExpoModules y recientemente NitroModules para lograr el mismo objetivo de conectar funcionalidades nativas de plataforma. Necesitamos mejor documentación sobre cómo implementarlo correctamente.
-
Documentación Brownfield – al momento de la cumbre, la documentación oficial para integrar React Native en aplicaciones nativas estaba bastante desactualizada. Desde entonces el equipo ha publicado documentación actualizada y simplificada para Android e iOS.
-
Tree-shaking para Metro web – el equipo central de Metro está abierto a integrar el trabajo del equipo de Expo en esta área.
APIs web para módulos nativos
Esta sesión se centró en el RFC de Microsoft que propone incorporar un subconjunto de APIs web a React Native. El objetivo es mejorar la escalabilidad de React Native y atraer más desarrolladores web mediante APIs familiares, permitiendo acceder a numerosas bibliotecas web de código abierto que actualmente no tienen soporte explícito para React Native.
Estandarizar según especificaciones de APIs web no solo es beneficioso sino esencial para el crecimiento de React Native, y se alinea con nuestra visión de Múltiples Plataformas y el proyecto react-strict-dom. La web ofrece una interfaz unificada a través de sus especificaciones, algo que actualmente falta en los módulos de la comunidad de React Native. Microsoft ha identificado alrededor de 200 APIs web esenciales que podrían implementarse primero para las plataformas que soportan: iOS, Android, Windows y macOS.
Animamos a los desarrolladores de bibliotecas a alinear sus APIs con especificaciones web siempre que sea posible, ya que esta estandarización mejorará la portabilidad del código y la experiencia del desarrollador entre plataformas.
Aunque la propuesta parece beneficiosa para el futuro de React Native, seguimos debatiendo los próximos pasos. Una preocupación es la gobernanza de las APIs y si deberían ubicarse en un repositorio separado de las implementaciones de plataforma. Otra cuestión es la posible divergencia de la especificación oficial cuando una plataforma permita comportamientos no especificados por el W3C. Necesitaríamos determinar cómo evitar incluir módulos innecesarios, por ejemplo con un plugin de Babel. Además, el alcance de esta iniciativa es considerable.
La sesión reforzó dos puntos clave: primero, existe un fuerte consenso en la comunidad de React Native para adoptar especificaciones compatibles con web cuando sea posible. Segundo, necesitamos establecer una estrategia técnica clara sobre cómo mantener estas implementaciones de APIs web por separado para diferentes plataformas. Microsoft junto con Callstack podrían refinar el RFC original y desarrollar una prueba de concepto para un número reducido de APIs como iniciativa comunitaria. Este enfoque incremental nos ayudará a validar el diseño y la experiencia del desarrollador antes de ampliar el alcance.
LeanCore 2.0
En 2019, el equipo de React Native inició la iniciativa Lean Core. El objetivo era abordar la superficie de la base de React Native, reduciendo APIs y componentes obsoletos. Desde entonces, los componentes y superficies de API de React Native han necesitado otra ronda de limpieza.
Actualmente existen muchos componentes que no se mantienen activamente y tienen alternativas comunitarias mejores. Además, hay componentes duplicados que eventualmente deberían consolidarse para mejorar la mantenibilidad.
En cuanto a las APIs, muchas de la capa JS están vinculadas a implementaciones nativas de iOS y Android, en lugar de ser verdaderamente independientes de la plataforma. Por ejemplo, Pressable incluye props como android_disableSound y android_ripple. Idealmente, los componentes de React Native deberían tener la menor superficie de API posible sin atarse a ninguna plataforma específica.
A medida que las plataformas Out-of-Tree crecen y son más adoptadas por el ecosistema, necesitamos un camino para reducir la superficie de componentes y APIs del núcleo de React Native. Esto disminuiría la carga del equipo central y facilitaría que los mantenedores de plataformas Out-of-Tree y bibliotecas se mantengan actualizados.
Como ventaja adicional, esto facilitaría que los desarrolladores de aplicaciones principiantes adopten React Native, ya que habría menos componentes duplicados y "trampas" que aprender. Cuando exista una alternativa comunitaria mejor, podremos orientar y animar a los desarrolladores a usar las opciones disponibles de la comunidad.
Durante la sesión, discutimos:
-
Las motivaciones de alto nivel de Lean Core y los beneficios para las partes involucradas (desarrolladores, mantenedores de bibliotecas, Meta)
-
Una vista agregada de qué componentes se usan en aplicaciones React Native reales en producción
-
Los criterios para determinar qué elementos son candidatos a ser eliminados del núcleo
-
Un plan de acción claro para ejecutar Lean Core 2.0 con:
- El proceso de alto nivel para la deprecación
- Manejo de casos donde Meta usa internamente componentes que tienen mejores alternativas comunitarias
Como siguiente paso, un grupo de colaboradores principales analizará recopilar más telemetría y datos, evaluará alternativas comunitarias y preparará un RFC que detalle los cambios propuestos.
Nitro Modules - Desbloqueo de componentes visuales mediante exposición de props como jsi::Values
Recientemente, Marc Rousavy presentó los Nitro Modules como enfoque alternativo para crear Native Modules. Los Nitro Modules utilizan interoperabilidad experimental entre C++ y Swift e incorporan mejoras que pueden aumentar el rendimiento en ciertos escenarios. Sin embargo, en esta sesión discutimos las compensaciones entre Nitro Modules y los TurboModules existentes.
Aunque los Nitro Modules ofrecen beneficios de rendimiento, también tienen limitaciones y consideraciones que abordar. Por ejemplo, el uso de funciones experimentales de interoperabilidad podría introducir complejidad o problemas de compatibilidad inexistentes en TurboModules. Nuestra discusión se centró en estas compensaciones y el potencial de integrar mejoras de Nitro Modules en React Native Core, lo que permitiría módulos más eficientes para todos.
Plataformas Out-of-Tree y CocoaPods
Las plataformas Out-of-Tree muestran todo el potencial de React Native, permitiendo compartir una base de código JS entre plataformas en dispositivos móviles, escritorio o incluso dispositivos VR/XR. Actualmente, crear estas plataformas no es sencillo: no existen pautas sobre cómo deben crearse, desarrollarse ni mantenerse. Además, React Native Core está vinculado principalmente a Android e iOS. Futuramente podríamos buscar un escenario donde todas las plataformas se traten por igual e interactúen con un núcleo C++/JS mediante APIs comunes.
En esta sesión, mantenedores de distintas plataformas discutieron problemas, desafíos y posibles soluciones para unificar la creación y mantenimiento de nuevas plataformas Out-of-Tree.
Otro aspecto fue discutir CocoaPods y planes futuros para gestionar dependencias nativas. Recientemente, el equipo de CocoaPods anunció que entrará en modo mantenimiento sin nuevas mejoras importantes. Durante la sesión evaluamos alternativas, sus pros/contras y cómo sería una migración.
React Native en escritorio
Steven y Saad de Microsoft, mantenedores de react-native-windows y react-native-macos, organizaron una sesión para recopilar feedback sobre plataformas de escritorio. Los temas incluyeron aumentar la adopción de React Native para escritorio (como flujos dedicados en Visual Studio o integración con Nx), y cómo mejorar el soporte para Expo, un obstáculo recurrente para mayor adopción.
Existe gran disparidad en módulos comunitarios para macOS y Windows, principalmente porque el código iOS es compatible con macOS mientras RNW requiere implementaciones personalizadas. Al trabajar en la Nueva Arquitectura para React Native en Windows, el equipo ve potencial en módulos C++ para compartir más código entre plataformas, lo que facilitaría desarrollar para escritorio. Cabe destacar que Software Mansion está agregando soporte para escritorio en sus módulos populares como React Native Screens, Gesture Handler y Reanimated.
Seguimos impresionados por cómo varias horas de trabajo conjunto durante dos días generaron tanto intercambio de conocimientos y polinización cruzada de ideas. En esta cumbre plantamos semillas para iniciativas que mejorarán y remodelarán el ecosistema de React Native.
Si te interesa unirte al desarrollo de React Native, participa en nuestras iniciativas abiertas y lee la guía de contribución en nuestro sitio. ¡Esperamos conocerte en persona en el futuro!