Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
La semana pasada en Chain React anunciamos Hermes, un motor JavaScript de código abierto en el que hemos estado trabajando en Facebook. Es un motor JavaScript pequeño y ligero optimizado para ejecutar React Native en Android. ¡Échale un vistazo!
Hermes mejora el rendimiento de React Native reduciendo el uso de memoria, disminuyendo el tamaño de descarga y acortando el tiempo hasta que la aplicación se vuelve utilizable o "tiempo hasta la interacción" (TTI).
"Al analizar los datos de rendimiento, notamos que el propio motor JavaScript era un factor significativo en el rendimiento de inicio y el tamaño de descarga. Con estos datos, supimos que debíamos optimizar el rendimiento de JavaScript en los entornos más limitados de un teléfono móvil en comparación con un ordenador de escritorio o portátil. Después de explorar otras opciones, construimos un nuevo motor JavaScript que llamamos Hermes. Está diseñado para mejorar el rendimiento de las aplicaciones, centrándonos en nuestras apps de React Native, incluso en dispositivos de mercado masivo con memoria limitada, almacenamiento lento y potencia de computación reducida." —Hermes: Un motor JavaScript de código abierto optimizado para aplicaciones móviles, empezando por React Native
Mantenedor Principal y Desarrollador de React Native
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 →
Tras meses de trabajo duro de cientos de colaboradores, el equipo central de React Native se enorgullece de anunciar el lanzamiento de la versión 0.60. Esta versión aborda migraciones significativas tanto para Android como para iOS, además de resolver numerosos problemas. Esta publicación destaca los aspectos más relevantes de la versión. Como siempre, consulta el registro de cambios para obtener información más detallada. ¡Finalmente, gracias a todos los colaboradores por ayudarnos a alcanzar este hito!
¡La pantalla de inicio de React Native ha sido actualizada! Gracias a los numerosos colaboradores que ayudaron a crear la nueva interfaz. Este nuevo "Hola Mundo" dará la bienvenida a los usuarios al ecosistema de manera más amigable y atractiva.
AndroidX es un gran avance en el ecosistema Android, y los antiguos componentes de la biblioteca de soporte están quedando obsoletos. Para la versión 0.60, React Native ha migrado a AndroidX. Este es un cambio disruptivo, y tu código nativo y dependencias también deberán migrarse.
Con este cambio, las aplicaciones de React Native deberán comenzar a usar AndroidX directamente. No pueden coexistir en una misma aplicación, por lo que todo el código de la app y sus dependencias debe usar una u otra.
Aunque deberás migrar tu propio código nativo, @mikehardy, @cawfree y @m4tt72 crearon una herramienta inteligente llamada "jetifier" para parchear tus node_modules. Los mantenedores de bibliotecas necesitarán actualizarlas, pero esta herramienta ofrece una solución temporal mientras les das tiempo para lanzar una versión compatible con AndroidX. Así que si encuentras errores relacionados con la migración a AndroidX, prueba esto.
CocoaPods ahora forma parte del proyecto iOS de React Native. Si aún no lo hacías, asegúrate de abrir el código de la plataforma iOS usando el archivo xcworkspace de ahora en adelante (consejo: prueba xed ios desde el directorio raíz del proyecto). Además, los podspec para paquetes internos han cambiado para hacerlos compatibles con los proyectos de Xcode, lo que ayudará en la solución de problemas y depuración. Espera hacer cambios sencillos en tu Podfile como parte de la actualización a 0.60 para incorporar este soporte. Ten en cuenta que conocemos un problema de compatibilidad con use_frameworks!, y estamos siguiendo un issue con soluciones alternativas y un futuro parche.
WebView y NetInfo se extrajeron previamente en repositorios separados, y en 0.60 hemos terminado de migrarlos fuera del repositorio de React Native. Además, en respuesta a los comentarios de la comunidad sobre las nuevas políticas de App Store, Geolocation también se ha extraído. Si aún no lo has hecho, completa tu migración agregando dependencias a react-native-webview, @react-native-community/netinfo y @react-native-community/geolocation. Si prefieres una solución automatizada, considera usar rn-upgrade-deprecated-modules. Los mantenedores han realizado más de 100 commits en estos repositorios desde su extracción y estamos emocionados con el apoyo de la comunidad.
¡El equipo que trabaja en la CLI de React Native ha introducido mejoras importantes en la vinculación de módulos nativos llamadas autolinking! La mayoría de los escenarios ya no requerirán usar react-native link. Al mismo tiempo, el equipo renovó por completo el proceso de vinculación. Asegúrate de ejecutar react-native unlink para cualquier dependencia preexistente como se menciona en la documentación anterior.
@lucasbento, @pvinis, @kelset y @watadarkstar han construido una gran herramienta llamada Upgrade Helper para simplificar el proceso de actualización. Ayuda a usuarios de React Native con apps brownfield o personalizaciones complejas a ver qué ha cambiado entre versiones. Consulta la documentación actualizada de actualización y pruébala hoy mismo para tu ruta de actualización.
Los cambios para AndroidX casi seguramente requerirán actualizaciones en tu biblioteca, así que asegúrate de incluir soporte pronto. Si aún no puedes actualizar, considera verificar tu biblioteca con jetifier para confirmar que los usuarios puedan parchearla en tiempo de compilación.
Revisa la documentación de autolinking para actualizar tus configuraciones y README. Dependiendo de cómo se integró previamente tu biblioteca, es posible que también necesites hacer cambios adicionales. Consulta la guía de dependencias de la CLI para información sobre cómo definir tu interfaz de dependencia.
Aunque estos son los aspectos más destacados que mencionamos, hay muchos otros que pueden entusiasmarte. Para ver todas las actualizaciones, consulta el changelog. Como siempre, mantente atento para más noticias. ¡Disfruta de la versión 0.60 mientras tanto!
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.
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:
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).
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!
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.
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.
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?"
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.
¡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 página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
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.
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.
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.
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í:
Mantenedor Principal y Desarrollador de React Native
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 →
¡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 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:
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.
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.
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.
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:
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.
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.
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!
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:
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.
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.
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.
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:
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.
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.
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! ⚛️✌️
Mantenedor Principal y Desarrollador de React Native
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 →
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:
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:
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.
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.
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.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
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.
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.
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.
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.
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
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.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
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:
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.
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).
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.
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.
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:
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.
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.
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.
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.
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.
Si actualmente estás usando accessibilityComponentType y accessibilityTraits, estos son los pasos que puedes seguir para migrar a las nuevas propiedades.
Este script también elimina instancias de AccessibilityComponentType (asumiendo que donde sea que configuraste AccessibilityComponentType, también configuraste AccessibilityTraits).
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.
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
Ilustración de Rachel Nabors
