Código y salud de la comunidad​

En los últimos seis meses, se realizaron 2800 commits en React Native por más de 550 colaboradores. 400 colaboradores de la comunidad crearon más de 1,150 Pull Requests, de los cuales se fusionaron 820 Pull Requests.

El número promedio de Pull Requests por día aumentó de tres a aproximadamente seis en este periodo, a pesar de haber separado el sitio web, la CLI y varios módulos de React Native mediante el esfuerzo Lean Core. La cantidad promedio de pull requests abiertos ahora está por debajo de 25, y generalmente respondemos con sugerencias y revisiones en horas o días.

Contribuciones significativas de la comunidad​

Queremos destacar varias contribuciones recientes que consideramos excepcionales:

• Accesibilidad: React Native 0.60 incluirá mejoras significativas en las API de accesibilidad para Android e iOS. Todas las nuevas funciones utilizan directamente las API de las plataformas subyacentes, por lo que se integrarán con tecnologías de asistencia nativas en ambos sistemas. Agradecemos a Marc Mulcahy, Alan Kenyon, Estevão Lucas, Sam Mathias Weggersen y Janic Duplessis por sus aportes:

  • Roles y estados de accesibilidad adicionales y una nueva API de estados de accesibilidad. Se agregaron roles de accesibilidad faltantes para varios componentes y una nueva API para mejor soporte web futuro.
  • AccessibilityInfo.announceForAccessibility. Se añadió soporte para Android (antes solo disponible en iOS).
  • Soporte extendido para acciones de accesibilidad. Se implementaron callbacks para manejar acciones definidas por el usuario.
  • Soporte para flags de accesibilidad en iOS y soporte para "reducir movimiento".
  • Mejoras en accesibilidad de teclado para Android. Se agregó una prop clickable y un callback onClick para invocar acciones mediante navegación por teclado (nota: pronto se renombrará a focusable).
  • Uso de CALayers para renderizar texto. Se solucionó un problema que hacía desaparecer texto escalado en iOS.

• Nueva pantalla de aplicación: La comunidad diseñó una nueva pantalla para aplicaciones implementada en la versión 0.60. Esta pantalla es lo primero que ven los nuevos usuarios de React Native. Ahora redirige a los principiantes hacia la documentación y su diseño coincide con el próximo rediseño de nuestro sitio web 🌟. ¡Un enorme agradecimiento a Orta, Adam Shurson, Glauber Castro, Karan Singh, Eli Perkins, Lucas Bento y Eric Lewis por su trabajo y colaboración!

  • Puedes ver la nueva pantalla en la serie de videos “React Native Show“.

• Tipos de TurboMódulos: El nuevo sistema TurboModules requiere tipos para todos los módulos nativos para garantizar operaciones seguras en cuanto a tipos en el entorno nativo. En poco más de dos semanas, la comunidad envió alrededor de 40 Pull Requests para completar este trabajo para módulos nativos con tipado de flujo. Además de las personas ya mencionadas anteriormente, nos gustaría agradecer a Michał Chudziak, Michał Pierzchała, Wojtek Szafraniec, y Jean Regisser y a todos los demás que enviaron uno o más Pull Requests.

• Haste: Desde 2015, React Native utilizó el sistema de módulos "haste" que permite importar módulos mediante un identificador global en lugar de una ruta relativa, lo cual es conveniente pero no es muy compatible con muchas herramientas. James Ide propuso eliminar haste, de manera similar a cómo React eliminó haste hace muchos años. Planificó todo el trabajo mediante una tarea paraguas y envió 18 Pull Requests para hacerlo realidad. ¡Consulta su hilo de Twitter para obtener más información!

• Fragmentos de Android: La propuesta de John Shelley para hacer que React Native funcione mediante Fragmentos de Android se ha fusionado y estará disponible en la versión 0.61. Lee más sobre los Fragmentos de Android aquí.

Lean Core​

La motivación principal de Lean Core ha sido separar módulos de React Native en repositorios independientes para que puedan recibir un mejor mantenimiento. En solo seis meses, repositorios como WebView, NetInfo, AsyncStorage, el sitio web y la CLI recibieron más de 800 Pull Requests en conjunto. Además de un mejor mantenimiento, estos proyectos también pueden lanzarse de forma independiente con más frecuencia que el propio React Native.

También hemos aprovechado la oportunidad para eliminar polyfills obsoletos y componentes heredados de React Native. En el pasado, los polyfills eran necesarios para admitir características del lenguaje como Map y Set en versiones antiguas de JavaScriptCore (JSC). Ahora que React Native incluye una nueva versión, estos polyfills se han eliminado.

Este trabajo aún está en curso y aún quedan muchas cosas por separar o eliminar tanto en el lado nativo como en JavaScript, pero hay indicios tempranos de que hemos logrado revertir la tendencia de aumentar el área de superficie y el tamaño de la aplicación: Por ejemplo, al observar el paquete JavaScript, hace aproximadamente un año en la versión 0.54, el tamaño del paquete JavaScript de React Native era de 530kb y creció a 607kb (+77kb) en la versión 0.57 en solo 6 meses. ¡Ahora estamos viendo una reducción del tamaño del paquete de 28kb, hasta 579kb en la rama principal, una diferencia de más de 100kb!

A medida que concluimos la primera iteración del esfuerzo Lean Core, nos esforzaremos por ser más intencionales con las nuevas API agregadas a React Native y evaluaremos continuamente formas de hacer React Native más pequeño y rápido, así como encontrar maneras de empoderar a la comunidad para que se haga cargo de varios componentes.

Comentarios de los Usuarios​

Hace seis meses preguntamos a la comunidad "¿Qué es lo que no te gusta de React Native?", lo que dio una buena visión general de los problemas que enfrentan los desarrolladores. Respondimos a esa publicación hace unos meses y ahora es momento de resumir el progreso en los principales temas:

• Actualizaciones: La comunidad de React Native se unió para implementar múltiples mejoras en la experiencia de actualización: autolinking, un mejor comando de actualización mediante rn-diff-purge, y un sitio web de ayuda para actualizaciones (próximamente). También nos aseguraremos de comunicar cambios disruptivos y nuevas funciones publicando artículos en el blog para cada versión principal. Muchas de estas mejoras facilitarán significativamente futuras actualizaciones más allá de la versión 0.60.

• Soporte/Incertidumbre: Muchos expresaron frustración por la falta de actividad en los Pull Requests y la incertidumbre sobre la inversión de Facebook en React Native. Como hemos mostrado anteriormente, podemos afirmar con confianza que estamos preparados para recibir muchos más Pull Requests y esperamos con entusiasmo vuestras propuestas y contribuciones.

• Rendimiento: React Native 0.59 incluyó una nueva y mucho más rápida versión de JavaScriptCore (JSC). Paralelamente, hemos trabajado para facilitar la activación por defecto de inline-requires y tenemos más actualizaciones emocionantes para los próximos meses.

• Documentación: Recientemente iniciamos un esfuerzo para renovar y reescribir toda la documentación de React Native. Si quieres contribuir, ¡nos encantaría contar con tu ayuda!

• Advertencias en Xcode: Eliminamos todas las advertencias existentes y nos esforzamos por no introducir nuevas.

• Hot Reloading: El equipo de React está desarrollando un nuevo sistema de hot reloading que pronto se integrará en React Native.

Lamentablemente aún no hemos podido mejorar todo:

• Depuración: Corregimos muchos errores inconvenientes que enfrentábamos diariamente, pero no hemos avanzado tanto como nos gustaría en este aspecto. Reconocemos que la depuración en React Native no es óptima y priorizaremos mejorarla en el futuro.

• Enlaces simbólicos (symlinks) en Metro: Aún no hemos implementado una solución simple y directa para esto. Sin embargo, usuarios de React Native compartieron diversas soluciones alternativas que podrían funcionarte.

Dada la gran cantidad de cambios en los últimos seis meses, nos gustaría hacerte la misma pregunta nuevamente. Si estás usando la última versión de React Native y tienes comentarios, por favor participa en nuestra nueva edición de "¿Qué es lo que no te gusta de React Native?"

Integración Continua​

Facebook fusiona todos los Pull Requests y cambios internos directamente en su repositorio primero, y luego sincroniza los commits con GitHub. La infraestructura de Facebook difiere de los servicios comunes de integración continua, y no todas las pruebas de código abierto se ejecutaban internamente. Esto causaba que los commits sincronizados con GitHub frecuentemente rompieran pruebas en código abierto, requiriendo mucho tiempo para solucionarlo.

Héctor Ramos del equipo de React Native dedicó los últimos dos meses a mejorar los sistemas de integración continua tanto en Facebook como en GitHub. La mayoría de las pruebas de código abierto ahora se ejecutan antes de confirmar cambios en React Native en Facebook, lo que mantendrá estable la CI en GitHub durante las sincronizaciones.

Próximos pasos​

¡Asegúrate de ver nuestras charlas sobre el futuro de React Native! En los próximos meses, miembros del equipo de React Native en Facebook hablarán en Chain React y en React Native EU. Además, mantente atento a nuestra próxima versión, la 0.60, que está a la vuelta de la esquina. Va a ser emocionante ✨

Esta semana, Eli White dio una charla en F8 2019 sobre React Native en las aplicaciones de Android e iOS de Facebook. Estamos emocionados de compartir lo que hemos estado haciendo durante los últimos dos años y nuestros próximos pasos.

Puedes ver el video en el sitio para desarrolladores de Facebook:

Puntos destacados de la charla:​

• Durante 2017 y 2018 nos enfocamos en el producto más grande de React Native: Facebook Marketplace. Colaboramos con el equipo de Marketplace para mejorar la calidad y añadir elementos que deleiten a los usuarios. Hoy, Marketplace es uno de los productos de mayor calidad en la app de Facebook tanto en Android como en iOS.

• El rendimiento de Marketplace también representó un gran desafío, especialmente en dispositivos Android de gama media. ¡Redujimos el tiempo de inicio en más del 50% durante el último año con más mejoras en camino! Las mejoras más significativas se están integrando en React Native y llegarán a la comunidad más adelante este año.

• Tenemos la confianza de que podemos construir aplicaciones de alta calidad y rendimiento que Facebook necesita con React Native. Esta confianza nos permite invertir en apuestas más grandes, como replantear el núcleo de React Native.

• Microsoft admite y utiliza React Native para Windows, permitiendo aprovechar conocimientos y código existentes para renderizar en la Plataforma Universal de Windows. No te pierdas Microsoft Build la próxima semana para escuchar más sobre esto.

Podcast React Radio sobre código abierto​

La charla de Eli concluye hablando de nuestro trabajo reciente en código abierto. Publicamos una actualización en marzo y recientemente Nader Dabit y Gant Laborde invitaron a Christoph a su podcast React Native Radio para conversar sobre React Native en código abierto.

Puntos destacados del podcast:​

• Hablamos sobre cómo el equipo de React Native en Facebook aborda el código abierto y cómo construimos una comunidad sostenible que escala para un proyecto del tamaño de React Native.

• Estamos en camino de eliminar múltiples módulos como parte del esfuerzo Lean Core. Módulos como WebView y la CLI de React Native han recibido más de 100 Pull Requests desde su extracción.

• A continuación, nos enfocaremos en renovar el sitio web y documentación de React Native. ¡Mantente atento!

Podrás encontrar el episodio en tu aplicación de podcasts favorita pronto o escuchar la grabación directamente aquí:

¡Bienvenidos al lanzamiento de React Native 0.59! Esta es otra gran versión con 644 commits de 88 colaboradores. Las contribuciones también vienen en otras formas, así que gracias por mantener issues, fomentar comunidades y enseñar sobre React Native. Este mes trae varios cambios muy esperados, y esperamos que los disfruten.

🎣 Los Hooks han llegado​

Los React Hooks forman parte de este lanzamiento, permitiéndote reutilizar lógica con estado entre componentes. Hay mucho entusiasmo sobre los hooks, pero si aún no los conoces, revisa estos excelentes recursos:

• Introducing Hooks explica por qué añadimos Hooks a React.
• Hooks at a Glance es un resumen rápido de los Hooks integrados.
• Building Your Own Hooks demuestra reutilización de código con Hooks personalizados.
• Making Sense of React Hooks explora nuevas posibilidades desbloqueadas por Hooks.
• useHooks.com muestra recetas y demos de Hooks mantenidas por la comunidad.

Asegúrate de probarlos en tus apps. Esperamos que encuentres la reutilización tan emocionante como nosotros.

📱 La JSC actualizada trae mejor rendimiento y soporte 64-bit en Android​

React Native usa JSC (JavaScriptCore) para ejecutar tu aplicación. La JSC en Android estaba desactualizada, lo que significaba que muchas características modernas de JavaScript no eran compatibles. Peor aún, su rendimiento era inferior comparado con la JSC moderna de iOS. Con este lanzamiento, eso cambia.

Gracias al increíble trabajo de @DanielZlotin, @dulmandakh, @gengjiawen, @kmagiera y @kudo, JSC se ha actualizado. Esto incluye soporte 64-bit, compatibilidad con JavaScript moderno y grandes mejoras de rendimiento. Reconocimiento también por hacer esto un proceso mantenible para aprovechar futuras mejoras de WebKit sin tanto esfuerzo, y gracias a Software Mansion y Expo por hacer posible este trabajo.

💨 Lanzamientos más rápidos con inline requires​

Queremos ayudar a tener apps React Native performantes por defecto y estamos trabajando para llevar las optimizaciones de Facebook a la comunidad. Las aplicaciones cargan recursos bajo demanda sin ralentizar el inicio. Esta función se llama "inline requires", permitiendo a Metro identificar componentes para carga diferida. Las apps con arquitecturas de componentes profundas y variadas verán mayor mejora.

Necesitamos que la comunidad pruebe esto antes de activarlo por defecto. Al actualizar a 0.59, verás un nuevo archivo metro.config.js; cambia la opción a true y danos tu feedback! Lee más sobre inline requires en la documentación de rendimiento para evaluar tu app.

🚅 Lean core está en marcha​

React Native es un proyecto grande y complejo con un repositorio intrincado. Esto hace que la base de código sea menos accesible para colaboradores, difícil de probar y engorrosa como dependencia de desarrollo. Lean Core es nuestro esfuerzo para abordar estos problemas migrando código a bibliotecas separadas para una mejor gestión. Las últimas versiones han mostrado los primeros pasos de este proceso, pero es hora de ponernos serios.

Notarás que componentes adicionales ahora están oficialmente obsoletos. Esta es una gran noticia, ya que ahora existen responsables que mantienen activamente estas funcionalidades. Presta atención a los mensajes de advertencia y migra a las nuevas bibliotecas para estas características, porque se eliminarán en una versión futura. A continuación hay una tabla que indica el componente, su estado y dónde puedes migrar su uso.

Durante los próximos meses, muchos más componentes seguirán este camino hacia un núcleo más ligero. Buscamos ayuda con esto — visita el paraguas de Lean Core para colaborar.

👩🏽‍💻 Mejoras en la CLI​

Las herramientas de línea de comandos de React Native son el punto de entrada de los desarrolladores al ecosistema, pero tenían problemas de larga data y carecían de soporte oficial. Las herramientas CLI se han trasladado a un nuevo repositorio, y un grupo dedicado de mantenedores ya ha realizado mejoras significativas.

Los logs ahora tienen un formato mucho mejor. Los comandos se ejecutan casi instantáneamente — notarás la diferencia inmediatamente:

🚀 Actualización a 0.59​

Escuchamos vuestros comentarios sobre el proceso de actualización de React Native y estamos tomando medidas para mejorar la experiencia en futuras versiones. Para actualizar a 0.59, recomendamos usar rn-diff-purge para identificar los cambios entre vuestra versión actual de React Native y 0.59, luego aplicar esos cambios manualmente. Una vez actualizado vuestro proyecto a 0.59, podréis usar el comando mejorado react-native upgrade (¡basado en rn-diff-purge!) para actualizar a 0.60 y versiones posteriores a medida que estén disponibles.

🔨 Cambios disruptivos​

El soporte para Android en 0.59 se ha actualizado siguiendo las últimas recomendaciones de Google, lo que podría causar problemas en aplicaciones existentes. Este problema podría manifestarse como un fallo en tiempo de ejecución con el mensaje: "You need to use a Theme.AppCompat theme (or descendant) with this activity". Recomendamos actualizar el archivo AndroidManifest.xml de vuestro proyecto, asegurando que el valor android:theme sea un tema AppCompat (como @style/Theme.AppCompat.Light.NoActionBar).

El comando react-native-git-upgrade se ha eliminado en 0.59 en favor del comando mejorado react-native upgrade.

🤗 Agradecimientos​

Muchos nuevos colaboradores ayudaron con habilitar la generación de código nativo a partir de tipos Flow y resolver advertencias de Xcode - estas son excelentes formas de aprender cómo funciona React Native y contribuir al bien común. ¡Gracias! Estad atentos a problemas similares en el futuro.

Aunque estos son los aspectos más destacados que hemos señalado, hay muchos otros que te entusiasmarán. Para ver todas las actualizaciones, consulta el registro de cambios. 0.59 es un lanzamiento enorme: estamos deseando que lo pruebes.

Tenemos aún más mejoras planeadas para lo que resta del año. ¡Mantente atento!

Ryan y todo el equipo central de React Native

Anunciamos nuestra hoja de ruta de código abierto de React Native en el cuarto trimestre de 2018, tras decidir invertir más en la comunidad de código abierto de React Native.

Para nuestro primer hito, nos centramos en identificar y mejorar los aspectos más visibles de nuestra comunidad. Nuestros objetivos eran reducir las pull requests pendientes, disminuir la superficie del proyecto, identificar los problemas principales de los usuarios y establecer pautas para la gestión comunitaria.

En los últimos dos meses, logramos más progreso del esperado. Sigue leyendo para conocer los detalles:

Pull Requests​

Para construir una comunidad saludable, debemos responder rápidamente a las contribuciones de código. En años anteriores, despriorizamos la revisión de contribuciones comunitarias y acumulamos 280 pull requests (diciembre 2018). En el primer hito, redujimos el número de pull requests abiertas a ~65. Simultáneamente, el promedio diario de pull requests abiertas aumentó de 3.5 a 7, lo que significa que hemos gestionado cerca de 600 pull requests en los últimos tres meses.

Fusionamos casi dos tercios y cerramos un tercio de las pull requests. Se cerraron sin fusionar cuando estaban obsoletas, eran de baja calidad o aumentaban innecesariamente la superficie del proyecto. La mayoría de las pull requests fusionadas corregían errores, mejoraban la paridad multiplataforma o introducían nuevas funcionalidades. Contribuciones destacadas incluyen mejoras en seguridad de tipos y el trabajo continuo para soportar AndroidX.

En Facebook, ejecutamos React Native desde la rama principal (master), por lo que probamos todos los cambios antes de que lleguen a una versión estable de React Native. De todas las pull requests fusionadas, solo seis causaron problemas: cuatro afectaron únicamente al desarrollo interno y dos fueron detectadas en estado de candidata a versión estable.

Una de las contribuciones comunitarias más visibles fue la pantalla "RedBox" actualizada. Es un buen ejemplo de cómo la comunidad está haciendo más amigable la experiencia del desarrollador.

Lean Core​

React Native actualmente tiene una superficie muy amplia con muchas abstracciones sin mantenimiento que no usamos mucho en Facebook. Estamos trabajando en reducir la superficie para hacer React Native más pequeño y permitir que la comunidad cuide mejor de las abstracciones poco utilizadas en Facebook.

En el primer hito, pedimos ayuda a la comunidad para el proyecto Lean Core. La respuesta fue abrumadora y apenas pudimos seguir el ritmo del progreso. ¡Mira todo el trabajo completado en menos de un mes!

Lo que más nos entusiasma es que los mantenedores se han involucrado corrigiendo problemas de larga data, añadiendo pruebas y dando soporte a funcionalidades solicitadas desde hace tiempo. Estos módulos están recibiendo más apoyo que nunca dentro de React Native, demostrando que es un gran paso para la comunidad. Ejemplos de estos proyectos son WebView que ha recibido muchas pull requests desde su extracción, y la CLI que ahora es mantenida por miembros de la comunidad y ha recibido mejoras y correcciones muy necesarias.

Problemas principales de los usuarios​

En diciembre, preguntamos a la comunidad qué les desagradaba de React Native. Consolidamos las respuestas y respondimos a cada uno de los problemas. Afortunadamente, muchos de los problemas que enfrenta nuestra comunidad también son relevantes en Facebook. En nuestro próximo hito, planeamos abordar algunos de los principales desafíos.

Uno de los problemas más votados fue la experiencia al actualizar a versiones más recientes de React Native. Lamentablemente, esto no es algo que experimentemos internamente porque ejecutamos React Native desde la rama principal. Afortunadamente, miembros de la comunidad ya han tomado la iniciativa para resolver este problema:

• Michał Pierzchała de Callstack mejoró react-native upgrade utilizando rn-diff-purge internamente. También actualizamos el sitio web para eliminar instrucciones de actualización obsoletas.

• Planeamos recomendar CocoaPods por defecto para proyectos iOS, lo que reducirá la inestabilidad en archivos de proyecto al actualizar React Native. Esto facilitará la instalación y vinculación de módulos de terceros, algo aún más importante en el contexto de Lean Core ya que esperamos que los proyectos vinculen más módulos por defecto.

Lanzamiento de la versión 0.59​

Sin la ayuda de la comunidad de React Native, especialmente Mike Grabowski y Lorenzo Sciandra, no podríamos gestionar los lanzamientos. Queremos mejorar el proceso de gestión de versiones y planeamos involucrarnos más a partir de ahora:

• Colaboraremos con miembros de la comunidad para crear una publicación de blog para cada lanzamiento importante.

• Mostraremos los cambios disruptivos directamente en la CLI cuando los usuarios actualicen a nuevas versiones.

• Reduciremos el tiempo necesario para realizar un lanzamiento. Estamos explorando formas de aumentar las pruebas automatizadas y crear un plan de pruebas manuales mejorado.

Muchos de estos planes se incorporarán en el próximo lanzamiento de React Native 0.59. La versión 0.59 incluirá React Hooks, una nueva versión 64-bit de JavaScriptCore para Android, y numerosas mejoras de rendimiento y funcionalidad. Actualmente está disponible como candidata a lanzamiento y se espera que sea estable en las próximas dos semanas.

Próximos pasos​

Durante los próximos dos meses, continuaremos gestionando pull requests para mantener el ritmo mientras comenzamos a reducir la cantidad de issues pendientes en GitHub. Seguiremos reduciendo la superficie de React Native mediante el proyecto Lean Core. Planeamos abordar 5 de los principales problemas de la comunidad. A medida que finalicemos las pautas comunitarias, centraremos nuestra atención en el sitio web y la documentación.

Estamos muy entusiasmados por recibir a más de diez colaboradores de nuestra comunidad en Facebook Londres en marzo para impulsar varios de estos esfuerzos. Nos alegra que utilicen React Native y esperamos que noten las mejoras en las que estamos trabajando durante 2019. Volveremos con otra actualización en unos meses y ¡mientras tanto estaremos fusionando sus pull requests! ⚛️✌️

En 2018, la comunidad de React Native realizó varios cambios en la forma en que desarrollamos y nos comunicamos sobre React Native. Creemos que dentro de unos años miraremos atrás y veremos que este cambio fue un punto de inflexión para React Native.

Mucha gente está entusiasmada con la reescritura de la arquitectura de React Native, ampliamente conocida como Fabric. Entre otras cosas, esto solucionará limitaciones fundamentales en la arquitectura de React Native y preparará a React Native para el éxito en el futuro junto con JSI y TurboModules.

El cambio más grande en 2018 fue empoderar a la comunidad de React Native. Desde el principio, Facebook animó a desarrolladores de todo el mundo a participar en el proyecto de código abierto de React Native. Desde entonces, surgieron varios colaboradores principales para manejar, entre otras cosas, el proceso de lanzamiento.

Estos miembros dieron algunos pasos sustanciales para que toda la comunidad tuviera más capacidad para moldear el futuro de este proyecto con los siguientes recursos:

react-native-releases 📬​

Este repositorio, creado en enero, tiene el doble propósito de permitir que todos puedan mantenerse al día con los nuevos lanzamientos de manera más colaborativa y abrió la conversación sobre qué formaría parte de un determinado lanzamiento a cualquier persona que quisiera sugerir un cherry-pick (como en 0.57.8 y todas sus versiones anteriores).

Esta ha sido la fuerza impulsora detrás del abandono de un ciclo de lanzamiento mensual y el enfoque de "soporte a largo plazo" que se usa actualmente para la versión 0.57.x.

La mitad del mérito por llegar a estas decisiones se debe al otro repositorio creado este año:

discussions-and-proposals 🗣​

Este repositorio, creado en julio, amplió la idea de un entorno más abierto para conversaciones sobre React Native. Anteriormente, esta necesidad se manejaba con issues etiquetados como For Discussion en el repositorio principal, pero queríamos expandir esta estrategia a un enfoque de RFC que otras bibliotecas tienen (por ejemplo, React).

Este experimento encontró inmediatamente su papel en el ciclo de vida de React Native. El equipo de Facebook ahora está utilizando el proceso de RFC de la comunidad para discutir qué se podría mejorar en React Native y coordinar los esfuerzos en torno al proyecto Lean Core, entre otras discusiones interesantes.

@ReactNativeComm 🐣​

Somos conscientes de que nuestro enfoque para comunicar estos esfuerzos no ha sido tan efectivo como nos hubiera gustado, y en un intento de facilitarles a todos el seguimiento de todo lo que sucede en la comunidad de React Native (desde lanzamientos hasta discusiones activas), creamos una nueva cuenta de Twitter en la que pueden confiar: @ReactNativeComm.

Si no estás en esa red social, recuerda que siempre puedes ver los repositorios a través de GitHub; esta función mejoró en los últimos meses con la posibilidad de ser notificado solo por lanzamientos, por lo que deberías considerar usarla de todos modos.

Lo que espera por delante 🎓​

Durante los últimos 7-8 meses, los colaboradores principales mejoraron la organización React Native Community en GitHub para asumir más responsabilidad en el desarrollo de React Native y mejorar la colaboración con Facebook. Pero esto siempre careció de la estructura formal que proyectos similares pueden tener establecida.

Esta organización puede servir de ejemplo para toda la comunidad de desarrolladores al establecer estándares para todos los paquetes/repositorios que alberga, proporcionando un lugar centralizado donde los mantenedores puedan ayudarse mutuamente y contribuir con código de calidad que cumpla con los estándares acordados por la comunidad.

A principios de 2019, tendremos implementadas estas nuevas directrices. Comparte tu opinión en la discusión dedicada.

Confiamos que con estos cambios la comunidad será más colaborativa, de modo que cuando alcancemos la versión 1.0, todos podremos seguir creando aplicaciones (aún más) increíbles aprovechando este esfuerzo conjunto 🤗

Espero que estés tan entusiasmado como nosotros con el futuro de esta comunidad. Nos emociona ver tu participación, ya sea en las conversaciones de los repositorios mencionados o mediante el excelente código que producirás.

¡Feliz codificación!

Este año, el equipo de React Native se ha enfocado en una re-arquitectura a gran escala de React Native. Como mencionó Sophie en su publicación sobre el estado de React Native, hemos esbozado un plan para apoyar mejor a la creciente comunidad de usuarios y colaboradores de React Native fuera de Facebook. Ahora es momento de compartir más detalles sobre nuestro trabajo. Antes de hacerlo, me gustaría exponer nuestra visión a largo plazo para React Native en código abierto.

Nuestra visión para React Native es...

• Un repositorio de GitHub saludable. Los problemas y solicitudes de extracción se gestionan en un plazo razonable.

  • Mayor cobertura de pruebas.
  • Los commits sincronizados desde el repositorio interno de Facebook no deben romper las pruebas de código abierto.
  • Una mayor escala de contribuciones significativas de la comunidad.

• APIs estables, que faciliten la integración con dependencias de código abierto.

  • Facebook utiliza la misma API pública que el código abierto.
  • Lanzamientos de React Native que sigan el versionado semántico.

• Un ecosistema vibrante. ViewManagers de alta calidad, módulos nativos y soporte multiplataforma mantenidos por la comunidad.

• Documentación excelente. Enfocada en ayudar a los usuarios a crear experiencias de alta calidad, con documentos de referencia de API actualizados.

Hemos identificado las siguientes áreas prioritarias para alcanzar esta visión.

✂️ Lean Core (Núcleo Ligero)​

Nuestro objetivo es reducir la superficie de React Native eliminando componentes no esenciales y sin uso. Transferiremos componentes no esenciales a la comunidad para permitirle avanzar más rápido. La superficie reducida facilitará la gestión de contribuciones a React Native.

WebView es un ejemplo de componente que transferimos a la comunidad. Estamos trabajando en un flujo que permita a los equipos internos seguir usando estos componentes tras eliminarlos del repositorio. Hemos identificado docenas de componentes adicionales cuya propiedad transferiremos a la comunidad.

🎁 Código Abierto de los Internos y 🛠Actualización de Herramientas​

La experiencia de desarrollo de React Native para equipos de producto en Facebook puede diferir bastante de la de código abierto. Herramientas populares en la comunidad de código abierto no se usan en Facebook. Puede existir una herramienta interna que cumple el mismo propósito. En algunos casos, los equipos de Facebook se han acostumbrado a herramientas que no existen fuera de la compañía. Estas diferencias plantean desafíos al liberar como código abierto nuestro próximo trabajo de arquitectura.

Trabajaremos en liberar algunas de estas herramientas internas. También mejoraremos el soporte para herramientas populares en la comunidad de código abierto. Esta es una lista no exhaustiva de proyectos que abordaremos:

• Liberar JSI como código abierto y permitir que la comunidad utilice sus propias máquinas virtuales JavaScript, reemplazando el JavaScriptCore inicial de RN. Cubriremos qué es JSI en una futura publicación; mientras tanto puedes aprender más sobre JSI en la charla de Parashuram en React Conf.

• Soporte para bibliotecas de 64 bits en Android.

• Habilitar depuración bajo la nueva arquitectura.

• Mejorar soporte para CocoaPods, Gradle, Maven y el nuevo sistema de compilación de Xcode.

✅ Infraestructura de Pruebas​

Cuando los ingenieros de Facebook publican código, se considera seguro si pasa todas las pruebas. Estas pruebas identifican si un cambio podría romper alguna de nuestras propias implementaciones de React Native. Sin embargo, existen diferencias en cómo Facebook utiliza React Native. Esto nos ha permitido romper involuntariamente React Native en código abierto.

Reforzaremos nuestras pruebas internas para garantizar que se ejecuten en un entorno lo más cercano posible al código abierto. Esto ayudará a evitar que el código que rompa estas pruebas llegue a código abierto. También trabajaremos en infraestructura para mejorar las pruebas del repositorio principal en GitHub, permitiendo que futuras pull requests incluyan pruebas fácilmente.

Combinado con la reducción de la superficie de código, esto permitirá a los colaboradores fusionar pull requests más rápido y con confianza.

📜 API Pública​

Facebook consumirá React Native a través de la API pública, igual que el código abierto, para reducir cambios disruptivos no intencionales. Hemos comenzado a convertir sitios de llamadas internas para abordar esto. Nuestro objetivo es converger en una API pública estable, llevando a la adopción de versionamiento semántico en la versión 1.0.

📣 Comunicación​

React Native es uno de los principales proyectos de código abierto en GitHub por cantidad de colaboradores. Eso nos hace muy felices y queremos mantenerlo. Continuaremos trabajando en iniciativas que fomenten la participación de colaboradores, como mayor transparencia y discusión abierta. La documentación es lo primero que encuentra alguien nuevo en React Native, pero no ha sido prioridad. Queremos solucionarlo comenzando con:

• Recuperar la documentación de referencia API generada automáticamente
• Crear contenido adicional enfocado en experiencias de usuario de calidad
• Mejorar nuestras notas de lanzamiento

Cronograma​

Planeamos implementar estos proyectos durante el próximo año aproximadamente. Algunos esfuerzos ya están en curso, como JSI que ya está en código abierto. Otros tomarán más tiempo, como reducir la superficie de código. Haremos nuestro mejor esfuerzo para mantener a la comunidad actualizada sobre nuestro progreso. Únanse a nosotros en el repositorio Discusiones y Propuestas, una iniciativa de la comunidad React Native que ha llevado a crear varias de las iniciativas discutidas en esta hoja de ruta.

Desde hace tiempo, Apple desaconseja el uso de UIWebViews en favor de WKWebView. En iOS 12, que se lanzará en los próximos meses, UIWebViews quedará oficialmente obsoleto. La implementación de WebView en React Native para iOS depende en gran medida de la clase UIWebView. Por lo tanto, ante estos cambios, hemos creado un nuevo backend nativo para iOS en el componente WebView de React Native que utiliza WKWebView.

La fase final de estos cambios se implementó en este commit y estará disponible en la versión 0.57.

Para utilizar esta nueva implementación, emplea la propiedad useWebKit:

<WebView
  useWebKit={true}
  source={{url: 'https://www.google.com'}}
/>

Mejoras​

UIWebView carecía de un método legítimo para facilitar la comunicación entre el JavaScript ejecutándose en el WebView y React Native. Cuando se enviaban mensajes desde el WebView, dependíamos de una solución alternativa para entregarlos a React Native. Brevemente: codificábamos los datos del mensaje en una URL con un esquema especial y navegábamos el WebView hacia ella. En el lado nativo, interceptábamos y cancelábamos esta navegación, extraíamos los datos de la URL y finalmente llamábamos a React Native. Esta implementación era propensa a errores e insegura. Me complace anunciar que hemos aprovechado las características de WKWebView para reemplazarla completamente.

Otras ventajas de WKWebView sobre UIWebView incluyen una ejecución de JavaScript más rápida y una arquitectura multiproceso. Consulta esta WWDC 2014 para más detalles.

Advertencias​

Si tus componentes utilizan las siguientes propiedades, podrías experimentar problemas al cambiar a WKWebView. Por ahora, te sugerimos evitar usar estas props:

Comportamiento inconsistente:

automaticallyAdjustContentInsets y contentInsets (commit)

Cuando agregas contentInsets a un WKWebView, esto no cambia el viewport del WKWebView. El viewport mantiene el mismo tamaño que el frame. Con UIWebView, el tamaño del viewport sí cambia (se reduce si los content insets son positivos).

backgroundColor (commit)

Con la nueva implementación de WebView para iOS, existe la posibilidad de que el color de fondo parpadee si usas esta propiedad. Además, WKWebView renderiza fondos transparentes de manera diferente a UIWebview. Consulta la descripción del commit para más detalles.

No compatible:

scalesPageToFit (commit)

WKWebView no soportaba la propiedad scalesPageToFit, por lo que no pudimos implementarla en el componente WebView de React Native.

Motivación​

A medida que la tecnología avanza y las aplicaciones móviles se vuelven cada vez más importantes en la vida cotidiana, la necesidad de crear aplicaciones accesibles también ha crecido en importancia.

La API de accesibilidad limitada de React Native siempre ha sido un gran punto de dolor para los desarrolladores, por lo que hemos realizado algunas actualizaciones en la API de accesibilidad para facilitar la creación de aplicaciones móviles inclusivas.

Problemas con la API existente​

Problema uno: dos propiedades completamente diferentes pero similares - accessibilityComponentType (Android) y accessibilityTraits (iOS)​

accessibilityComponentType y accessibilityTraits son dos propiedades que se utilizan para indicar a TalkBack en Android y VoiceOver en iOS con qué tipo de elemento de interfaz de usuario está interactuando el usuario. Los dos mayores problemas con estas propiedades son:

1. Son dos propiedades diferentes con métodos de uso distintos, pero tienen el mismo propósito. En la API anterior, estas son dos propiedades separadas (una para cada plataforma), lo que no solo era inconveniente, sino también confuso para muchos desarrolladores. accessibilityTraits en iOS permite 17 valores diferentes, mientras que accessibilityComponentType en Android solo permite 4 valores. Además, los valores en su mayoría no tenían superposición. Incluso los tipos de entrada para estas dos propiedades son diferentes. accessibilityTraits permite pasar un array de rasgos o un solo rasgo, mientras que accessibilityComponentType solo permite un único valor.

2. Existe una funcionalidad muy limitada en Android. Con la propiedad anterior, los únicos elementos de interfaz de usuario que Talkback podía reconocer eran "button", "radiobutton_checked" y "radiobutton_unchecked".

Problema dos: Pistas de accesibilidad inexistentes​

Las pistas de accesibilidad ayudan a los usuarios que utilizan TalkBack o VoiceOver a comprender qué sucederá cuando realicen una acción en un elemento de accesibilidad que no es evidente solo por la etiqueta de accesibilidad. Estas pistas se pueden activar y desactivar en el panel de configuración. Anteriormente, la API de React Native no admitía pistas de accesibilidad en absoluto.

Problema tres: Ignorar colores invertidos​

Algunos usuarios con pérdida de visión utilizan colores invertidos en sus teléfonos móviles para tener un mayor contraste en la pantalla. Apple proporcionó una API para iOS que permite a los desarrolladores ignorar ciertas vistas. De esta manera, las imágenes y los videos no se distorsionan cuando un usuario tiene activada la configuración de colores invertidos. Esta API actualmente no es compatible con React Native.

Diseño de la nueva API​

Solución uno: Combinar accessibilityComponentType (Android) y accessibilityTraits (iOS)​

Para resolver la confusión entre accessibilityComponentType y accessibilityTraits, decidimos fusionarlas en una sola propiedad. Esto tenía sentido porque técnicamente tenían la misma funcionalidad prevista y, al fusionarlas, los desarrolladores ya no tenían que preocuparse por las complejidades específicas de la plataforma al crear funciones de accesibilidad.

Antecedentes

En iOS, UIAccessibilityTraits es una propiedad que se puede establecer en cualquier NSObject. Cada uno de los 17 rasgos que se pasan a través de la propiedad de JavaScript a nativo se asigna a un elemento UIAccessibilityTraits en Objective-C. Cada rasgo está representado por un long int, y cada rasgo que se establece se combina mediante un OR.

Sin embargo, en Android, AccessibilityComponentType es un concepto inventado por React Native, y no se asigna directamente a ninguna propiedad en Android. La accesibilidad se maneja mediante un delegado de accesibilidad. Cada vista tiene un delegado de accesibilidad predeterminado. Si deseas personalizar cualquier acción de accesibilidad, tienes que crear un nuevo delegado de accesibilidad, sobrescribir los métodos específicos que deseas personalizar y luego establecer que el delegado de accesibilidad de la vista que estás manejando esté asociado con el nuevo delegado. Cuando un desarrollador establecía AccessibilityComponentType, el código nativo creaba un nuevo delegado basado en el componente que se pasaba, y establecía que la vista tuviera ese delegado de accesibilidad.

Cambios realizados

Para nuestra nueva propiedad, queríamos crear un superconjunto de ambas propiedades. Decidimos modelar la nueva propiedad principalmente siguiendo el comportamiento de la propiedad existente accessibilityTraits, ya que accessibilityTraits tiene significativamente más valores. La funcionalidad en Android para estos rasgos se implementaría mediante modificaciones en el Delegado de Accesibilidad.

Existen 17 valores de UIAccessibilityTraits que pueden asignarse a accessibilityTraits en iOS. Sin embargo, no incluimos todos como valores posibles en nuestra nueva propiedad. Esto se debe a que el efecto de configurar algunos de estos rasgos es poco conocido, y muchos de estos valores prácticamente no se utilizan.

Los valores de UIAccessibilityTraits generalmente cumplían uno de dos propósitos: describían el rol del elemento de UI o describían su estado. La mayoría de los usos observados combinaban un valor representando un rol con "state selected", "state disabled" o ambos. Por ello, decidimos crear dos nuevas propiedades: accessibilityRole y accessibilityState.

accessibilityRole

La nueva propiedad accessibilityRole indica a TalkBack o VoiceOver el rol de un elemento de UI. Puede tomar uno de estos valores:

• none

• button

• link

• search

• image

• keyboardkey

• text

• adjustable

• header

• summary

• imagebutton

Esta propiedad solo permite un valor porque los elementos de UI generalmente no asumen más de un rol lógico. La excepción son imagen y botón, por lo que añadimos el rol imagebutton que combina ambos.

accessibilityStates

La nueva propiedad accessibilityStates indica a TalkBack o VoiceOver el estado de un elemento de UI. Acepta un array con uno o ambos valores:

• selected

• disabled

Solución dos: Adición de sugerencias de accesibilidad​

Añadimos una nueva propiedad accessibilityHint. Configurarla permite a TalkBack o VoiceOver leer sugerencias a los usuarios.

accessibilityHint

Esta propiedad recibe la sugerencia de accesibilidad como cadena de texto.

En iOS, configura la propiedad nativa AccessibilityHint en la vista. VoiceOver leerá la sugerencia si están activadas en el iPhone.

En Android, el valor se añade al final de la etiqueta de accesibilidad. Esto imita el comportamiento de iOS, pero con la limitación de que en Android no pueden desactivarse mediante ajustes como en iOS.

Tomamos esta decisión porque las sugerencias suelen corresponder con acciones específicas (ej. clic) y queríamos mantener coherencia entre plataformas.

Solución al problema tres​

accessibilityIgnoresInvertColors

Exponemos la API de Apple AccessibilityIgnoresInvertColors en JavaScript. Ahora puedes evitar inversión de colores en vistas (ej. imágenes) configurando esta propiedad como true.

Nuevo uso​

Estas propiedades estarán disponibles en React Native 0.57.

Cómo actualizar​

Si actualmente estás usando accessibilityComponentType y accessibilityTraits, estos son los pasos que puedes seguir para migrar a las nuevas propiedades.

1. Usando jscodeshift​

Los casos de uso más simples pueden reemplazarse ejecutando un script de jscodeshift.

Este script reemplaza las siguientes instancias:

accessibilityTraits=“trait”
accessibilityTraits={[“trait”]}

Con

accessibilityRole= “trait”

Este script también elimina instancias de AccessibilityComponentType (asumiendo que donde sea que configuraste AccessibilityComponentType, también configuraste AccessibilityTraits).

2. Usando un codemod manual​

Para los casos que usaban AccessibilityTraits sin un valor correspondiente en AccessibilityRole, y los casos donde se pasaban múltiples rasgos en AccessibilityTraits, se requiere un codemod manual.

En general,

accessibilityTraits= {[“button”, “selected”]}

se reemplazaría manualmente con

accessibilityRole=“button”
accessibilityStates={[“selected”]}

Estas propiedades ya están siendo utilizadas en la base de código de Facebook. El codemod para Facebook fue sorprendentemente simple. El script de jscodeshift corrigió aproximadamente la mitad de nuestras instancias, y la otra mitad se corrigió manualmente. En general, todo el proceso tomó menos de unas pocas horas.

¡Esperamos que encuentres útil la API actualizada! Y por favor, ¡sigan haciendo aplicaciones accesibles! #inclusion

La tan esperada versión 0.56 de React Native ya está disponible 🎉. Esta entrada de blog destaca algunos de los cambios introducidos en esta nueva versión. También queremos aprovechar para explicar en qué hemos estado ocupados desde marzo.

El dilema de los cambios que rompen compatibilidad, o, "¿cuándo lanzar?"​

La Guía del colaborador explica el proceso de integración por el que pasan todos los cambios en React Native. El proyecto está compuesto por muchas herramientas diferentes, que requieren coordinación y soporte constante para que todo funcione correctamente. Si añadimos la vibrante comunidad de código abierto que contribuye al proyecto, obtendrán una idea de la escala alucinante que todo esto supone.

Con la impresionante adopción de React Native, los cambios que rompen compatibilidad deben hacerse con mucho cuidado, y el proceso no es tan fluido como nos gustaría. Se decidió omitir los lanzamientos de abril y mayo para permitir que el equipo central integrara y probara un nuevo conjunto de cambios que rompen compatibilidad. Se utilizaron canales de comunicación dedicados con la comunidad para garantizar que el lanzamiento de junio de 2018 (0.56.0) sea lo más sencillo posible de adoptar para quienes esperaron pacientemente la versión estable.

¿Es 0.56.0 perfecta? No, como cualquier otro software: pero hemos alcanzado un punto donde el equilibrio entre "esperar más estabilidad" versus "las pruebas dieron resultados exitosos y podemos avanzar" nos hace sentir preparados para lanzarla. Además, somos conscientes de algunos problemas que no se resolvieron en la versión final de 0.56.0. La mayoría de desarrolladores no deberían tener problemas al actualizar a 0.56.0. Para quienes estén bloqueados por los problemas mencionados, esperamos verles en nuestras discusiones y estamos deseando trabajar con ustedes en soluciones para estos problemas.

Pueden considerar 0.56.0 como un bloque fundamental hacia un marco más estable: probablemente tomará una o dos semanas de adopción generalizada antes de que se pulan todos los casos extremos, pero esto conducirá a un lanzamiento aún mejor en julio de 2018 (0.57.0).

Nos gustaría concluir esta sección agradeciendo a los 67 colaboradores que trabajaron en un total de 818 commits (!) que ayudarán a mejorar sus aplicaciones 👏.

Y ahora, sin más preámbulos...

Los grandes cambios​

Babel 7​

Como quizá sepan, la herramienta de transpilación que nos permite usar las últimas y mejores características de JavaScript, Babel, está migrando a v7 próximamente. Dado que esta nueva versión trae cambios importantes, consideramos que ahora es un buen momento para actualizar, permitiendo que Metro aproveche sus mejoras.

Si tienen problemas con la actualización, consulten la sección de documentación relacionada.

Modernización del soporte para Android​

En Android, gran parte del ecosistema de herramientas ha cambiado. Hemos actualizado a Gradle 3.5, Android SDK 26, Fresco a 1.9.0 y OkHttp a 3.10.0, e incluso el NDK API target a API 16. Estos cambios deberían implementarse sin problemas y resultarán en builds más rápidos. Más importante aún, ayudará a los desarrolladores a cumplir con los nuevos requisitos de Play Store que entrarán en vigor el próximo mes.

Relacionado con esto, nos gustaría agradecer especialmente a Dulmandakh por los numerosos PRs enviados para hacerlo posible 👏.

Quedan más pasos por tomar en esta dirección, y puedes seguir la planificación futura y discusión sobre la actualización del soporte para Android en el issue dedicado (y otro adicional para JSC).

Nuevas versiones de Node, Xcode, React y Flow ¡oh my!​

Node 8 es ahora el estándar para React Native. En realidad ya se estaba probando, pero nos hemos comprometido completamente ahora que Node 6 entró en modo mantenimiento. React también se actualizó a 16.4, que trae consigo una gran cantidad de correcciones.

Estamos eliminando el soporte para iOS 8, haciendo que iOS 9 sea la versión más antigua que se puede targetear. No prevemos que esto sea un problema, ya que cualquier dispositivo que ejecute iOS 8 puede actualizarse a iOS 9. Este cambio nos permitió eliminar código poco utilizado que implementaba soluciones alternativas para dispositivos antiguos con iOS 8.

La cadena de herramientas de integración continua se ha actualizado para usar Xcode 9.4, asegurando que todas las pruebas de iOS se ejecuten en las herramientas de desarrollo más recientes proporcionadas por Apple.

Hemos actualizado a Flow 0.75 para usar el nuevo formato de errores que muchos desarrolladores aprecian. También hemos creado tipos para muchos más componentes. Si aún no aplicas tipado estático en tu proyecto, considera usar Flow para identificar problemas durante el desarrollo en lugar de en tiempo de ejecución.

Y muchas otras cosas...​

Por ejemplo, YellowBox fue reemplazado con una nueva implementación que mejora mucho la depuración.

Para las notas completas de la versión, consulta el changelog completo aquí. Y recuerda revisar la guía de actualización para evitar problemas al migrar a esta nueva versión.

Una nota final: a partir de esta semana, el equipo central de React Native reanudará las reuniones mensuales. Nos aseguraremos de mantener a todos actualizados sobre lo tratado, y consideraremos sus comentarios para futuras reuniones.

¡Feliz coding a todos!

Lorenzo, Ryan, y todo el equipo central de React Native

PD: como siempre, queremos recordar que React Native sigue en versión 0.x debido a los muchos cambios en curso. Al actualizar, recuerden que sí, probablemente algo podría fallar o romperse. Sean colaborativos en los issues y al enviar PRs, y recuerden seguir el CoC: siempre hay una persona al otro lado de la pantalla.

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.