abhijith-web-dev/folient-io

1. Repository shape

- Folient Builder is a single-page React 19 + TypeScript application built with Vite.

- The repo is primarily a frontend orchestration layer: it owns the editor UI, local state, cloud API integrations, and client-side routing.

- Static hosting support is baked in via netlify.toml and public/_redirects, so the app is meant to run as a client-rendered SPA.

2. Top-level app composition

- src/main.tsx boots the app; src/App.tsx is the shell that wires routing and global UI.

- The main route set lives under src/pages/: Home, Editor, Dashboard, Community, Templates, Docs, Auth, Terms, and NotFound.

- This suggests a product split between a marketing/site surface and the authenticated builder workspace.

3. Core editor workspace

- The editor experience is concentrated in src/components/ and src/components/editor/.

- Key building blocks include the VisualCanvas, CodePanel, PropertyPanel, TopNavigationBar, LeftTelemetryPanel, and AI/chat surfaces.

- The editor subcomponents are organized by design domains: layout sections, typography, flexbox, box model, background, animation, layers, assets, and telemetry.

- Architecturally, this is a multi-panel workspace where visual editing, code inspection, and property tuning are separate but synchronized views.

4. State management boundary

- Global state is managed with Zustand stores in src/store/: useAuthStore, useEditorStore, and useProjectStore.

- These stores are the main in-memory contract between the UI panels, the editor canvas, project persistence, and auth-aware features.

- The likely flow is: user action in canvas/panel → store update → other panels re-render from the same store state.

5. Local persistence and offline project storage

- src/db/dexie.ts shows the app uses Dexie.js over IndexedDB for local persistence.

- This is the offline/cache boundary for project files and editor state, separate from cloud services.

- The repo therefore has a clear split between ephemeral UI state in Zustand and durable browser-local project storage in IndexedDB.

6. AI subsystem

- AI orchestration is centralized in src/modules/ai/AIOrchestrator.ts.

- Provider-specific adapters live alongside it: GeminiAdapter, GroqAdapter, and OpenRouterAdapter.

- src/lib/aiInferenceRouter.ts indicates a routing layer that chooses or forwards inference requests to the right model backend.

- The UI surfaces for this are the AI chatbox and telemetry/status panels, so the AI system is treated as an external intelligence service layer, not embedded logic.

7. Hosting and deployment subsystem

- src/modules/hosting/ contains PublishPanel, CloudCallback, useCloudAuth, and another useDeploymentEngine.

- src/services/DeployService.ts plus the hosting module imply a deployment pipeline that can publish generated work to external providers such as Vercel and Netlify.

- src/hooks/useDeploymentEngine.ts mirrors that concern at the app level, suggesting a shared deployment state machine used by the publish UI and status display.

- CloudCallback indicates the app expects an OAuth or redirect-based callback flow from cloud providers.

8. Community/auth/data backend

- Firebase is present via src/firebase/config.ts and firestore.rules, and the README explicitly ties it to community subscriptions, social feed, comments, and profile tracking.

- The Community, Dashboard, and Auth pages are the user-facing boundary for this backend.

- This is separate from the editor: the app appears to use Firebase for social and identity-related features, while the builder itself remains mostly client-side.

9. Supabase and secure asset storage

- Supabase integration is represented by src/services/SupabaseClient.ts, credentialSync.ts, and portfolioSync.ts.

- Based on the README, Supabase is the asset vault / media library layer for uploads and shared assets.

- CryptoService.ts and src/utils/crypto.ts suggest sensitive data is encrypted or transformed before sync, making this a distinct secure-data boundary rather than plain object storage.

10. Template and content model

- src/templates/templates.ts provides the template catalog used by the templates page and likely the editor startup flow.

- This is the product’s reusable content layer: it seeds the builder with prebuilt layouts, presets, and starter configurations.

- Templates sit between the visual editor and the project store, acting as initial state or importable project definitions.

11. Cross-cutting UX and app services

- src/hooks/useSEO.ts suggests the app also manages per-page metadata for public-facing pages.

- src/components/CookieConsentBanner.tsx and src/components/ErrorBoundary.tsx are app-wide concerns rather than feature logic.

- These sit in the shell layer and support the public marketing/community experience, not the editing core.

12. Important architectural boundaries

- The app is mostly a browser client with direct integrations to external services; there is no custom server in this repo.

- The primary boundaries are:

- UI/editor shell

- local state and IndexedDB persistence

- AI model routing

- cloud deploy/auth callbacks

- Firebase community data

- Supabase asset storage

- For an architecture diagram, the central node should be the React editor shell, with arrows out to the AI providers, Firebase, Supabase, IndexedDB, and deployment providers.