Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
El año pasado realizamos entrevistas con usuarios y enviamos una encuesta para entender mejor cómo y cuándo las personas usan la documentación de React Native. Con los datos y orientación obtenidos de 24 entrevistas y más de 3000 respuestas a la encuesta, hemos trabajado para mejorar la documentación de React Native, y hoy nos entusiasma compartir ese progreso:
Nueva guía de Testing Colaboramos con Vojtech Novak para crear una nueva guía ilustrada de testing que presenta a los desarrolladores diferentes estrategias de pruebas y cómo funcionan en el flujo de trabajo de React Native.
Nueva guía de Seguridad Trabajamos con Kadi Kraman para crear una nueva guía ilustrada de seguridad que explica los fundamentos de seguridad en React Native y propone soluciones de primer nivel.
https://reactnative.dev ¡Después de 5 años finalmente nos mudamos a nuestro propio dominio! reactnative.dev se autocompleta más fácilmente desde la barra del navegador y es más sencillo de escribir que nuestra dirección anterior github.io.
Mejoras de diseño y arquitectura del sitio Actualizamos el diseño y la arquitectura del sitio para destacar y categorizar mejor nuestras guías, y hacer más legible el contenido en la referencia de API. ¡Un reconocimiento especial a Bartosz Kaszubowski cuya atención al detalle y colaboración hicieron posibles rápidamente muchos de estos cambios!
¡Sigan enviando esos PRs! ¡Hemos logrado mantener consistentemente nuestras PRs abiertas en menos de 10 por semana! ¡Gracias por enviarlas!
¡Muchísimas gracias a todos los que participaron en las entrevistas, la encuesta y nuestros esfuerzos de documentación! Su colaboración hace esto posible.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
El equipo de React Native en Facebook se guía por principios que ayudan a determinar cómo priorizamos nuestro trabajo. Estos principios representan específicamente a nuestro equipo y no necesariamente a todas las partes interesadas en la comunidad de React Native. Compartimos estos principios para ser más transparentes sobre lo que nos impulsa, cómo tomamos decisiones y cómo enfocamos nuestros esfuerzos.
Nuestra máxima prioridad para React Native es cumplir con las expectativas que las personas tienen para cada plataforma. Por eso React Native renderiza usando primitivas de plataforma. Valoramos más la apariencia y comportamiento nativos que la consistencia multiplataforma.
Por ejemplo, el componente TextInput en React Native se renderiza como un UITextField en iOS. Esto garantiza que la integración con gestores de contraseñas y controles del teclado funcione inmediatamente. Al usar primitivas de plataforma, las apps de React Native también pueden mantenerse actualizadas con los cambios de diseño y comportamiento de nuevas versiones de Android e iOS.
Para igualar la apariencia y comportamiento de las aplicaciones nativas, también debemos igualar su rendimiento. Aquí enfocamos nuestros esfuerzos más ambiciosos. Por ejemplo, Facebook creó Hermes, un nuevo motor JavaScript creado desde cero para React Native en Android. Hermes mejora significativamente el tiempo de inicio de las apps de React Native. También estamos trabajando en cambios arquitectónicos importantes que optimizan el modelo de hilos y facilitan la interoperabilidad con código nativo.
Cientos de pantallas en la app de Facebook están implementadas con React Native. La app de Facebook es utilizada por miles de millones de personas en una enorme variedad de dispositivos. Por esto invertimos en los problemas más desafiantes a gran escala.
Implementar React Native en nuestras apps nos permite identificar problemas que no veríamos a menor escala. Por ejemplo, Facebook se enfoca en mejorar el rendimiento en un amplio espectro de dispositivos, desde el iPhone más nuevo hasta muchas generaciones anteriores de dispositivos Android. Este enfoque guía nuestros proyectos arquitectónicos como Hermes, Fabric y TurboModules.
Hemos demostrado que React Native también puede escalar a organizaciones masivas. Cuando cientos de desarrolladores trabajan en la misma app, la adopción gradual es imprescindible. Por eso nos aseguramos de que React Native pueda adoptarse una pantalla a la vez. Pronto daremos un paso más allá, permitiendo migrar vistas nativas individuales de pantallas nativas existentes a React Native.
El enfoque en la escala masiva significa que hay muchas cosas en las que nuestro equipo no está trabajando actualmente. Por ejemplo, nuestro equipo no impulsa la adopción de React Native en la industria. Tampoco desarrollamos activamente soluciones para problemas que no observamos a gran escala. Estamos orgullosos de tener muchos socios y contribuidores principales que pueden enfocarse en esas áreas importantes para la comunidad.
Las grandes experiencias de usuario se crean de forma iterativa. Debería tomar solo unos segundos ver el resultado de cambios en el código en una aplicación en ejecución. La arquitectura de React Native permite proporcionar retroalimentación casi instantánea durante el desarrollo.
A menudo escuchamos de equipos que adoptar React Native mejoró significativamente su velocidad de desarrollo. Estos equipos encuentran que la retroalimentación instantánea durante el desarrollo facilita probar diferentes ideas y añadir pulido adicional, sin tener que interrumpir su sesión de codificación por cada pequeño cambio. Cuando hacemos cambios en React Native, nos aseguramos de preservar esta cualidad de la experiencia del desarrollador.
La retroalimentación instantánea no es la única forma en que React Native mejora la velocidad de desarrollo. Los equipos pueden aprovechar el ecosistema en rápido crecimiento de paquetes de código abierto de alta calidad. También pueden compartir lógica de negocio entre Android, iOS y la web. Esto les ayuda a lanzar actualizaciones más rápido y reducir silos organizacionales entre equipos de plataformas.
Cuando presentamos React Native en 2014, lo hicimos con nuestro lema "Learn once, write anywhere" (Aprende una vez, escribe en cualquier lugar) — y nos referimos a cualquier lugar. Los desarrolladores deberían poder llegar a tantas personas como sea posible sin verse limitados por el modelo de dispositivo o sistema operativo.
React Native abarca plataformas muy diversas como móviles, escritorio, web, TV, realidad virtual, consolas de juegos y más. Buscamos habilitar experiencias enriquecidas en cada plataforma en lugar de obligar a los desarrolladores a construir para el mínimo común denominador. Para lograrlo, nos enfocamos en admitir las características únicas de cada plataforma. Esto abarca desde diferentes mecanismos de entrada (como tacto, lápiz, ratón) hasta experiencias de consumo fundamentalmente distintas como entornos 3D en realidad virtual.
Este principio fundamentó nuestra decisión de implementar la nueva arquitectura central de React Native en C++ multiplataforma para promover la paridad entre plataformas. También estamos refinando la interfaz pública dirigida a otros mantenedores de plataformas como Microsoft con Windows y macOS. Nos esforzamos por permitir que cualquier plataforma admita React Native.
No creemos en desplegar interfaces idénticas en cada plataforma, creemos en exponer las capacidades únicas de cada plataforma con el mismo modelo de programación declarativo. Nuestro modelo de programación declarativo es React.
En nuestra experiencia, el flujo de datos unidireccional popularizado por React hace que las aplicaciones sean más comprensibles. Preferimos expresar una pantalla como composición de componentes declarativos en lugar de vistas gestionadas imperativamente. El éxito de React en la web y la dirección de los nuevos frameworks nativos de Android e iOS demuestran que la industria también ha adoptado interfaces declarativas.
React popularizó las interfaces de usuario declarativas. Sin embargo, aún existen problemas no resueltos que React está singularmente posicionado para resolver. React Native continuará construyendo sobre las innovaciones de React y mantendrá su posición a la vanguardia del movimiento de interfaces de usuario declarativas.
Hemos recibido comentarios frecuentes de la comunidad indicando que los errores y advertencias son difíciles de depurar en React Native. Para abordar estos problemas, revisamos todo el sistema de errores, advertencias y logs en React Native y lo rediseñamos desde cero.
LogBox es una experiencia completamente rediseñada de redbox, yellowbox y registro de logs en React Native. En la versión 0.62 presentamos LogBox como opcional. En este lanzamiento, implementamos LogBox como experiencia predeterminada en todo React Native.
LogBox aborda las quejas sobre errores y advertencias demasiado verbosos, mal formateados o inaccionables centrándose en tres objetivos principales:
Conciso: Los logs deben proporcionar la mínima información necesaria para depurar un problema.
Formateado: Los logs deben estar estructurados para que puedas encontrar rápidamente la información que necesitas.
Accionable: Los logs deben ser prácticos para que puedas resolver el problema y continuar.
Para lograr estos objetivos, LogBox incluye:
Notificaciones de logs: Hemos rediseñado las notificaciones de advertencias y añadido soporte para errores, haciendo que todos los mensajes de console.warn y console.log aparezcan como notificaciones en lugar de cubrir tu aplicación.
Marcos de código: Cada error y advertencia ahora incluye un marco de código que muestra el código fuente del log directamente en la app, permitiéndote identificar rápidamente el origen del problema.
Pilas de componentes: Todas las pilas de componentes ahora se extraen de los mensajes de error y se colocan en su propia sección con los tres primeros marcos visibles. Esto te da un espacio único y consistente para obtener información de marcos de pila sin saturar el mensaje del log.
Contracción de marcos de pila: Por defecto, ahora contraemos los marcos de pila de llamada no relacionados con el código de tu aplicación para que puedas ver rápidamente el problema sin revisar internos de React Native.
Formateo de errores de sintaxis: Hemos mejorado el formato para errores de sintaxis y añadido marcos de código con resaltado de sintaxis para que puedas ver el origen del error, corregirlo y continuar programando sin que React Native interfiera.
Hemos integrado todas estas características en un diseño visual mejorado, consistente entre errores y advertencias, que permite navegar por todos los logs en una interfaz única y agradable.
Con este cambio también estamos dejando obsoleta YellowBox en favor de las APIs de LogBox:
LogBox.ignoreLogs(): Esta función reemplaza a YellowBox.ignoreLogs([]) como forma de silenciar logs que coincidan con las cadenas o expresiones regulares dadas.
LogBox.ignoreAllLogs(): Esta función reemplaza a console.disableYellowBox como forma de desactivar notificaciones de errores o advertencias. Nota: esto solo desactiva las notificaciones; los errores no capturados aún abrirán un LogBox a pantalla completa.
En la versión 0.63, mostraremos advertencias al usar estos módulos o métodos obsoletos. Por favor, actualiza tus puntos de llamada de estas APIs antes de que se eliminen en la versión 0.64.
Para más información sobre LogBox y depuración en React Native, consulta la documentación aquí.
React Native se creó para que las aplicaciones cumplan con las expectativas de los usuarios en cada plataforma. Esto incluye evitar "indicios": pequeños detalles que revelan que la experiencia fue construida con React Native. Una fuente importante de estos indicios han sido los componentes táctiles: Button, TouchableWithoutFeedback, TouchableHighlight, TouchableOpacity, TouchableNativeFeedback y TouchableBounce. Estos componentes hacen que tu aplicación sea interactiva al permitirte proporcionar retroalimentación visual a las interacciones del usuario. Sin embargo, como incluyen estilos y efectos incorporados que no coinciden con la interacción nativa de la plataforma, los usuarios pueden detectar cuando las experiencias están escritas con React Native.
Además, a medida que React Native ha evolucionado y nuestros estándares para aplicaciones de alta calidad han aumentado, estos componentes no han evolucionado con él. React Native ahora admite plataformas como Web, Escritorio y TV, pero ha carecido de soporte para modalidades de entrada adicionales. React Native necesita ofrecer experiencias de interacción de alta calidad en todas las plataformas.
Para abordar estos problemas, presentamos un nuevo componente central llamado Pressable. Este componente puede detectar varios tipos de interacciones. Su API fue diseñada para proporcionar acceso directo al estado actual de la interacción sin necesidad de mantener manualmente el estado en un componente padre. También se diseñó para permitir que las plataformas amplíen sus capacidades e incluyan hover, blur, focus y más. Esperamos que la mayoría de las personas construyan y compartan componentes que utilicen Pressable internamente, en lugar de depender de la experiencia predeterminada de componentes como TouchableOpacity.
Cada plataforma nativa tiene el concepto de colores definidos por el sistema. Son colores que responden automáticamente a configuraciones del sistema como modo Claro u Oscuro, ajustes de accesibilidad como modo Alto Contraste, e incluso su contexto dentro de la aplicación como las características de una vista o ventana contenedora.
Si bien es posible detectar algunas de estas configuraciones mediante la API Appearance y/o AccessibilityInfo y ajustar los estilos en consecuencia, tales abstracciones no solo son costosas de desarrollar sino que aproximan la apariencia de los colores nativos. Estas inconsistencias son particularmente notorias en aplicaciones híbridas, donde los elementos de React Native coexisten junto a los nativos.
React Native ahora ofrece una solución lista para usar estos colores del sistema. PlatformColor() es una nueva API que puede usarse como cualquier otro color en React Native.
import{View,Text,PlatformColor}from'react-native'; <View style={{ backgroundColor:PlatformColor('?attr/colorButtonNormal'), }}> <Text>This is colored like a button!</Text> </View>;
Sets the background color of the View component to colorButtonNormal as defined by Android.
DynamicColorIOS es una API exclusiva de iOS que te permite definir qué color usar en modo claro y oscuro. Similar a PlatformColor, puede usarse en cualquier lugar donde se usen colores. DynamicColorIOS utiliza internamente colorWithDynamicProvider de iOS.
import{Text,DynamicColorIOS}from'react-native'; const customDynamicTextColor =DynamicColorIOS({ dark:'lightskyblue', light:'midnightblue', }); <Textstyle={{color: customDynamicTextColor}}> This color changes automatically based on the system theme! </Text>;
Changes the text color based on the system theme
Puedes obtener más información sobre DynamicColorIOS en la documentación.
Después de más de cuatro años desde su lanzamiento, eliminamos el soporte para iOS 9. Este cambio nos permitirá avanzar más rápido al reducir las comprobaciones de compatibilidad necesarias en el código nativo para detectar si una función era compatible con cierta versión de iOS. Con su cuota de mercado del 1%, no debería tener un impacto negativo significativo en tus usuarios.
Al mismo tiempo, estamos eliminando el soporte para Node 8. Su ciclo de mantenimiento LTS expiró en diciembre de 2019. La versión LTS actual es Node 10 y ahora es la versión que estamos utilizando como objetivo. Si aún usas Node 8 para el desarrollo de aplicaciones React Native, te recomendamos actualizar para recibir todas las correcciones de seguridad y actualizaciones más recientes.
Soporte para renderizar <View /> dentro de <Text /> sin tamaño explícito: Ahora puedes renderizar cualquier <View /> dentro de cualquier componente <Text /> sin establecer explícitamente su ancho y alto, algo que no siempre era posible. En versiones anteriores de React Native, esto resultaba en un RedBox.
Cambio de LaunchScreen en iOS de xib a storyboard: A partir del 30 de abril de 2020, todas las aplicaciones enviadas a App Store deben usar un storyboard de Xcode para proporcionar la pantalla de inicio, y todas las apps para iPhone deben admitir todas las pantallas de iPhone. Este cambio ajusta la plantilla predeterminada de React Native para cumplir con este requisito.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
Hoy lanzamos React Native versión 0.62 que incluye soporte para Flipper de forma predeterminada.
Este lanzamiento ocurre en medio de una pandemia global. Publicamos esta versión hoy para respetar el trabajo de cientos de colaboradores que hicieron posible este lanzamiento y evitar que quede demasiado rezagado respecto a la rama principal. Por favor, consideren la capacidad reducida de los colaboradores para ayudar con problemas y prepárense para retrasar la actualización si es necesario.
Flipper es una herramienta de desarrollo para depurar aplicaciones móviles. Es popular en las comunidades de Android e iOS, y en esta versión hemos habilitado su soporte por defecto para aplicaciones nuevas y existentes de React Native.
Flipper proporciona las siguientes funciones listas para usar:
Acciones de Metro: Recarga la aplicación y activa el Menú de Desarrollo desde la barra de herramientas.
Reporte de Fallos: Visualiza informes de fallos desde dispositivos Android e iOS.
React DevTools: Usa la versión más reciente de React DevTools junto con todas tus otras herramientas.
Inspector de Red: Visualiza todas las solicitudes de red realizadas por las aplicaciones del dispositivo.
Registros de Metro y Dispositivo: Visualiza, busca y filtra todos los registros tanto de Metro como del dispositivo.
Inspector de Diseño Nativo: Visualiza y edita el diseño nativo generado por el renderizador de React Native.
Inspectores de Base de Datos y Preferencias: Visualiza y edita las bases de datos y preferencias del dispositivo.
Adicionalmente, dado que Flipper es una plataforma extensible, proporciona un mercado que obtiene plugins de NPM para que puedas publicar e instalar plugins personalizados específicos para tus flujos de trabajo. Consulta los plugins disponibles aquí.
Hemos añadido un nuevo módulo Appearance para proporcionar acceso a las preferencias de apariencia del usuario, como su esquema de color preferido (claro u oscuro).
const colorScheme =Appearance.getColorScheme(); if(colorScheme ==='dark'){ // Use dark color scheme }
También hemos añadido un hook para suscribirse a actualizaciones de estado de las preferencias del usuario:
Como parte de nuestro esfuerzo Lean Core y para alinear Apple TV con otras plataformas como React Native Windows y React Native macOS, hemos comenzado a eliminar el código específico de Apple TV del núcleo.
De ahora en adelante, el soporte para Apple TV en React Native se mantendrá en react-native-community/react-native-tvos junto con el paquete NPM correspondiente react-native-tvos. Este es un fork completo del repositorio principal, con solo los cambios necesarios para soportar Apple TV.
Los lanzamientos de react-native-tvos se basarán en la versión pública de React Native. Para este lanzamiento 0.62 de react-native, actualiza los proyectos de Apple TV para usar react-native-tvos 0.62.
Cuando se lanzó la versión 0.61, la comunidad presentó una nueva herramienta de asistente de actualización para ayudar a los desarrolladores a actualizar a nuevas versiones de React Native. El asistente muestra un diff de cambios desde tu versión actual hasta la versión objetivo, permitiéndote ver los cambios necesarios para tu actualización específica.
Incluso con esta herramienta, surgen problemas al actualizar. Hoy presentamos más soporte dedicado para actualizaciones al anunciar Upgrade-Support. Upgrade Support es un rastreador de problemas de GitHub donde los usuarios pueden enviar problemas específicos sobre la actualización de sus proyectos para recibir ayuda de la comunidad.
Siempre estamos trabajando para mejorar la experiencia de actualización, y esperamos que estas herramientas brinden a los usuarios el soporte que necesitan en casos extremos que aún no hemos cubierto.
LogBox: Estamos agregando la nueva experiencia de errores y advertencias de LogBox como opción; para habilitarla, añade require('react-native').unstable_enableLogBox() a tu archivo index.js.
React DevTools v4: Este cambio incluye una actualización a las últimas React DevTools que ofrecen mejoras significativas de rendimiento, una experiencia de navegación mejorada y soporte completo para React Hooks.
Mejoras de accesibilidad: Hemos realizado mejoras en accesibilidad incluyendo la adición de accessibilityValue, props faltantes en Touchables, eventos de accesibilidad onSlidingCompleteaccesibilidad, y cambiar el rol predeterminado del componente Switch de "button" a "switch".
Eliminación de PropTypes: Estamos eliminando propTypes de los componentes principales para reducir el impacto en el tamaño de la aplicación del núcleo de React Native y favorecer sistemas de tipos estáticos que se verifican en tiempo de compilación en lugar de en tiempo de ejecución.
Eliminación de accessibilityStates: Hemos eliminado la propiedad obsoleta accessibilityStates en favor de la nueva prop accessibilityState, que es una forma semánticamente más rica para que los componentes describan información sobre su estado a los servicios de accesibilidad.
Cambios en TextInput: Eliminamos onTextInputde TextInput ya que es poco común, no cumple con W3C y es difícil de implementar en Fabric. También eliminamos la prop no documentada inputView y selectionState.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
Tras más de 20 pull requests de 6 colaboradores en la Comunidad de React Native, nos complace lanzar react-native doctor, un nuevo comando que te ayudará a comenzar, solucionar problemas y corregir automáticamente errores en tu entorno de desarrollo. El comando doctor está fuertemente inspirado en los comandos doctor de Expo y Homebrew, con un toque de interfaz inspirado en Jest.
Cuando preguntamos a la comunidad de React Native sobre puntos problemáticos comunes, una de las respuestas principales fue que la función de "recarga en caliente" estaba rota. No funcionaba de manera confiable para componentes funcionales, a menudo fallaba al actualizar la pantalla y no resistía errores tipográficos. Escuchamos que la mayoría de la gente la desactivaba porque era demasiado poco fiable.
En React Native 0.61, unificamos las funciones existentes de "recarga en vivo" (recargar al guardar) y "recarga en caliente" en una nueva función llamada "Fast Refresh". Fast Refresh se implementó desde cero con estos principios:
Fast Refresh admite completamente React moderno, incluidos componentes funcionales y Hooks.
Fast Refresh se recupera adecuadamente después de errores tipográficos y otros fallos, recurriendo a recarga completa cuando es necesario.
Fast Refresh no realiza transformaciones de código invasivas, por lo que es lo suficientemente confiable como para estar activado por defecto.
Para ver Fast Refresh en acción, mira este video:
¡Pruébalo y cuéntanos qué opinas! Si lo prefieres, puedes desactivarlo en el Menú de desarrollo (Cmd+D en iOS, Cmd+M o Ctrl+M en Android). Activarlo y desactivarlo es instantáneo, así que puedes hacerlo en cualquier momento.
Aquí tienes algunos consejos sobre Fast Refresh:
Por defecto, Fast Refresh preserva el estado local de React en componentes funcionales (¡y Hooks!).
Si necesitas resetear el estado de React en cada edición, añade el comentario especial // @refresh reset en el archivo de ese componente.
Fast Refresh siempre vuelve a montar componentes de clase sin preservar estado. Esto garantiza su funcionamiento confiable.
¡Todos cometemos errores en el código! Fast Refresh reintenta el renderizado automáticamente tras guardar un archivo. No necesitas recargar la app manualmente después de corregir errores de sintaxis o runtime.
Añadir sentencias console.log o debugger durante las ediciones es una técnica de depuración muy útil.
Reporta cualquier problema con Fast Refresh en GitHub, y los investigaremos.
Corrección del soporte para use_frameworks! en CocoaPods. En 0.60 realizamos actualizaciones para integrar CocoaPods por defecto. Lamentablemente, esto rompió compilaciones usando use_frameworks!. Esto está solucionado en 0.61, facilitando integrar React Native en proyectos iOS que requieren frameworks dinámicos.
Se añade el Hook useWindowDimensions. Este nuevo Hook proporciona y suscribe automáticamente actualizaciones de dimensiones, pudiendo usarse en lugar de la API Dimensions en la mayoría de casos.
React se actualizó a 16.9. Esta versión deprecia nombres antiguos de métodos del ciclo de vida UNSAFE_, contiene mejoras en act, y más. Consulta la publicación sobre React 16.9 para el script de migración automatizado y más información.
Eliminación de React .xcodeproj. En la versión 0.60, introdujimos soporte para auto-linking mediante CocoaPods. También hemos integrado CocoaPods en las pruebas de extremo a extremo, estableciendo así una forma estándar unificada de integrar React Native en aplicaciones iOS. Esto elimina efectivamente el soporte para React .xcodeproj, y el archivo se ha eliminado a partir de la versión 0.61. Nota: si ya usas auto-linking de la versión 0.60, no deberías verte afectado.
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í: