Data Synchronization

Relevant source files

The following files were used as context for generating this wiki page:

• src/core/services/api/sync.api.js
• TASK_4_SUMMARY.md
• TASK_4_DISCUSSION.md
• src/core/utils/constants.js
• CRITICAL_BUGS_FIXED.md
• SECURITY_AND_CLEANUP_FIXES.md

The Data Synchronization system in eefashiondesign is a planned feature designed to save, load, and manage user design data between the local application and a cloud backend. It is architected as a "backdoor" or placeholder integration, allowing for future implementation without significant refactoring. The core of this system is the Cloud Sync API service, which is intended to interact with a Supabase backend for persisting design data.

Currently, the entire cloud synchronization functionality is disabled by default via a feature flag. The existing implementation consists of placeholder services and documented architectural plans for enabling cloud sync, offline support, and real-time collaboration. Local data persistence is handled by separate services like autoSaveService.js.

Sources: TASK_4_DISCUSSION.md, TASK_4_SUMMARY.md, src/core/services/api/sync.api.js

System Architecture

The proposed architecture separates concerns into distinct layers for services, state management, and configuration. The data synchronization feature is a key part of the service layer, designed to be modular and swappable between mock and real implementations.

Sources: TASK_4_DISCUSSION.md

Service Layer Structure

The following diagram illustrates the proposed structure for the services, including the sync.api.js file.

This diagram shows the planned service layer, highlighting where sync.api.js fits within the API services.

Sources: TASK_4_DISCUSSION.md

Feature Flag Control

The entire cloud sync functionality is controlled by a feature flag within the features.config.js file. This allows developers to enable or disable the feature globally. The CLOUD_SYNC configuration object also includes settings for auto-sync behavior.

// From the proposed features.config.js structure
export const FEATURES = {
  // ... other features
  CLOUD_SYNC: {
    ENABLED: false,           // Backdoor - enable when ready
    AUTO_SYNC: true,
    SYNC_INTERVAL: 30000,
  },
  // ... other features
};

Sources: TASK_4_DISCUSSION.md, src/core/services/api/sync.api.js:12-15

Local Storage Keys

The application defines several keys for AsyncStorage to manage local data. The LAST_SYNC key is specifically intended for tracking the timestamp of the last successful synchronization with the cloud. The DESIGNS key is used for storing design data locally.

Key	Description
@designs	Stores user design data on the local device.
@last_sync	Stores the timestamp of the last successful cloud synchronization.

Sources: src/core/utils/constants.js:240-258, SECURITY_AND_CLEANUP_FIXES.md

Cloud Sync API Service

The sync.api.js file serves as the placeholder for the cloud synchronization service. It defines the function signatures for all CRUD (Create, Read, Update, Delete) operations related to design data in the cloud. Each function currently checks the CLOUD_SYNC feature flag before proceeding and returns a "Not implemented yet" error if the feature is disabled.

Sources: src/core/services/api/sync.api.js, TASK_4_SUMMARY.md

Core Functions

The service exposes four primary functions for managing designs in the cloud.

Function	Parameters	Description	Current Status
syncDesignToCloud	designId, designData	Upserts a design to the cloud database.	Not Implemented
loadDesignFromCloud	designId	Retrieves a single design from the cloud.	Not Implemented
getAllDesignsFromCloud	-	Fetches a list of all user designs from the cloud.	Not Implemented
deleteDesignFromCloud	designId	Deletes a specific design from the cloud.	Not Implemented

Sources: src/core/services/api/sync.api.js:17-111

Intended Data Flow

The following sequence diagram shows the intended data flow when a sync operation is triggered. It illustrates the feature flag check and the subsequent interaction with the Supabase client.

This diagram visualizes how every function in sync.api.js first validates the feature flag before attempting a database operation.

Sources: src/core/services/api/sync.api.js:12-36

Related Systems: Local Persistence

While cloud sync is not yet implemented, the application has systems for local data persistence, which are precursors to synchronization.

• AutoSaveService: This service, mentioned in CRITICAL_BUGS_FIXED.md, periodically saves design changes to local storage. It has start(), stop(), and manual save() methods. This ensures work is not lost locally.
• ExportService: This service handles exporting designs to various file formats (PNG, SVG, etc.) and saving them to the device's file system.

These services manage the local state of designs, which is the data that will eventually be synchronized to the cloud.

Sources: CRITICAL_BUGS_FIXED.md, src/services/exportService.js

Activation and Implementation

The data synchronization feature is designed for straightforward activation. The following steps are required to enable and implement it:

1. Enable Feature Flag: In features.config.js (or the environment equivalent), set FEATURES.CLOUD_SYNC.ENABLED to true.
2. Implement API Functions: Uncomment and complete the Supabase logic within the placeholder functions in src/core/services/api/sync.api.js. The file already contains commented-out example implementations.
3. Database Setup: Create a designs table in the Supabase project, as referenced in the example code.
4. Integrate with UI: Connect UI elements, such as the "Save & Sync" button in the BottomBar component, to call the functions in sync.api.js.

Sources: TASK_4_SUMMARY.md, src/core/services/api/sync.api.js