Guía de ingeniería de Business App
Usa esta guía para desarrollar y verificar la app React Native Business App. Para confirmar qué versión está instalada por los usuarios, consulta el sistema de publicación de tu organización y la configuración de API y proveedores asociada con esa compilación.
Arquitectura
La aplicación separa la lógica compartida sin interfaz, la presentación propiedad de la app y la conexión de pantallas nativas:
index.js → App.tsx → src/BusinessApp.tsx → src/AppContainer.tsx
└→ src/navigators/RootNavigator.tsx
src/@/components shared headless controllers, hooks, and API client
src/ui Business App presentation and app-owned contexts
src/pages thin screen wrappers
src/navigators authentication, tabs, stacks, push, and connectivity wiring
ios and android native projects and platform integrations
src/@/components es un submódulo Git. El alias React Native @components resuelve a su punto de
entrada nativo. Coordina los cambios de lógica compartida en el repositorio Components; no edites el
submódulo como si fuera código normal de la app.
Las pantallas de Business App usan React Navigation y styled-components. Mantén el trabajo visual
reutilizable en src/ui, el cableado específico de páginas en src/pages, el comportamiento nativo y
de navegación en src/navigators y la lógica compartida de negocio y API en Ordering.co Components.
Mapa del repositorio
| Ruta | Responsabilidad |
|---|---|
App.tsx, src/BusinessApp.tsx, src/AppContainer.tsx | Entrada de la app y composición de proveedores |
src/pages | Conexión de pantallas para operadores |
src/navigators | Controles de autenticación, pestañas, pilas, transferencia de push y conectividad |
src/ui | Componentes de interfaz, diseños, proveedores y presentación de acciones sin conexión, propiedad de la app |
src/context | Estado de permisos propiedad de la app |
src/@/components | Submódulo Components compartido y fijado |
src/config.json | Ajustes de ejecución versionados que consume la app |
src/theme.json | Entradas del tema de la app y referencias a recursos |
i18n | Herramientas para generar, validar y sincronizar catálogos de traducción |
ios, android | Workspaces nativos, proyectos, manifests, entitlements y configuración Gradle |
jest, src/**/__tests__ | Harness de pruebas de la app y suites |
patches | Parches de dependencias nativas aplicados durante la instalación |
Mantén alineados los alias @, @ui y @components en babel.config.js y tsconfig.json.
Requisitos previos y configuración
- Instala los requisitos de React Native del host para la plataforma que vayas a ejecutar: Xcode y CocoaPods para iOS, o Android Studio y un JDK/SDK de Android compatible.
- Usa Yarn.
NODE_VERSION.txtdel repositorio selecciona Node 22, mientras quepackage.jsonacepta Node 20 o posterior. - Clona con submódulos o inicialízalos antes de instalar dependencias.
git clone --recursive <authorized-repository-url>
cd <cloned-repository-directory>
yarn install --frozen-lockfile
Para un clon existente:
git submodule update --init --recursive
yarn install --frozen-lockfile
Para iOS, instala las dependencias Ruby y Pods versionadas la primera vez y después de cambios en dependencias nativas:
bundle install
cd ios
bundle exec pod install
cd ..
Abre ios/businessApp.xcworkspace cuando trabajes en Xcode. El scheme compartido es businessApp.
Usa el wrapper Gradle versionado para Android en lugar de una versión instalada por separado.
Configuración segura
src/config.json y src/theme.json son entradas versionadas de la aplicación, no un lugar para
credenciales. Mantén las claves secretas, material de firma, hosts privados, registros de clientes,
tokens, datos de pedidos o pagos y credenciales de proveedores fuera del código fuente, capturas,
registros y tickets.
Antes de iniciar la app, pide al responsable del entorno que confirme que los ajustes empaquetados, la revisión asociada de Components, el entorno de API previsto, el entorno de socket y la configuración nativa de proveedores corresponden entre sí. No copies valores de otro proyecto ni sustituyas un valor versionado por un endpoint supuesto.
El inicio normal puede inicializar API, socket, notificaciones, permisos y otros comportamientos de proveedores nativos. Usa un entorno no productivo aprobado y cuentas sintéticas con el mínimo propósito. Trata el registro de notificaciones, mensajes, cambios de pedidos, archivos, impresión y acceso a ubicación como efectos que requieren un plan de pruebas y limpieza explícito.
El trabajo de traducción debe empezar por la generación y verificación local. yarn i18n:sync es la
prueba en seco documentada; yarn i18n:sync:live puede escribir mediante una integración API autorizada
y no debe usarse como comando exploratorio.
Ejecuta la app
Inicia Metro en una terminal:
yarn start
Ejecuta una plataforma desde otra terminal:
yarn ios
yarn android
Si Metro conserva estado obsoleto de módulos, usa yarn start:reset. Para cambios nativos, recompila
el destino nativo en vez de depender únicamente de Fast Refresh.
Prueba y verifica los cambios
Usa el comando de lint que no modifica archivos durante las comprobaciones locales. El script normal
yarn lint aplica correcciones.
npx tsc --noEmit
yarn lint:check
yarn test
yarn i18n:check-generated
yarn i18n:verify
Entre los comandos útiles y acotados están:
yarn test path/to/file.test.tsx
yarn test:coverage
yarn test:coverage:summary
El flujo de CI de la app instala el lockfile congelado de Yarn y ejecuta lint, TypeScript, Jest, comprobaciones de traducción y cobertura. Jest cubre ubicaciones de pruebas propiedad de la app y excluye directorios nativos y el submódulo Components; valida también los cambios en Components en su propio repositorio. Ejecuta los cambios de interfaz y nativos en el simulador o dispositivo afectado y verifica los estados compatibles, errores, cancelaciones y rutas de limpieza.
Compilación y entrega para publicación
El repositorio documenta compilaciones nativas de desarrollo mediante React Native CLI, el workspace de Xcode y el wrapper Gradle. Los flujos inspeccionados son controles de calidad, no prueba de que se haya firmado, cargado, revisado o publicado una compilación para las tiendas.
Antes de entregar una candidata al responsable de publicación:
- Registra el commit de la app, el commit exacto del submódulo Components, el estado de los archivos de bloqueo y el entorno previsto, sin incluir valores secretos.
- Parte de un worktree limpio e instala las dependencias a partir de los archivos de bloqueo versionados.
- Ejecuta comprobación de tipos, lint sin modificaciones, Jest, validación de traducciones y las pruebas nativas específicas del cambio.
- Compila los destinos afectados de iOS y Android mediante la configuración versionada de workspace o proyecto.
- Ejecuta solo escenarios sintéticos aprobados y registra por separado las observaciones de la app, API, proveedor y salida física.
- Solicita al responsable de publicación que aplique el proceso autorizado de firma, distribución, lanzamiento gradual y reversión.
Una compilación local o una ejecución correcta de CI solo confirma esa compilación o flujo. Verifica la publicación en tiendas y la firma mediante el sistema de versiones de tu organización.
Resolución de problemas
| Síntoma | Comprobación |
|---|---|
No se resuelve @components | Confirma que el submódulo esté inicializado y que el alias apunte al punto de entrada nativo. |
| Metro resuelve archivos obsoletos | Detén Metro, ejecuta yarn start:reset y recompila después de cambios nativos. |
| Faltan dependencias o símbolos de iOS | Ejecuta Bundler y bundle exec pod install desde ios; abre el workspace, no el proyecto. |
| La configuración de compilación de Android no coincide con el checkout | Usa android/gradlew y verifica el JDK/SDK instalado frente a los archivos React Native y Gradle versionados. |
| La interfaz y el controlador se comportan distinto | Confirma si el cambio corresponde a src/ui/src/pages, propiedad de la app, o al submódulo Components fijado. |
| Falta una función configurada | Verifica el par exacto app/Components, entorno, autorización y requisitos en tiempo de ejecución; un indicador visible no garantiza derechos. |
| Hay ambigüedad con push, socket, impresión, archivos, mapas o apps externas | Detén los reintentos y revisa el contrato de integración correspondiente. |
| CI y los resultados locales difieren | Compara Node, instalación desde el lockfile, commit del submódulo, traducciones generadas y variante exacta del comando. |
Seguridad y escalamiento
Detente y escala el caso si se desconoce el entorno previsto, la referencia fijada de Components, la identidad de firma, la aplicación del proveedor, el propósito del permiso, el fixture sintético o el observador de limpieza. Informa solo el contexto mínimo redactado: plataforma, commit de la app, commit de Components, comando, estado visible no sensible y si algún efecto podría seguir pendiente.
Nunca pegues credenciales, valores de configuración sin procesar, tokens de acceso, datos de clientes o pedidos, coordenadas precisas, datos de pago, cargas de notificaciones, identificadores de dispositivo ni material de firma en un ticket. Una solicitud del cliente, una promesa resuelta, un aviso toast, un identificador de proveedor o un diálogo del sistema abierto no demuestra la aceptación del servidor ni la finalización externa.