React Native EU ha concluido. Más de 300 participantes de 33 países visitaron Wroclaw. Las charlas están disponibles en YouTube.
Estamos retomando gradualmente nuestro ritmo de trabajo en código abierto después de la conferencia. Un punto destacable es que estamos preparando una nueva versión de react-native-opentok que solucionará la mayoría de los problemas existentes.
Trabajando para reducir las barreras de entrada para desarrolladores que adoptan React Native con estas iniciativas:
Anunciamos BuilderX.io en React Native EU. BuilderX es una herramienta de diseño que trabaja directamente con archivos JavaScript (actualmente solo soporta React Native) para generar código elegante, legible y editable.
Lanzamos ReactNativeSeed.com, que ofrece plantillas para tu próximo proyecto en React Native. Incluye diversas opciones como TypeScript & Flow para tipos de datos, MobX, Redux y mobx-state-tree para gestión de estado, con CRNA y React-Native básico como stack.
Pronto lanzaremos el SDK 21, que añade soporte para react-native 0.48.3 junto con correcciones de errores, mejoras de fiabilidad y nuevas funciones en Expo SDK, incluyendo grabación de video, nueva API para pantallas de inicio, soporte para react-native-gesture-handler y mejor manejo de errores.
Respecto a react-native-gesture-handler, Krzysztof Magiera de Software Mansion continúa avanzando en este proyecto. Hemos colaborado en pruebas y financiado parte de su desarrollo. Su integración en Expo SDK21 permitirá probarlo fácilmente en Snack, así que estamos emocionados por ver qué crea la comunidad.
Sobre mejoras en registro/manejo de errores: consulta este gist de un PR interno de Expo para detalles del registro (especialmente "Problema 2"), y este commit para cambios en el manejo de importaciones fallidas de módulos estándar de npm. Existen oportunidades para mejorar mensajes de error en React Native mediante este enfoque, y trabajaremos en PRs posteriores. Sería excelente que la comunidad participe también.
Mejorando componentes <Text> y <TextInput> en Android (crecimiento automático nativo para <TextInput>; problemas de diseño en componentes <Text> anidados; mejor estructura de código; optimizaciones de rendimiento).
Seguimos buscando colaboradores adicionales que deseen ayudar en la gestión de issues y pull requests.
Lanzada función de Firma de Código para CodePush. Los desarrolladores de React Native ahora pueden firmar sus paquetes de aplicación en CodePush. El anuncio está disponible aquí
Trabajando en completar la integración de CodePush en Mobile Center. También evaluando la integración de pruebas y gestión de fallos.
La próxima sesión está programada para el miércoles 10 de octubre de 2017. Como esta fue solo nuestra cuarta reunión, nos gustaría saber cómo estas notas benefician a la comunidad de React Native. No dudes en contactarme en Twitter si tienes sugerencias sobre cómo mejorar los resultados de nuestras reuniones.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
¡Continuamos con la reunión mensual de React Native! Este mes el encuentro fue más breve porque la mayoría de nuestros equipos estaban ocupados lanzando productos. El próximo mes estaremos en la conferencia React Native EU en Wroclaw, Polonia. ¡Asegúrate de conseguir tu entrada y nos vemos allí en persona! Mientras tanto, veamos en qué están trabajando nuestros equipos.
Recientemente hicimos open source de react-native-material-palette. Extrae colores prominentes de las imágenes para ayudarte a crear aplicaciones visualmente atractivas. Actualmente solo está disponible para Android, pero estamos evaluando añadir soporte para iOS en el futuro.
Hemos implementado soporte para HMR en haul junto con otras funcionalidades interesantes. ¡Consulta los últimos lanzamientos!
¡React Native EU 2017 se acerca! ¡El próximo mes estará dedicado a React Native y Polonia! Asegúrate de conseguir las últimas entradas disponibles aquí.
Lanzamos soporte para instalar paquetes npm en Snack. Se aplican las restricciones habituales de Expo: los paquetes no pueden depender de APIs nativas personalizadas que no estén ya incluidas en Expo. También estamos trabajando en la compatibilidad con múltiples archivos y carga de recursos en Snack. Satyajit hablará sobre Snack en React Native Europe.
Lanzamos SDK20 con cámara, pagos, almacenamiento seguro, magnetómetro, pausar/reanudar descargas fs y pantalla de inicio/carga mejorada.
Seguimos colaborando con Krzysztof en react-native-gesture-handler. Por favor pruébalo, reconstruye algún gesto que hayas implementado antes usando PanResponder o reconocedores de gestos nativos y cuéntanos qué problemas encuentras.
Experimentando con el protocolo de depuración de JSC, trabajando en varias solicitudes de características en Canny.
El mes pasado discutimos la gestión del rastreador de problemas en GitHub y cómo intentaríamos realizar mejoras para abordar la mantenibilidad del proyecto.
Actualmente, el número de problemas abiertos se mantiene estable alrededor de 600, y parece que podría continuar así por un tiempo. En el último mes, cerramos 690 problemas por inactividad (definida como ningún comentario en los últimos 60 días). De esos 690 problemas, 58 se reabrieron por diversas razones (un mantenedor se comprometió a solucionarlo, o un colaborador presentó argumentos sólidos para mantener el problema abierto).
Planeamos continuar con el cierre automatizado de issues inactivos en el futuro previsible. Queremos llegar a un estado donde cada issue significativo abierto en el tracker sea atendido, pero aún no estamos allí. Necesitamos toda la ayuda posible de los mantenedores para triar issues y asegurarnos de no pasar por alto aquellos que introducen regresiones o cambios disruptivos, especialmente los que afectan proyectos recién creados. Las personas interesadas en ayudar pueden usar el Facebook GitHub Bot para triar issues y pull requests. La nueva Guía para Mantenedores contiene más información sobre triaje y uso del GitHub Bot. ¡Por favor añádete al equipo de fuerza de issues y anima a otros miembros activos de la comunidad a hacer lo mismo!
La nueva aplicación Skype está construida sobre React Native para facilitar compartir la mayor cantidad de código posible entre plataformas. La aplicación Skype basada en React Native ya está disponible en las tiendas de aplicaciones de Android e iOS.
Mientras construíamos la aplicación Skype con React Native, enviamos pull requests a React Native para solucionar errores y características faltantes que encontramos. Hasta ahora, hemos logrado que se fusionen alrededor de 70 pull requests.
React Native nos permitió impulsar las aplicaciones Skype para Android e iOS desde la misma base de código. También queremos usar esa base de código para impulsar la aplicación web de Skype. Para ayudarnos a lograr ese objetivo, construimos y publicamos como código abierto una capa delgada sobre React/React Native llamada ReactXP. ReactXP proporciona un conjunto de componentes multiplataforma que se asignan a React Native cuando se dirige a iOS/Android y a react-dom cuando se dirige a la web. Los objetivos de ReactXP son similares a otra biblioteca de código abierto llamada React Native for Web. Hay una breve descripción de cómo difieren los enfoques de estas bibliotecas en las FAQ de ReactXP.
Continuamos nuestros esfuerzos para mejorar y simplificar la experiencia del desarrollador al crear aplicaciones usando Shoutem.
Comenzamos a migrar todas nuestras aplicaciones a react-navigation, pero terminamos posponiendo esto hasta que se lance una versión más estable o alguna de las soluciones de navegación nativa se estabilice.
Actualizando todas nuestras extensiones y la mayoría de nuestras bibliotecas de código abierto (animation, theme, ui) a React Native 0.47.1.
La próxima sesión está programada para el miércoles 13 de septiembre de 2017. Como esta fue solo nuestra tercera reunión, nos gustaría saber cómo estas notas benefician a la comunidad de React Native. No dudes en contactarme en Twitter si tienes alguna sugerencia sobre cómo deberíamos mejorar los resultados de la reunión.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
React Native se utiliza en múltiples lugares de diversas aplicaciones de la familia Facebook, incluida una pestaña principal en las aplicaciones principales de Facebook. El enfoque de este artículo es un producto altamente visible: Marketplace. Está disponible en una docena de países y permite a los usuarios descubrir productos y servicios ofrecidos por otros usuarios.
En el primer semestre de 2017, mediante el esfuerzo conjunto del equipo Relay, el equipo Marketplace, el equipo de Plataforma JS Móvil y el equipo React Native, redujimos a la mitad el Tiempo hasta la Interacción (TTI) de Marketplace en dispositivos Android de Year Class 2010-11. Facebook históricamente ha considerado estos dispositivos como Android de gama baja, y presentan los TTIs más lentos en cualquier plataforma o tipo de dispositivo.
Un inicio típico de React Native se ve así:
Aclaración: las proporciones no son representativas y variarán según cómo se configure y utilice React Native.
Primero inicializamos el núcleo de React Native (también llamado "Bridge") antes de ejecutar el JavaScript específico del producto, que determina qué vistas nativas renderizará React Native durante el Tiempo de Procesamiento Nativo.
Uno de nuestros primeros errores fue permitir que Systrace y CTScan guiaran nuestros esfuerzos de rendimiento. Estas herramientas nos ayudaron a encontrar muchas mejoras fáciles en 2016, pero descubrimos que tanto Systrace como CTScan no representan escenarios de producción reales y no pueden emular lo que ocurre en entornos reales. Las proporciones de tiempo en los desgloses suelen ser incorrectas y, a veces, completamente desacertadas. En casos extremos, algunas operaciones que esperábamos tomaran milisegundos tardaban cientos o miles de milisegundos. Dicho esto, CTScan es útil y hemos comprobado que detecta un tercio de las regresiones antes de que lleguen a producción.
En Android, atribuimos las limitaciones de estas herramientas a tres factores: 1) React Native es un framework multihilo, 2) Marketplace coexiste con múltiples vistas complejas como Newsfeed y otras pestañas principales, y 3) los tiempos de cálculo varían enormemente. Por ello, este semestre dejamos que las mediciones y desgloses de producción guiaran casi todas nuestras decisiones y priorizaciones.
Siguiendo el camino de la instrumentación en producción
Instrumentar la producción puede parecer simple superficialmente, pero resultó ser un proceso bastante complejo. Tomó múltiples ciclos de iteración de 2-3 semanas cada uno; debido a la latencia desde integrar un commit en master, hasta publicar la app en Play Store, y recopilar suficientes muestras de producción para validar nuestro trabajo. Cada ciclo implicaba verificar si nuestros desgloses eran precisos, si tenían el nivel adecuado de granularidad y si sumaban correctamente al tiempo total. No podíamos confiar en versiones alpha y beta porque no representan a la población general. En esencia, construimos meticulosamente un rastreo de producción muy preciso basado en millones de muestras agregadas.
Una razón por la que verificamos meticulosamente que cada milisegundo en los desgloses sumara correctamente a sus métricas padre fue que descubrimos vacíos en nuestra instrumentación. Resultó que nuestros desgloses iniciales no contabilizaban las pausas causadas por saltos entre hilos. Los saltos de hilo en sí no son costosos, pero saltar a hilos ocupados que ya están trabajando es muy costoso. Finalmente reproducimos estos bloqueos localmente agregando llamadas Thread.sleep() en momentos clave, y los solucionamos mediante:
eliminar nuestra dependencia de AsyncTask,
revertir la inicialización forzada de ReactContext y NativeModules en el hilo UI, y
eliminar la dependencia de medir ReactRootView durante la inicialización.
Juntos, la eliminación de estos problemas de bloqueo de hilos redujo el tiempo de inicio en más de un 25%.
Las métricas de producción también desafiaron algunas de nuestras suposiciones anteriores. Por ejemplo, solíamos precargar muchos módulos de JavaScript en la ruta de inicio bajo el supuesto de que ubicar módulos juntos en un único paquete reduciría su costo de inicialización. Sin embargo, el costo de precargar y colocar estos módulos superó ampliamente los beneficios. Al reconfigurar nuestras listas negras de requerimientos en línea y eliminar módulos de JavaScript de la ruta de inicio, pudimos evitar cargar módulos innecesarios como Relay Classic (cuando solo Relay Modern era necesario). Hoy, nuestro desglose RUN_JS_BUNDLE es más de un 75% más rápido.
También encontramos mejoras al investigar módulos nativos específicos del producto. Por ejemplo, al inyectar de manera diferida las dependencias de un módulo nativo, redujimos el costo de ese módulo nativo en un 98%. Al eliminar la contención del inicio de Marketplace con otros productos, reducimos el inicio en un intervalo equivalente.
Lo mejor es que muchas de estas mejoras son ampliamente aplicables a todas las pantallas construidas con React Native.
La gente asume que los problemas de rendimiento en el inicio de React Native son causados por JavaScript lento o tiempos de red excesivamente altos. Si bien acelerar cosas como JavaScript reduciría el TTI en una cantidad no trivial, cada uno de estos factores contribuye con un porcentaje mucho menor del TTI de lo que se creía anteriormente.
La lección hasta ahora ha sido: ¡mide, mide, mide! Algunas mejoras provienen de trasladar costos de tiempo de ejecución al tiempo de compilación, como Relay Modern y los Módulos Nativos Diferidos. Otras mejoras provienen de evitar trabajo al ser más inteligentes sobre la paralelización de código o eliminar código muerto. Y algunas mejoras provienen de grandes cambios arquitectónicos en React Native, como limpiar bloqueos de hilos. No existe una solución grandiosa para el rendimiento, y las mejoras de rendimiento a largo plazo provendrán de instrumentación incremental y optimizaciones. No permitas que el sesgo cognitivo influya en tus decisiones. En su lugar, recopila e interpreta cuidadosamente datos de producción para guiar el trabajo futuro.
A largo plazo, queremos que el TTI de Marketplace sea comparable al de productos similares construidos nativamente y, en general, que el rendimiento de React Native esté a la par del rendimiento nativo. Además, aunque este semestre redujimos drásticamente el costo de inicio del puente en aproximadamente un 80%, planeamos llevar el costo del puente de React Native cerca de cero mediante proyectos como Prepack y más procesamiento en tiempo de compilación.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
¡Continúa nuestra reunión mensual de React Native! En esta sesión nos acompañó Infinite Red, los creadores de Chain React, la Conferencia de React Native. Como la mayoría de los asistentes estaban presentando charlas en Chain React, pospusimos la reunión una semana. Las charlas de la conferencia ya están disponibles online y les recomiendo verlas. Veamos qué están haciendo nuestros equipos.
Mike Grabowski sigue gestionando las versiones mensuales de React Native como siempre, incluyendo algunas betas publicadas. En particular, está trabajando en publicar la versión v0.43.5 en npm ¡ya que desbloquea a los usuarios de Windows!
El trabajo en Haul avanza lento pero constante. Hay un pull request que añade HMR y ya se han implementado otras mejoras. Recientemente varios líderes de la industria lo han adoptado. Posiblemente comenzaremos trabajo remunerado a tiempo completo en esta área.
Tenemos varias novedades interesantes de nuestro departamento de OSS. En particular, estamos trabajando en integrar Material Palette API en React Native. Planeamos finalmente lanzar nuestro kit nativo para iOS que busca ofrecer un look & feel idéntico a los componentes nativos.
Recientemente lanzamos Native Directory para mejorar el descubrimiento y evaluación de bibliotecas en el ecosistema React Native. El problema: existen muchas bibliotecas, son difíciles de probar, requieren aplicar heurísticas manualmente y no es evidente cuáles son las mejores que deberías usar. También es difícil determinar si algo es compatible con CRNA/Expo. Native Directory busca resolver estos problemas. ¡Visítalo y añade tu biblioteca! La lista de bibliotecas está aquí. Esta es solo nuestra primera versión, y queremos que sea propiedad y gestión de la comunidad, no solo del equipo de Expo. ¡Contribuye si crees que es valioso y quieres mejorarlo!
Añadimos soporte inicial para instalar paquetes npm en Snack con Expo SDK 19. Avísanos si encuentras problemas, aún estamos resolviendo algunos errores. Junto con Native Directory, esto debería facilitar probar bibliotecas con dependencias solo JavaScript o incluidas en el Expo SDK. Pruébalo:
Trabajando en una guía documental con Alexander Kotliarskyi con consejos para mejorar la experiencia de usuario en apps. ¡Únete para ampliar la lista o colaborar en la redacción!
Continuamos trabajando en: audio/video, cámara, gestos (con Software Mansion, react-native-gesture-handler), integración de cámara GL. Esperamos lanzar algunas novedades en SDK20 (agosto) con mejoras significativas. Estamos iniciando la infraestructura en el cliente Expo para trabajos en segundo plano (geolocalización, audio, manejo de notificaciones, etc.).
Facebook explora internamente integrar componentes nativos de ComponentKit y Litho dentro de React Native.
¡Las contribuciones a React Native son muy bienvenidas! Si te preguntas cómo puedes contribuir, la guía "Cómo contribuir" describe nuestro proceso de desarrollo y detalla los pasos para enviar tu primer pull request. Hay otras formas de contribuir que no requieren escribir código, como clasificar incidencias o actualizar la documentación.
Al momento de escribir, React Native tiene 635incidencias abiertas y 249pull requests abiertos. Esto resulta abrumador para nuestros mantenedores, y cuando los problemas se solucionan internamente, es difícil actualizar las tareas correspondientes.
No estamos seguros del mejor enfoque para manejar esto manteniendo satisfecha a la comunidad. ¡Algunas opciones (no todas!) incluyen cerrar incidencias obsoletas, otorgar permisos a más personas para gestionar incidencias y cerrar automáticamente aquellas que no sigan la plantilla. Creamos la guía "Qué esperar de los mantenedores" para establecer expectativas y evitar sorpresas. Si tienes ideas para mejorar esta experiencia tanto para mantenedores como para quienes reportan incidencias o envían pull requests (asegurando que se sientan escuchados y valorados), ¡háznoslo saber!
Presentamos nuestra herramienta de diseño que funciona con archivos de React Native en Chain React. Muchos asistentes se inscribieron en la lista de espera.
También estamos explorando otras soluciones multiplataforma como Google Flutter (próximamente una comparativa detallada), Kotlin Native y Apache Weex para entender diferencias arquitectónicas y aprender cómo mejorar el rendimiento general de React Native.
Migramos a react-navigation en la mayoría de nuestras apps, mejorando significativamente el rendimiento.
Además, anunciamos NativeBase Market: un marketplace para componentes y aplicaciones de React Native (creado por y para desarrolladores).
CodePush se integró en Mobile Center. Los usuarios actuales no verán cambios en su flujo de trabajo.
Algunos reportaron problemas con apps duplicadas (por tener apps existentes en Mobile Center). Estamos resolviendo estos casos; si tienes apps duplicadas, avísanos para fusionarlas.
Mobile Center ahora soporta Notificaciones Push para CodePush. Mostramos cómo combinar Notificaciones y CodePush para pruebas A/B en apps, algo único en la arquitectura de React Native.
VS Code tiene un problema conocido en la depuración con React Native; la próxima versión de la extensión (en pocos días) lo solucionará.
Dado que múltiples equipos en Microsoft trabajan con React Native, mejoraremos la representación de todos los grupos en próximas reuniones.
Finalizamos las mejoras para simplificar el desarrollo con React Native en Shoutem. Ahora puedes usar todos los comandos estándar de react-native al desarrollar apps en Shoutem.
Dedicamos mucho esfuerzo para determinar el mejor enfoque para el análisis de rendimiento en React Native. Gran parte de la documentación está desactualizada, así que haremos nuestro mejor esfuerzo para crear un pull request en la documentación oficial o al menos publicar nuestras conclusiones en una entrada de blog.
Estamos migrando nuestra solución de navegación a react-navigation, por lo que pronto podríamos tener comentarios al respecto.
Lanzamos un nuevo componente HTML en nuestro kit que transforma HTML crudo en un árbol de componentes de React Native.
Comenzamos a trabajar en un pull request para Metro Bundler con capacidades de react-native-repackager. Actualizamos react-native-repackager para soportar RN 44 (que usamos en producción). Lo estamos utilizando para nuestra infraestructura de simulación en detox.
Durante las últimas tres semanas hemos cubierto la aplicación de Wix con pruebas detox. Ha sido una experiencia increíble para aprender cómo reducir el control de calidad manual en una aplicación de esta escala (más de 40 ingenieros). Como resultado, resolvimos varios problemas con detox y acabamos de publicar una nueva versión. Me complace informar que estamos cumpliendo con la "política de cero imprevisibilidad" y las pruebas hasta ahora pasan consistentemente.
Detox para Android avanza muy bien. Estamos recibiendo ayuda significativa de la comunidad. Esperamos tener una versión inicial en aproximadamente dos semanas.
DetoxInstruments, nuestra herramienta de pruebas de rendimiento, está creciendo más de lo que planeamos originalmente. Ahora planeamos convertirla en una herramienta independiente que no estará tan acoplada a detox. Permitirá investigar el rendimiento de aplicaciones iOS en general. También se integrará con detox para ejecutar pruebas automatizadas sobre métricas de rendimiento.
La próxima sesión está programada para el 16 de agosto de 2017. Como esta fue solo nuestra segunda reunión, nos gustaría saber cómo estas notas benefician a la comunidad de React Native. No dudes en contactarme en Twitter si tienes sugerencias sobre cómo mejorar el resultado de estas reuniones.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
En Shoutem, hemos tenido la fortuna de trabajar con React Native desde sus inicios. Decidimos que queríamos ser parte de esta increíble comunidad desde el primer día. Pronto nos dimos cuenta de que era casi imposible seguir el ritmo al que la comunidad crecía y mejoraba. Por eso decidimos organizar una reunión mensual donde los principales contribuidores de React Native puedan presentar brevemente sus esfuerzos y planes.
Tuvimos nuestra primera sesión el 14 de junio de 2017. La misión de React Native Monthly es simple y directa: mejorar la comunidad de React Native. Presentar los esfuerzos de los equipos facilita la colaboración entre ellos fuera de línea.
Dado que los planes de los equipos pueden interesar a una audiencia más amplia, los compartiremos aquí, en el blog de React Native. Así que aquí están:
Buscan mejorar el proceso de lanzamientos usando Detox para pruebas E2E. El pull request debería integrarse pronto.
Su pull request sobre Blob ha sido fusionado, vendrán más pull requests relacionados.
Incrementando la adopción de Haul en proyectos internos para comparar su rendimiento con Metro Bundler. Trabajan con el equipo de webpack en mejoras de rendimiento multihilo.
Internamente han implementado mejor infraestructura para gestionar proyectos open source. Planean publicar más contenido en las próximas semanas.
La conferencia React Native Europe avanza, aún sin novedades destacables, ¡pero todos estáis invitados!
Se han tomado un descanso de react-navigation para investigar alternativas (especialmente navegaciones nativas).
Create React Native App está incluido en la guía de inicio de la documentación. Expo quiere animar a los autores de bibliotecas a explicar claramente si sus librerías funcionan con CRNA o no, y en caso afirmativo, detallar cómo configurarlas.
El empaquetador de React Native ahora es Metro Bundler, en un repositorio independiente. El equipo de Metro Bundler en Londres está entusiasmado por abordar las necesidades de la comunidad, mejorar la modularidad para casos de uso más allá de React Native, y aumentar la capacidad de respuesta en issues y PRs.
En los próximos meses, el equipo de React Native trabajará en refinar las APIs de componentes primitivos. Esperen mejoras en peculiaridades de diseño, accesibilidad y tipado con Flow.
El equipo de React Native también planea mejorar la modularidad del núcleo este año, mediante refactorizaciones para soportar completamente plataformas de terceros como Windows y macOS.
El equipo está trabajando en una aplicación de diseño UI/UX (nombre en clave: Builder) que funciona directamente con archivos .js. Actualmente solo soporta React Native. Es similar a Adobe XD y Sketch.
El equipo trabaja intensamente para que puedas cargar una aplicación React Native existente en el editor, hacer cambios (visualmente, como diseñador) y guardarlos directamente en el archivo JS.
Buscan acortar la brecha entre diseñadores y desarrolladores, uniéndolos en el mismo repositorio.
Además, NativeBase alcanzó recientemente 5,000 estrellas en GitHub.
CodePush se ha integrado ahora en Mobile Center. Este es el primer paso para ofrecer una experiencia mucho más integrada con distribución, analíticas y otros servicios. Consulten su anuncio aquí.
VS Code tiene un error con la depuración; están trabajando en solucionarlo ahora y lanzarán una nueva versión.
Investigando Detox para pruebas de integración, explorando JSC Context para obtener variables junto con informes de fallos.
Facilitando el trabajo en aplicaciones Shoutem con herramientas de la comunidad React Native. Podrás usar todos los comandos de React Native para ejecutar aplicaciones creadas en Shoutem.
Investigando herramientas de profiling para React Native. Tuvieron muchos problemas de configuración y compartirán algunas conclusiones descubiertas en el proceso.
Shoutem está trabajando para facilitar la integración de React Native con aplicaciones nativas existentes. Documentarán el concepto desarrollado internamente para obtener retroalimentación de la comunidad.
Trabajando internamente para adoptar Detox y trasladar partes significativas de la aplicación Wix a "QA manual cero". Como resultado, Detox se usa intensivamente en producción por docenas de desarrolladores y está madurando rápidamente.
Trabajando para añadir soporte en Metro Bundler que permita sobrescribir cualquier extensión de archivo durante la compilación. En lugar de solo "ios" y "android", soportaría extensiones personalizadas como "e2e" o "detox". Planean usar esto para simulación E2E. Ya existe una biblioteca llamada react-native-repackager, y ahora están trabajando en un PR.
Investigando la automatización de pruebas de rendimiento. Este es un nuevo repositorio llamado DetoxInstruments. Puedes echarle un vistazo, se está desarrollando como código abierto.
Colaborando con un contribuidor de KPN en Detox para Android y soporte para dispositivos físicos.
Explorando el concepto de "Detox como plataforma" para permitir construir otras herramientas que necesiten automatizar simuladores/dispositivos. Un ejemplo es Storybook para React Native o la idea de Ram para pruebas de integración.
Las reuniones se realizarán cada cuatro semanas. La próxima sesión está programada para el 12 de julio de 2017. Como acabamos de comenzar con este formato, nos gustaría saber cómo estas notas benefician a la comunidad de React Native. No dudes en contactarme en Twitter si tienes sugerencias sobre qué deberíamos cubrir en futuras sesiones o cómo mejorar los resultados de estas reuniones.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
Muchos de ustedes ya han empezado a probar nuestros nuevos componentes de lista tras nuestro anuncio preliminar en el grupo comunitario, ¡pero hoy los anunciamos oficialmente! Adiós a los ListView, DataSource, filas obsoletas, errores ignorados y consumo excesivo de memoria. Con el último candidato a lanzamiento de React Native de marzo 2017 (0.43-rc.1), puedes elegir entre esta nueva suite de componentes lo que mejor se adapte a tu caso de uso, con gran rendimiento y funciones listas para usar:
Si necesitas renderizar datos organizados en secciones lógicas (como en una agenda alfabética con encabezados), o con datos heterogéneos y renderizados diversos (por ejemplo: una vista de perfil con botones, seguida de un compositor, luego una cuadrícula de fotos, otra de amigos y finalmente historias), esta es la opción ideal.
El estado interno de los subcomponentes no se preserva al salir de la ventana de renderizado. Asegúrate de capturar todos los datos en el ítem o almacenes externos como Flux, Redux o Relay.
Estos componentes se basan en PureComponent, lo que significa que no se rerenderizarán si los props permanecen superficialmente iguales. Asegúrate que todo lo que usa tu función renderItem se pase como prop que no sea === tras actualizaciones, o tu UI podría no actualizarse. Esto incluye el prop data y el estado del componente padre. Ejemplo:
<FlatList data={this.state.data} renderItem={({item})=>( <MyItem item={item} onPress={()=> this.setState(oldState=>({ selected:{ // New instance breaks `===` ...oldState.selected,// copy old data [item.key]:!oldState.selected[item.key],// toggle }, })) } selected={ !!this.state.selected[item.key]// renderItem depends on state } /> )} selected={ // Can be any prop that doesn't collide with existing props this.state.selected// A change to selected should re-render FlatList } />
Para optimizar memoria y permitir scroll fluido, el contenido se renderiza asíncronamente fuera de pantalla. Esto puede causar que al hacer scroll muy rápido aparezca contenido vacío momentáneamente. Es una compensación ajustable por aplicación, y estamos trabajando en mejoras internas.
Por defecto, estas listas buscan una prop key en cada ítem para la clave de React. Alternativamente, puedes usar keyExtractor.
Además de simplificar la API, los nuevos componentes de lista también ofrecen mejoras significativas de rendimiento, siendo la principal un uso de memoria casi constante para cualquier cantidad de filas. Esto se logra "virtualizando" elementos fuera de la ventana de renderizado desmontándolos completamente de la jerarquía de componentes y liberando la memoria JS de los componentes React, junto con la memoria nativa del shadow tree y las vistas de UI. Esto tiene una salvedad: el estado interno del componente no se conservará, así que asegúrate de guardar cualquier estado importante fuera de los componentes mismos, por ejemplo en almacenes de Relay, Redux o Flux.
Limitar la ventana de renderizado también reduce el trabajo requerido por React y la plataforma nativa, como en recorridos de vistas. Incluso al renderizar el último de un millón de elementos, con estas nuevas listas no necesitas iterar todos los elementos para renderizar. Puedes saltar al centro con scrollToIndex sin renderizado excesivo.
También mejoramos la programación para aumentar la capacidad de respuesta de las aplicaciones. Los elementos en el borde de la ventana de renderizado se procesan con menos frecuencia y menor prioridad, después de completarse gestos, animaciones u otras interacciones activas.
A diferencia de ListView, todos los elementos en la ventana de renderizado se vuelven a renderizar cuando cambian las props. Suele ser aceptable porque la ventana reduce los elementos a una cantidad constante, pero si tus elementos son complejos, sigue las mejores prácticas de React para rendimiento usando React.PureComponent y/o shouldComponentUpdate según corresponda en tus componentes para limitar re-renderizados del subárbol recursivo.
Si puedes calcular la altura de tus filas sin renderizarlas, mejora la experiencia del usuario proporcionando la prop getItemLayout. Esto suaviza el desplazamiento a elementos específicos con ej. scrollToIndex, y mejora la UI del indicador de scroll al determinar la altura del contenido sin renderizarlo.
Para tipos de datos alternativos como listas inmutables, usa <VirtualizedList>. Toma una prop getItem que devuelve datos del elemento para cualquier índice, con tipado de Flow más flexible.
Hay múltiples parámetros ajustables para casos inusuales: usa windowSize para equilibrar memoria/experiencia de usuario, maxToRenderPerBatch para ajustar tasa de llenado/capacidad de respuesta, onEndReachedThreshold para controlar la carga al desplazar, y más.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
En Facebook, a menudo necesitamos acceder a valores profundamente anidados en estructuras de datos obtenidas con GraphQL. Al intentar acceder a estos valores, es común que uno o más campos intermedios sean nulos. Estos campos intermedios pueden ser nulos por diversas razones, desde controles de privacidad fallidos hasta el simple hecho de que null es la forma más flexible de representar errores no fatales.
Desafortunadamente, acceder a estos valores profundamente anidados es actualmente tedioso y verboso.
Existe una propuesta de ECMAScript para introducir el operador existencial que haría esto mucho más conveniente. Pero hasta que esa propuesta se finalice, queremos una solución que mejore nuestra calidad de vida, mantenga la semántica existente del lenguaje y fomente la seguridad de tipos con Flow.
Creamos una función existencial que llamamos idx.
idx(props,_=> _.user.friends[0].friends);
La invocación en este fragmento de código se comporta de manera similar a la expresión booleana en el fragmento anterior, pero con significativamente menos repetición. La función idx toma exactamente dos argumentos:
Cualquier valor, típicamente un objeto o array del cual quieres acceder a un valor anidado.
Una función que recibe el primer argumento y accede a un valor anidado en él.
En teoría, la función idx capturará errores que resulten de acceder a propiedades en null o undefined. Si se detecta tal error, devolverá null o undefined. (Puedes ver cómo se implementa esto en idx.js.)
En la práctica, capturar errores en cada acceso a propiedades anidadas es lento, y diferenciar entre tipos específicos de TypeErrors es frágil. Para abordar estas limitaciones, creamos un plugin de Babel que transforma la invocación de idx anterior en la siguiente expresión:
Finalmente, añadimos una declaración de tipo personalizada de Flow para idx que permite verificar correctamente el recorrido en el segundo argumento mientras permite el acceso anidado en propiedades que pueden ser nulas.
La función, el plugin de Babel y la declaración de Flow están ahora disponibles en GitHub. Se utilizan instalando los paquetes npm idx y babel-plugin-idx, y agregando "idx" a la lista de plugins en tu archivo .babelrc.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
Hoy anunciamos Create React Native App: ¡una nueva herramienta que facilita significativamente comenzar con un proyecto de React Native! Está fuertemente inspirada en el diseño de Create React App y es el resultado de una colaboración entre Facebook y Expo (anteriormente Exponent).
Muchos desarrolladores enfrentan dificultades al instalar y configurar las dependencias nativas actuales de React Native, especialmente para Android. Con Create React Native App, no es necesario usar Xcode ni Android Studio, y puedes desarrollar para dispositivos iOS usando Linux o Windows. Esto se logra mediante la aplicación Expo, que carga y ejecuta proyectos CRNA escritos en JavaScript puro sin compilar código nativo.
Prueba crear un nuevo proyecto (reemplaza con comandos de yarn si lo tienes instalado):
$ npm i -g create-react-native-app $ create-react-native-app my-project $ cd my-project $ npm start
Esto iniciará el empaquetador de React Native y mostrará un código QR. Ábrelo en la aplicación Expo para cargar tu JavaScript. Las llamadas a console.log se redirigen a tu terminal. Puedes utilizar cualquier API estándar de React Native, así como el SDK de Expo.
Muchos proyectos de React Native tienen dependencias en Java u Objective-C/Swift que requieren compilación. La aplicación Expo sí incluye APIs para cámara, video, contactos y más, además de incluir bibliotecas populares como react-native-maps de Airbnb o autenticación de Facebook. Sin embargo, si necesitas una dependencia de código nativo que Expo no incluye, probablemente necesitarás tu propia configuración de compilación. Al igual que Create React App, CRNA admite la "expulsión" (ejecting).
Puedes ejecutar npm run eject para obtener un proyecto muy similar al que generaría react-native init. En ese punto, necesitarás Xcode y/o Android Studio, como si hubieras comenzado con react-native init. Agregar bibliotecas con react-native link funcionará y tendrás control total sobre el proceso de compilación de código nativo.
Create React Native App es ahora lo suficientemente estable para uso general, ¡lo que significa que estamos muy interesados en conocer tu experiencia usándolo! Puedes encontrarme en Twitter o abrir un issue en el repositorio de GitHub. ¡Las solicitudes de extracción (pull requests) son bienvenidas!
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
Durante el último año, hemos trabajado en mejorar el rendimiento de las animaciones que utilizan la biblioteca Animated. Las animaciones son muy importantes para crear una experiencia de usuario atractiva, pero también pueden ser difíciles de implementar correctamente. Queremos facilitar a los desarrolladores la creación de animaciones de alto rendimiento sin que tengan que preocuparse por que parte de su código cause retrasos.
La API Animated se diseñó con una restricción muy importante en mente: es serializable. Esto significa que podemos enviar toda la información sobre la animación al entorno nativo antes de que comience, lo que permite que el código nativo ejecute la animación en el hilo de la interfaz de usuario sin tener que pasar por el puente en cada fotograma. Es muy útil porque una vez que la animación ha comenzado, el hilo de JavaScript puede bloquearse y la animación seguirá ejecutándose sin problemas. En la práctica, esto puede ocurrir con frecuencia porque el código del usuario se ejecuta en el hilo de JavaScript y los renders de React también pueden bloquear JS durante mucho tiempo.
Este proyecto comenzó hace aproximadamente un año, cuando Expo construyó la aplicación li.st en Android. Contrataron a Krzysztof Magiera para construir la implementación inicial en Android. Terminó funcionando bien y li.st fue la primera aplicación en implementar animaciones nativas usando Animated. Unos meses después, Brandon Withrow construyó la implementación inicial en iOS. Luego, Ryan Gomba y yo trabajamos en agregar funciones faltantes como soporte para Animated.event, además de corregir errores que encontramos al usarlo en aplicaciones de producción. Este fue verdaderamente un esfuerzo comunitario y me gustaría agradecer a todos los involucrados, así como a Expo por patrocinar gran parte del desarrollo. Ahora se utiliza en los componentes Touchable de React Native, así como para animaciones de navegación en la biblioteca recién lanzada React Navigation.
Primero, veamos cómo funcionan actualmente las animaciones usando Animated con el controlador JS. Al usar Animated, declaras un grafo de nodos que representan las animaciones que deseas realizar, y luego usas un controlador para actualizar un valor Animated usando una curva predefinida. También puedes actualizar un valor Animated conectándolo a un evento de una View mediante Animated.event.
Aquí hay un desglose de los pasos para una animación y dónde ocurren:
JS: El controlador de animación usa requestAnimationFrame para ejecutarse en cada fotograma y actualizar el valor que controla, utilizando el nuevo valor que calcula basado en la curva de animación.
JS: Se calculan valores intermedios y se pasan a un nodo de propiedades que está adjunto a una View.
JS: La View se actualiza mediante setNativeProps.
Puente de JS a Native.
Nativo: Se actualiza el UIView o android.View.
Como puedes ver, la mayor parte del trabajo ocurre en el hilo de JS. Si este se bloquea, la animación omitirá fotogramas. También necesita pasar por el puente de JS a Native en cada fotograma para actualizar las vistas nativas.
Lo que hace el controlador nativo es mover todos estos pasos al entorno nativo. Como Animated produce un grafo de nodos animados, puede serializarse y enviarse a native solo una vez al iniciar la animación, eliminando la necesidad de volver al hilo de JS; el código nativo puede encargarse de actualizar las vistas directamente en el hilo de UI en cada fotograma.
Aquí un ejemplo de cómo podemos serializar un valor animado y un nodo de interpolación (no la implementación exacta, solo un ejemplo).
Crea el nodo de valor nativo, este es el valor que se animará:
Con esto, el módulo animado nativo tiene toda la información necesaria para actualizar las vistas nativas directamente sin tener que pasar por JS para calcular ningún valor.
Solo queda iniciar la animación especificando el tipo de curva de animación deseado y qué valor animado actualizar. Las animaciones de temporización también pueden simplificarse precalculando cada fotograma de la animación en JS para reducir la implementación nativa.
Y este es el desglose de lo que ocurre cuando se ejecuta la animación:
Nativo: El controlador de animación nativo usa CADisplayLink o android.view.Choreographer para ejecutarse en cada fotograma y actualizar el valor que controla usando el nuevo valor calculado según la curva de animación.
Nativo: Se calculan valores intermedios y se pasan a un nodo de propiedades conectado a una vista nativa.
Nativo: Se actualiza el UIView o android.View.
Como puedes ver, ¡no hay más hilo JS ni puente, lo que significa animaciones más rápidas! 🎉🎉
Animated.timing(this.state.animatedValue,{ toValue:1, duration:500, useNativeDriver:true,// <-- Add this }).start();
Los valores animados solo son compatibles con un controlador. Si usas el controlador nativo al iniciar una animación en un valor, asegúrate de que todas las animaciones posteriores en ese valor también usen el controlador nativo.
También funciona con Animated.event, lo cual es muy útil para animaciones que deben seguir la posición de desplazamiento, ya que sin el controlador nativo siempre irán un fotograma atrás del gesto debido a la naturaleza asíncrona de React Native.
<Animated.ScrollView// <-- Use the Animated ScrollView wrapper scrollEventThrottle={1}// <-- Use 1 here to make sure no events are ever missed onScroll={Animated.event( [{ nativeEvent:{ contentOffset:{ y:this.state.animatedValue}}}], { useNativeDriver:true}// <-- Add this )} > {content} </Animated.ScrollView>
No todo lo que puedes hacer con Animated está actualmente soportado en Animated Nativo. La principal limitación es que solo puedes animar propiedades no relacionadas con el diseño: propiedades como transform y opacity funcionarán, pero Flexbox y propiedades de posición no. Otra limitación es que Animated.event solo funciona con eventos directos, no con eventos de propagación. Esto significa que no funciona con PanResponder pero sí con elementos como ScrollView#onScroll.
Animated Nativo ha sido parte de React Native durante bastante tiempo, pero nunca se documentó porque se consideraba experimental. Por eso, asegúrate de usar una versión reciente (0.40+) de React Native si quieres usar esta función.
Si quieres un análisis profundo sobre animaciones y cómo delegarlas a nativo puede mejorar la experiencia de usuario, también está esta charla de Krzysztof Magiera.
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto.
¿Encontraste un error? Reportar problema →
Tras publicar una aplicación en las tiendas de apps, la internacionalización es el siguiente paso para ampliar tu alcance de audiencia. Más de 20 países y numerosas personas en todo el mundo utilizan idiomas de derecha a izquierda (RTL). Por lo tanto, es fundamental que tu aplicación ofrezca soporte RTL para estos usuarios.
Nos complace anunciar que React Native ha sido mejorado para soportar diseños RTL. Esta funcionalidad ya está disponible en la rama principal de react-native y estará incluida en la próxima versión candidata: v0.33.0-rc.
Esto implicó modificar css-layout, el motor de diseño central utilizado por RN, la implementación principal de RN, así como componentes JS específicos de código abierto para admitir RTL.
Para probar exhaustivamente el soporte RTL en producción, la última versión de la aplicación Facebook Ads Manager (la primera app multiplataforma 100% RN) ya está disponible en árabe y hebreo con diseños RTL tanto para iOS como para Android. Así es como se ve en estos idiomas RTL:
css-layout ya maneja el concepto de start (inicio) y end (fin) para el diseño. En el flujo izquierda-derecha (LTR), start equivale a left (izquierda) y end a right (derecha). Pero en RTL, start significa right y end significa left. Esto permite que RN utilice los cálculos de start y end para determinar el diseño correcto, incluyendo position, padding y margin.
Además, css-layout hace que la dirección de cada componente herede de su elemento padre. Esto significa que simplemente debemos configurar la dirección del componente raíz como RTL, y toda la aplicación se invertirá automáticamente.
El siguiente diagrama describe los cambios a alto nivel:
Permite el diseño RTL en tu aplicación llamando a la función allowRTL() al inicio del código nativo. Hemos proporcionado esta utilidad para aplicar el diseño RTL solo cuando tu aplicación esté lista. Aquí tienes un ejemplo:
iOS:
// in AppDelegate.m [[RCTI18nUtil sharedInstance] allowRTL:YES];
Android:
// in MainActivity.java I18nUtil sharedI18nUtilInstance =I18nUtil.getInstance(); sharedI18nUtilInstance.allowRTL(context,true);
Para Android, debes agregar android:supportsRtl="true" al elemento <application> en el archivo AndroidManifest.xml.
Ahora, cuando recompiles tu aplicación y cambies el idioma del dispositivo a uno RTL (como árabe o hebreo), el diseño de tu aplicación debería cambiar automáticamente a RTL.
En general, la mayoría de componentes ya están preparados para RTL, por ejemplo:
Diseño izquierda-derecha (LTR)
Diseño derecha-izquierda (RTL)
Sin embargo, hay varios casos a considerar donde necesitarás el I18nManager. En I18nManager, existe la constante isRTL que indica si el diseño es RTL, permitiéndote realizar ajustes según la dirección del layout.
Si tu componente usa iconos o imágenes, se mostrarán igual en diseños LTR y RTL porque RN no voltea las imágenes originales. Debes invertirlos manualmente según la dirección del layout.
En desarrollo para Android/iOS, al cambiar a RTL los gestos y animaciones se invierten respecto a LTR. Actualmente en RN, estos no tienen soporte a nivel de núcleo pero sí en componentes. Algunos como SwipeableRow y NavigationExperimental ya soportan RTL, pero otros componentes con gestos requerirán ajustes manuales.
Un ejemplo claro de soporte para gestos en RTL es SwipeableRow.
Mantenimiento de tu aplicación preparada para RTL
Incluso después del lanzamiento inicial de una app compatible con RTL, probablemente necesitarás iterar en nuevas funciones. Para mejorar la eficiencia de desarrollo, I18nManager proporciona la función forceRTL() para pruebas RTL más rápidas sin cambiar el idioma del dispositivo de prueba. Podrías incluir un interruptor simple para esto en tu aplicación. Aquí un ejemplo del caso RTL en RNTester:
<RNTesterBlock title={'Quickly Test RTL Layout'}> <View style={styles.flexDirectionRow}> <Text style={styles.switchRowTextView}>forceRTL</Text> <View style={styles.switchRowSwitchView}> <Switch onValueChange={this._onDirectionChange} style={styles.rightAlignStyle} value={this.state.isRTL} /> </View> </View> </RNTesterBlock>; _onDirectionChange=()=>{ I18nManager.forceRTL(!this.state.isRTL); this.setState({isRTL:!this.state.isRTL}); Alert.alert( 'Reload this page', 'Please reload this page to change the UI direction! '+ 'All examples in this app will be affected. '+ 'Check them out to see what they look like in RTL layout.', ); };
Al trabajar en una nueva función, puedes alternar fácilmente este botón y recargar la app para ver el diseño RTL. La ventaja es que no necesitarás cambiar la configuración de idioma para probar, aunque algunas alineaciones de texto no cambiarán, como se explica en la siguiente sección. Por lo tanto, siempre es recomendable probar tu app en el idioma RTL antes del lanzamiento.
El soporte RTL debería cubrir la mayoría de la experiencia de usuario en tu app; sin embargo, actualmente existen algunas limitaciones:
Los comportamientos de alineación de texto difieren en Android e iOS
En iOS, la alineación predeterminada depende del paquete de idioma activo y es consistente en un lado. En Android, la alineación predeterminada depende del idioma del contenido: inglés se alinea a la izquierda y árabe a la derecha.
En teoría, esto debería ser consistente entre plataformas, pero algunos usuarios pueden preferir un comportamiento sobre otro. Se necesita más investigación de experiencia de usuario para determinar las mejores prácticas.
No existe una "verdadera" izquierda/derecha
Como se mencionó anteriormente, mapeamos los estilos left/right de JS a start/end. Todo left en código para diseño RTL se convierte en "derecha" en pantalla, y right en código se convierte en "izquierda". Esto es conveniente porque no requiere muchos cambios en tu código, pero significa que no hay forma de especificar "verdadera izquierda" o "verdadera derecha" en el código. En el futuro, podría ser necesario permitir que un componente controle su dirección independientemente del idioma.
Hacer el soporte RTL para gestos y animaciones más accesible
Actualmente, aún se requiere esfuerzo de programación para hacer compatibles gestos y animaciones con RTL. Idealmente, en el futuro se podría simplificar este soporte para desarrolladores.
