Project Structure
Relevant source files
The following files were used as context for generating this wiki page: - [README.md](https://github.com/softvibeslab/elmecV2-Demo/blob/HEAD/README.md) - [VALIDACION-COMPLETA.md](https://github.com/softvibeslab/elmecV2-Demo/blob/HEAD/VALIDACION-COMPLETA.md) - [REPORTE_CHAT_MODULE.md](https://github.com/softvibeslab/elmecV2-Demo/blob/HEAD/REPORTE_CHAT_MODULE.md) - [FIXES-APLICADOS.md](https://github.com/softvibeslab/elmecV2-Demo/blob/HEAD/FIXES-APLICADOS.md) - [utils/logger.ts](https://github.com/softvibeslab/elmecV2-Demo/blob/HEAD/utils/logger.ts) - [DEPLOY-NETLIFY.md](https://github.com/softvibeslab/elmecV2-Demo/blob/HEAD/DEPLOY-NETLIFY.md) - [REPORTE_PRUEBAS_REQUESTS_CRUD.md](https://github.com/softvibeslab/elmecV2-Demo/blob/HEAD/REPORTE_PRUEBAS_REQUESTS_CRUD.md) - [supabase/setup-instructions.md](https://github.com/softvibeslab/elmecV2-Demo/blob/HEAD/supabase/setup-instructions.md)The ElmecV2 project is a multi-platform mobile application for request management, built using React Native, Expo, and Supabase. The project structure is designed to enforce a clear separation of concerns, separating UI components, application screens, state management, services, and backend configuration into distinct directories. This modular architecture facilitates maintainability, scalability, and collaborative development.
The core principles of the architecture include a centralized service layer for backend communication, a well-defined state management strategy using Zustand and TanStack Query, and a robust system for logging and error handling. The application is designed for deployment on iOS, Android, and Web, with specific configurations managed for each environment.
Sources: README.md:10-13, VALIDACION-COMPLETA.md:120-125
High-Level Directory Structure
The project's root directory is organized into folders, each with a specific responsibility. This structure separates frontend concerns, backend integration, utilities, and configuration.
Sources: README.md:100-115
The following diagram illustrates the main directories and their purpose.
| Directory | Description | Source |
|---|---|---|
components/ | Contains reusable React components, subdivided into ui/ for basic elements and forms/ for form-related components. | README.md:101 |
screens/ | Holds the application's screens, organized by feature or role (e.g., auth/, admin/, user/). | README.md:103 |
navigation/ | Manages navigation logic using React Navigation and Expo Router. | README.md:106 |
store/ | Contains global state management logic, primarily using Zustand. | README.md:107 |
services/ | Centralizes communication with external services, notably a SupabaseService for all backend interactions. | README.md:108, VALIDACION-COMPLETA.md:122 |
utils/ | A collection of helper functions and core utilities, including a custom logger.ts and errorHandler.ts. | README.md:109 |
types/ | Stores TypeScript type definitions, including auto-generated types from Supabase. | README.md:112 |
assets/ | Contains static assets like images, fonts, and icons. | README.md:113 |
supabase/ | Includes all Supabase-related configurations, such as database migrations and setup instructions. | README.md:114 |
Frontend Architecture
The frontend is built with React Native and Expo, emphasizing a component-based architecture and clear data flow patterns.
UI and Screens
components/: This directory houses all reusable components. A key example isFileUploadComponent.tsx, which encapsulates the logic for selecting files from the gallery, camera, or document picker, and handling uploads to Supabase.
Sources: RESUMEN_CONFIGURACION.md:13, README.md:101screens/: Each major view in the application corresponds to a file in this directory. They are organized by user roles and features, such asauth/login.tsxfor authentication or(tabs)/requests.tsxfor the requests module.
Sources: README.md:103-105, FIXES-APLICADOS.md:10
Navigation and Routing
The application uses a combination of Expo Router for file-based routing and React Navigation for managing the navigation stack. The entry point app/index.tsx determines the initial route based on the user's authentication state.
The following diagram shows the initial routing logic.
This logic ensures that unauthenticated users are always directed to the login page, while authenticated users are taken directly to the main application dashboard.
Sources: FIXES-APLICADOS.md:113-121
State Management
The project employs a dual strategy for state management:
- Zustand: Used for managing global UI state and client-side data.
Sources: README.md:46 - TanStack Query: Manages server state, including caching, refetching, and invalidation of data fetched from Supabase.
Sources: README.md:47 - React Context API: Used for feature-specific state that needs to be shared across a component tree. A prominent example is the
ChatContext, which manages real-time chat subscriptions, messages, and presence tracking for the chat module.
Sources: VALIDACION-COMPLETA.md:121, REPORTE_CHAT_MODULE.md:31-35
Backend and Database
The entire backend is powered by Supabase, a Backend-as-a-Service (BaaS) platform that provides a PostgreSQL database, authentication, real-time subscriptions, and file storage.
Sources: README.md:49-53
Database Schema
The core of the application revolves around a set of related tables in the PostgreSQL database. The main entities are users, requests, chat_rooms, and messages.
The following Entity-Relationship diagram illustrates the database schema.
This schema is derived from migration files and test reports that detail table columns and relationships.
Sources: supabase/setup-instructions.md:68-76, REPORTE_PRUEBAS_REQUESTS_CRUD.md:83-96, REPORTE_CHAT_MODULE.md:275-292
Real-time Functionality
The application leverages Supabase Realtime for features like the chat module. The ChatContext subscribes to database changes (INSERT, UPDATE) on the messages and chat_rooms tables, allowing for instant message delivery and UI updates. It also uses "Presence" for tracking user online status and "typing..." indicators.
Sources: FIXES-APLICADOS.md:90-108, REPORTE_CHAT_MODULE.md:110-146
Utilities and Core Logic
The utils/ directory contains shared logic, with logger.ts being a critical component for diagnostics and monitoring.
Logging System
The project includes a custom Logger class in utils/logger.ts for structured logging. It supports multiple log levels, conditional console output based on the environment, and a mechanism for remote logging.
The Logger class has the following structure and methods:
The logger is configured based on environment variables, with debug logs enabled in development and only warnings and above in production.
// file: utils/logger.ts:25-30
private static config: LoggerConfig = {
enableConsoleLogging: process.env.EXPO_PUBLIC_ENVIRONMENT !== 'production',
enableRemoteLogging: process.env.EXPO_PUBLIC_ENVIRONMENT === 'production',
logLevel: process.env.EXPO_PUBLIC_ENVIRONMENT === 'production' ? LogLevel.WARN : LogLevel.DEBUG,
maxLocalLogs: 1000
};
Sources: utils/logger.ts
DevOps and Deployment
The project is configured for continuous deployment to Netlify for the web version.
Configuration Files
.env: Stores environment-specific variables like Supabase URL and keys.
Sources: README.md:73-83netlify.toml: Defines build settings for Netlify, such as the build command, publish directory, and the required Node.js version.
Sources: DEPLOY-NETLIFY.md:27-31, STATUS-DEPLOY.md:21-22app.json: Expo configuration file, used to define plugins, platform-specific settings, and the web app's origin URL for authentication redirects.
Sources: DEPLOY-NETLIFY.md:120-131
Deployment Flow
Deployment to Netlify is automated via GitHub. A push to the netifly branch triggers a new build and deployment.
This diagram shows the deployment workflow.
The build command npm ci && npm run build:production ensures a clean installation of dependencies and an optimized production build.
Sources: DEPLOY-NETLIFY.md:18-23, NETLIFY-DASHBOARD-SETUP.md:32-39
Key Scripts
The package.json file defines several scripts to automate common development and deployment tasks.
| Script | Description | Source |
|---|---|---|
npm start | Starts the Expo development server. | README.md:130 |
npm run web | Runs the web version of the app in development. | README.md:131 |
npm run build:production | Creates an optimized production build for the web in the dist/ directory. | README.md:133 |
npm run deploy | Deploys the production build to Netlify. | README.md:134 |
npm test | Executes the test suite. | README.md:139 |
npm run lint | Runs ESLint to check for code quality issues. | README.md:137 |
Conclusion
The ElmecV2 project is built on a modern, scalable architecture that leverages the strengths of React Native for cross-platform UI and Supabase for a comprehensive backend. The well-defined directory structure promotes separation of concerns and maintainability. Key architectural patterns like a centralized service layer, robust logging, and a clear state management strategy contribute to a high-quality, production-ready codebase. The automated deployment pipeline to Netlify ensures a streamlined and reliable release process for the web application.