Architecture Overview
Relevant source files
The following files were used as context for generating this wiki page:The eefashionita application is a cross-platform 3D fashion design tool built with React Native and Expo. Its architecture is designed to be modular, scalable, and platform-aware, providing a full-featured 3D design experience on web and desktop while offering graceful fallbacks for mobile and tablet devices. The system is structured to support future backend integration for features like real-time collaboration, cloud storage, and user authentication through a series of "backdoor" integration points.
The architecture emphasizes a clean separation of concerns, with distinct layers for core business logic, feature modules, and shared components. A recent migration from React Native Paper to the Tamagui UI library has been initiated to improve performance, bundle size, and developer experience.
Sources: README.md:9-12, TASK_4_DISCUSSION.md:14-20, TAMAGUI_MIGRATION.md:1-4
Technology Stack
The project is built on a modern stack centered around React Native for cross-platform development.
| Category | Technology | Purpose |
|---|---|---|
| Core | React Native + Expo | Cross-platform application framework |
| Navigation | React Navigation | App-wide routing and screen transitions |
| UI | Tamagui | Performant, type-safe UI component library |
| State | Zustand | Lightweight state management |
| 3D Rendering | React Three Fiber, Three.js, @react-three/drei | 3D design interface (Web/Desktop only) |
| UI (Legacy) | React Native Paper | Previous UI library, being phased out |
Sources: README.md:42-50, TAMAGUI_MIGRATION.md:11-18, BUGS_FIXED_AND_IMPROVEMENTS.md:83-88
Project Structure
The project follows a feature-based directory structure, which modularizes the codebase and promotes a clean separation of concerns.
Sources: README.md:16-39, TASK_4_DISCUSSION.md:104-121
This diagram illustrates the high-level organization of the src directory.
Sources: README.md:17-39
Key Directories
src/core: Contains the application's core business logic, services, state management, and utilities. This layer is designed to be feature-agnostic.state/: Houses Zustand stores for global state management (e.g.,authStore,designStore).services/: Manages external interactions, such as API calls (to Supabase), local storage, and sync services.utils/: Provides shared utility functions, constants, and platform-detection logic.
src/features: Each subdirectory represents a distinct feature of the application (e.g.,home,design3D,auth). This modular approach allows for independent development and testing.src/shared: Contains reusable components, custom hooks, and assets that are used across multiple features.src/navigation: Defines the navigation structure of the app using React Navigation.App.js: The main entry point of the application, responsible for setting up providers (e.g.,TamaguiProvider) and the root navigator.
Sources: README.md:17-39, TASK_4_DISCUSSION.md:104-138, TAMAGUI_MIGRATION.md:104-108
Platform-Specific Architecture
The application intelligently adapts its feature set based on the underlying platform to optimize performance and user experience. Full 3D editing capabilities are reserved for web and desktop, which have more processing power and WebGL support.
| Platform | 3D Editing | 3D Viewing | AR Try-On |
|---|---|---|---|
| Web | ✅ Full Features | ✅ Full Features | ❌ N/A |
| Desktop | ✅ Full Features | ✅ Full Features | ❌ N/A |
| Tablet | ⚠️ Limited | ✅ Basic Viewing | ✅ Yes |
| Mobile | ❌ Fallback UI | ✅ View-Only | ✅ Yes |
Sources: README.md:52-57, README.md:92-108
Service Layer and Backend Integration
The architecture is designed with "backdoors" or placeholder integration points to facilitate future backend integration without requiring major refactoring. The proposed and implemented service layer is built to be modular, allowing for mock services in development and real API services in production.
Sources: TASK_4_DISCUSSION.md:22-34, TASK_4_SUMMARY.md:7-17
The diagram below shows the structure of the service layer, designed to handle API communication, storage, and other external concerns.
Key Components:
- API Client (
supabase.client.js): A centralized client for communicating with the Supabase backend. It handles session management and token refreshing. - Authentication (
auth.api.js,authStore.js): A dedicated service and Zustand store for managing user authentication, including sign-up, sign-in, sign-out, and session persistence. - Cloud Sync (
sync.api.js): A placeholder service ready to be implemented for saving and loading design data from a cloud database. - Offline Manager (
offlineManager.js): A placeholder service designed to queue operations when the device is offline and process them upon reconnection. - Storage Services: Wrappers for both local (
AsyncStorage) and cloud storage (e.g., Supabase Storage) are planned.
Sources: TASK_4_SUMMARY.md:8-67, TASK_4_DISCUSSION.md:104-121
Configuration Management
Application configuration is centralized to manage environment-specific settings, feature flags, and global constants.
| File Path | Purpose |
|---|---|
.env | Stores environment-specific variables like Supabase API keys. This file is not committed to Git. |
src/core/config/env.config.js | Reads and validates environment variables from .env for use within the application. |
src/core/config/features.config.js | Manages feature flags to enable or disable functionality dynamically (e.g., CLOUD_SYNC, PREMIUM). |
src/core/utils/constants.js | A consolidated file for application-wide constants like API endpoints, theme colors, and storage keys. |
src/config/constants.js | A deprecated constants file, being merged into src/core/utils/constants.js. |
Sources: TASK_4_SUMMARY.md:69-87, SECURITY_AND_CLEANUP_FIXES.md:11-31, src/core/utils/constants.js, src/config/constants.js:101-103
Feature Flags
Feature flags allow for the gradual rollout of features without new deployments.
// src/core/config/features.config.js (Example from discussion)
export const FEATURES = {
AUTH: {
ENABLED: true,
SOCIAL_LOGIN: false,
},
CLOUD_SYNC: {
ENABLED: false,
AUTO_SYNC: true,
},
COLLABORATION: {
ENABLED: false,
},
PREMIUM: {
ENABLED: false,
},
};
Sources: TASK_4_DISCUSSION.md:143-167, TASK_4_SUMMARY.md:69-87
Storage Keys
A unified STORAGE_KEYS object ensures consistent keys are used for AsyncStorage across the application.
// src/core/utils/constants.js
export const STORAGE_KEYS = {
// Authentication
AUTH_TOKEN: '@auth_token',
REFRESH_TOKEN: '@refresh_token',
USER_DATA: '@user_data',
// App Data
THEME: '@theme',
DESIGNS: '@designs',
// ... and more
};
Sources: src/core/utils/constants.js:246-265, SECURITY_AND_CLEANUP_FIXES.md:46-70
UI Layer (Tamagui Migration)
The project is undergoing a significant migration from react-native-paper to Tamagui. This strategic shift aims to address several key areas:
- Performance: Tamagui offers significantly faster rendering and better animation performance by using the native driver by default.
- Bundle Size: Advanced tree-shaking in Tamagui leads to a smaller application bundle size.
- Developer Experience: The introduction of a type-safe, token-based design system with CSS shorthands and component variants streamlines UI development and ensures consistency.
- Maintainability: Centralizing the design system in
tamagui.config.tsmakes the UI easier to maintain and theme compared to scatteredStyleSheet.createinstances.
Sources: TAMAGUI_MIGRATION.md:32-46, BUGS_FIXED_AND_IMPROVEMENTS.md:83-112
Summary
The eefashionita architecture is a well-considered framework for a complex, cross-platform application. Its feature-based modularity, platform-aware feature delivery, and forward-thinking service layer provide a robust foundation for current functionality and future growth. The ongoing migration to Tamagui further modernizes the stack, promising improvements in performance, developer experience, and code quality. The clear separation between core logic, features, and UI components ensures the project remains scalable and maintainable.