Estado de React Native 2018
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →
Ha pasado tiempo desde nuestra última actualización sobre el estado de React Native.
En Facebook, usamos React Native más que nunca para proyectos importantes. Marketplace, una de nuestras soluciones más populares, es una pestaña principal de nuestra aplicación mensual usada por 800 millones de personas. Desde su creación en 2015, todo Marketplace se ha construido con React Native, incluyendo más de cien vistas de pantalla completa en distintas secciones de la app.
También empleamos React Native en nuevas áreas de la aplicación. Quienes vieron el evento F8 del mes pasado reconocerán Donaciones de Sangre, Respuesta ante Crisis, Accesos Directos de Privacidad y Chequeos de Bienestar: todas funciones recientes desarrolladas con React Native. Los proyectos externos a la app principal de Facebook también usan React Native. El nuevo visor VR Oculus Go incluye una app móvil complementaria totalmente construida con React Native, sin mencionar que React VR potencia experiencias dentro del propio dispositivo.
Naturalmente, también utilizamos otras tecnologías para nuestras apps. Litho y ComponentKit son bibliotecas que empleamos extensivamente; ambas ofrecen una API de componentes similar a React para construir pantallas nativas. Nunca fue objetivo de React Native reemplazar otras tecnologías: nos enfocamos en mejorarlo, pero nos complace ver equipos adoptar conceptos como la recarga instantánea para código no JavaScript.
Arquitectura
Al iniciar React Native en 2013, diseñamos un único "puente" entre JavaScript y nativo que fuera asíncrono, serializable y por lotes. Así como React DOM convierte actualizaciones de estado en llamadas imperativas a APIs del DOM como document.createElement(attrs) y .appendChild(), React Native devuelve un mensaje JSON con mutaciones a ejecutar, tipo [["createView", attrs], ["manageChildren", ...]]. Diseñamos el sistema para nunca depender de respuestas síncronas y garantizar que todo fuera serializable a JSON. Esto nos dio flexibilidad: sobre esta arquitectura construimos herramientas como la depuración en Chrome, que ejecuta código JavaScript asíncronamente vía WebSocket.
Tras 5 años, descubrimos que estos principios iniciales dificultan ciertas funcionalidades. Un puente asíncrono impide integrar lógica JavaScript con APIs nativas que requieren respuestas síncronas. Un puente por lotes encola llamadas nativas, complicando la invocación de funciones nativas desde apps React Native. Y un puente serializable implica copiar datos innecesariamente en lugar de compartir memoria directamente. Para apps completamente en React Native, estas limitaciones son manejables. Pero en apps con integración compleja entre código nativo y React Native, resultan frustrantes.
Estamos reestructurando React Native a gran escala para flexibilizar el framework y mejorar su integración con infraestructura nativa en apps híbridas JavaScript/nativas. Con este proyecto aplicaremos aprendizajes de los últimos 5 años y modernizaremos gradualmente nuestra arquitectura. Reescribimos internos de React Native, pero la mayoría de cambios son internos: las apps existentes seguirán funcionando con pocas o ninguna modificación.
Para hacer React Native más ligero y que se integre mejor en aplicaciones nativas existentes, esta reestructuración incluye tres cambios internos importantes. Primero, estamos modificando el modelo de subprocesos. En lugar de requerir que cada actualización de UI realice trabajo en tres hilos diferentes, será posible llamar sincrónicamente a JavaScript en cualquier hilo para actualizaciones de alta prioridad, manteniendo el trabajo de baja prioridad fuera del hilo principal para preservar la capacidad de respuesta. Segundo, incorporaremos capacidades de renderizado asíncrono en React Native para permitir múltiples prioridades de renderizado y simplificar el manejo de datos asíncronos. Finalmente, simplificaremos nuestro puente para hacerlo más rápido y liviano; las llamadas directas entre nativo y JavaScript serán más eficientes y facilitarán la creación de herramientas de depuración como trazas de pila entre lenguajes.
Una vez completados estos cambios, serán posibles integraciones más estrechas. Actualmente, es imposible incorporar navegación nativa y manejo de gestos, o componentes nativos como UICollectionView y RecyclerView sin soluciones complejas. Tras nuestras modificaciones al modelo de subprocesos, desarrollar estas características será directo.
Publicaremos más detalles sobre este trabajo más adelante este año, conforme se acerque su finalización.
Comunidad
Junto a la comunidad interna de Facebook, nos complace contar con una próspera comunidad de usuarios y colaboradores de React Native fuera de Facebook. Queremos apoyar más a esta comunidad, tanto mejorando la experiencia para los usuarios como facilitando las contribuciones al proyecto.
Así como nuestros cambios arquitectónicos ayudarán a React Native a interoperar mejor con otras infraestructuras nativas, React Native debería ser más delgado en el lado de JavaScript para integrarse mejor con su ecosistema, lo que incluye hacer intercambiables la VM y el empaquetador. Reconocemos que el ritmo de los cambios disruptivos puede ser difícil de seguir, por lo que buscamos formas de reducir las versiones mayores. Finalmente, sabemos que algunos equipos necesitan documentación más exhaustiva en temas como optimización de arranque, donde aún no hemos plasmado nuestra experiencia. Esperen ver estos cambios durante el próximo año.
Si usas React Native, eres parte de nuestra comunidad; sigue compartiendo cómo podemos mejorarlo para ti.
React Native es solo una herramienta en el arsenal de un desarrollador móvil, pero es una en la que creemos firmemente. La estamos mejorando cada día, con más de 2500 commits en el último año provenientes de más de 500 colaboradores.