ericjoel25/gestorprestamos

1. What this repository is

- Cobrapp is a React Native mobile app for loan management.

- The architecture is offline-first: the core product runs locally on the device, with optional cloud backup/synchronization.

2. Top-level runtime shape

- The app is a single mobile client built with JavaScript/TypeScript React Native.

- Shared UI and logic live in src/, while android/ and ios/ contain the native shells, app configuration, and platform bootstrap code.

3. Application entry and bootstrapping

- index.js and App.tsx are the main JavaScript entry points.

- The app is likely initialized through React context/providers and then handed off to the navigation stack.

- Tests are set up with Jest and React Native Testing Library style structure (__tests__/App.test.tsx).

4. Navigation and screen composition

- src/navigation/ defines the main route structure:

- bottom tabs,

- drawer navigation,

- stack navigators for home, clients, and expenses.

- This suggests a shell-and-feature model: navigation is the app’s top-level composition layer, and feature modules are embedded as screens.

5. Feature-centric module structure

- The app is split by business capability under src/modules/, not by generic UI layers.

- Main domains include:

- home / dashboard

- client management

- loan registration and updates

- collections and payment history

- late payments

- expense control

- notes

- notifications

- settings

- support/tutorials

- premium / ads

- sync / backup

- This is the core architecture boundary for most business logic.

6. Local persistence layer

- src/db/ is the primary data subsystem and appears to be backed by a local relational database, likely SQLite.

- It is organized by domain tables:

- clients

- clients without loans

- payments

- expenses

- late fee

- notes

- notifications

- settings

- Each domain has create/insert/query/update/delete files, which indicates a table-centric repository layer rather than a remote API-driven backend.

7. Offline data flow

- User actions in modules write to the local DB through the corresponding table helpers.

- Screens then read from the same local DB to render current state, histories, summaries, and reports.

- The app therefore uses the device database as the system of record for day-to-day operation.

8. Shared state and cross-cutting hooks

- src/hooks/ contains shared state and computed loan logic.

- This layer likely bridges UI modules with the database and derived calculations, such as loan balance, payment schedule, or summary state.

- It acts as the main boundary for reusable business state that multiple screens need.

9. Common utilities and app-wide services

- src/utils/ contains reusable services for:

- formatting numbers, phone numbers, locale-aware text,

- encryption,

- responsive layout,

- colors, typography, animation,

- print/share helpers,

- toast and ad-related flows,

- async storage.

- These utilities are shared infrastructure rather than feature logic.

10. Documents, PDF, and export flows

- The collection and payment modules include HTML templates and PDF/share helpers.

- The app can generate contracts, receipts, and payment documents, then share or print them.

- This is a major user-facing output path: database data is transformed into formatted documents for external use.

11. Synchronization and backup

- src/modules/synchronizeData/ contains background fetch, backup upload/download, and database merge logic.

- There is a Google Drive storage submodule, so cloud sync is an optional external service integration, not the core app runtime.

- This subsystem likely handles reconciling local data with cloud backups when connectivity is available.

12. Native platform integration

- android/ and ios/ are standard React Native native projects, but the presence of backup, printing, camera, and notification-related modules suggests the app depends on native capabilities.

- Android includes a google-services.json, indicating Firebase/Google services integration may be present.

- The native shells mainly provide permissions, build configuration, assets, and platform runtime support.

13. UI composition and reusable components

- src/components/ holds reusable presentation primitives such as headers, buttons, modals, error boundaries, and alerts.

- These are shared across feature modules and provide consistent interaction patterns.

- Modal-heavy UI suggests the app is designed around task flows like registration, confirmation, review, and selection rather than page navigation alone.

14. Localization and user formatting

- src/locales/ supports at least English, Spanish, and Portuguese.

- src/utils/format/ centralizes locale-aware formatting and country-specific behavior.

- This matters architecturally because many business screens depend on localized labels, date/phone formatting, and currency-like display rules.

15. Non-functional concerns

- src/components/ErrorBoundary/ and toast/ads helpers show attention to app stability and monetization/support flows.

- The repository includes linting, formatting, Babel/Metro, and platform build configuration, but the main architectural story is still a self-contained offline mobile system with local data, document generation, and optional cloud backup.