Mejores Prácticas de Brownfield
Un resumen condensado de las 25 mejores prácticas más importantes extraídas de todas las páginas de esta sección.
//
Busca en todas las páginas de la documentación
Un resumen condensado de las 25 mejores prácticas más importantes extraídas de todas las páginas de esta sección.
Define brownfield explícitamente: Si el AppDelegate / Application nativo posee la interfaz de usuario raíz, RN es un invitado - planifica los límites de embebimiento antes de elegir rutas de Expo Router.
Puntuación embebimiento vs reescritura vs WebView por característica: Usa la matriz de tres vías en Brownfield Basics - shells de WebView permanentes sin un ADR al atardecer son un modo de fallo común.
Por defecto artefactos aislados expo-brownfield: AAR + Swift Package permite que la CI nativa omita Node cuando los equipos están divididos - integrado solo cuando un escuadrón edita ambos lados diariamente.
Un empaquetador Metro por módulo embebido: Dos runtimes de RN en un proceso requieren multipleFrameworks: true en iOS y una estrategia de símbolos deliberada - evita proyectos Metro accidentales dobles.
Inicializa ReactNativeHostManager una vez en el lanzamiento de la aplicación: La inicialización tardía causa pantallas RN en blanco y ciclo de vida de módulos Expo inestables - refleja los documentos de Expo en el host AppDelegate / Application.
Coincide moduleName con registro JS: El host ReactNativeViewController(moduleName:) debe alinearse con registerRootComponent / entrada app.json - la falta de coincidencia muestra pantalla blanca sin error de JS.
Pin Expo SDK en expo y expo-brownfield: Usa npx expo install en SDK 57 - Hermes y binarios nativos se desvían si las versiones divergen.
Ejecuta npx expo-doctor en cada construcción de artefacto: Captura el skew de módulo nativo antes de que los consumidores Maven/XCFramework publicados ingieran artefactos malos.
Versiona artefactos Android en config del plugin: android.version debe coincidir con coordinadas Maven - etiqueta Git y Maven con el mismo semver.
Envía paquetes Swift de depuración y lanzamiento iOS por separado: Los objetivos binarios de SPM son específicos del flavor - los pins de QA y App Store no deben cruzar cables.
Documenta una versión de contrato de bridge: BRIDGE_CONTRACT_VERSION en tipos compartidos - breaking SharedStateKeys o valores de type de mensaje requieren lanzamientos coordinados nativos + RN.
Keychain nativo posee tokens de refresco: RN obtiene tokens de acceso de corta duración mediante useSharedState - el refresco se mantiene nativo a menos que el auth strangler explícitamente migró.
Monta un listener SessionBridge raíz: Mensajes SESSION_UPDATED / LOGOUT en _layout.tsx - los listeners por pantalla pierden eventos en navegación rápida.
Nunca pases tokens de refresco en initialProps: Los props de bootstrap se registran e introspectados - usa estado compartido configurado por native después de lectura segura.
Usa Brownfield.popToNative() al completar flujo: Los finales de checkout y wizard deben devolver control al chrome nativo - no dejes stacks de RN huérfanos bajo pestañas nativas.
Habilita setNativeBackEnabled cuando native posee back: El back de hardware debe salir del módulo RN cuando la pila está vacía - previene usuarios atrapados en Android.
Elige cortes strangler post-autenticación y fuera del arranque en frío: El primer corte no debe bloquear el lanzamiento de la aplicación - la inicialización de RN de la pestaña inicio es una trampa de rendimiento y propiedad de navegación.
Graba el orden de cortes en ADRs: Incremental Adoption ADR las decisiones clasificadas previenen migraciones de "página de configuración aleatoria" sin cohesión de viaje.
Ramas de lanzamiento separadas: RN artifact pipeline, host store pipeline, OTA opcional - versionlas independientemente por Brownfield CI/CD.
OTA solo dentro de runtimeVersion: eas update en el proyecto RN no debe adelantarse al Hermes runtime embebido en el artefacto fijado del host.
Prueba offline artefactos de lanzamiento: Modo avión en host Release build antes de actualizar Maven/SPM - las rutas Metro de depuración ocultan bundles embebidos faltantes.
Usa @expo/ui RNHostView para chrome nativo dentro de pantallas RN: Distinto de presentación brownfield completa - barras de herramientas nativas alrededor de cuerpos RN sin view managers personalizados.
Mantén rutas RN delgadas; características gordas: Lo mismo que greenfield - app/ re-exporta pantallas de características por Mobile Architecture Basics.
Prefiere plugins de config sobre plists editados manualmente del host: Plugin expo-brownfield regenera objetivos en prebuild --clean - las ediciones manuales de Gradle se pierden.
Trata brownfield como alfa-capaz, no alfa-descuidado: Expo documenta el soporte brownfield como alfa - presupuesta depuración de construcción nativa, lee notas de lanzamiento de SDK, y archiva problemas upstream con artefactos de reproducción.
No - usa artefactos brownfield de depuración con Metro o construcciones de host internas. Expo Go no puede cargar tu shell de host.
Legal, marketing, y contenido raramente actualizado de solo lectura - no flujos de productos principales con requisitos offline o de navegación nativa.
Uno a menos que los límites legales o de equipo obliguen a dos - cada uno agrega CI de artefacto, contratos de bridge, y complejidad de enlazador iOS.
Expo Router posee navegación dentro del módulo embebido solo hasta que ADR declara raíz nativa jubilada - ver ADR de navegación en architecture-design.
El escuadrón RN publica nuevo artefacto; RP de integración del escuadrón nativo actualiza dependencia - OTA solo es insuficiente para nuevos módulos nativos.
expo-brownfieldVersiones de stack: Esta página fue escrita para React 19.2.3, React Native 0.86.0, y Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última actualización: 16 jul 2026