abineshkumarr/synora

Purpose and Runtime

Synora is a desktop-first productivity workspace organized around boards, notes, calendar, habits, and dashboard views. It is a browser SPA built with React-style JSX and Vite entry infrastructure: src/main.jsx, src/App.jsx, and vite.config.js. Current persistence is local browser storage; no backend, authentication, cloud sync, or external API integration is represented in the repository.

Application Composition and Navigation

App is the top-level application assembly point, while the shared shell separates persistent navigation from feature workspaces. Layout components provide the sidebar, top bar, breadcrumbs, and content workspace: src/components/layout/Layout.jsx, src/components/layout/Sidebar.jsx, and src/components/layout/Workspace.jsx. Navigation destinations are centrally defined in src/constants/navigation.js, creating a boundary between global navigation structure and page implementations.

Global State and UI Interaction

Application-wide state is exposed through a React context/provider layer: src/context/AppContext.jsx, src/context/AppProvider.jsx, and src/hooks/useApp.js. Feature and layout consumers should use this abstraction rather than directly coupling to storage or top-level state. Reusable interaction hooks support workspace selection, modal behavior, debouncing, and local storage access, notably src/hooks/useWorkspace.js, src/hooks/useModal.js, and src/hooks/useLocalStorage.js.

Persistence, Validation, and Domain Services

Storage is a distinct client-side data boundary. src/storage/storageService.js owns persistence access, src/storage/validationService.js validates stored data, and src/storage/migrationService.js supports schema evolution for existing local data. Domain-facing operations are separated into src/services/boardService.js and src/services/noteService.js; pages and components should route board/note mutations through these services instead of directly managing persisted records.

Feature Workspaces

Boards are the core established product area, represented by the board landing view and a board-specific workspace: src/pages/Boards/Boards.jsx and src/pages/Boards/BoardWorkspace.jsx. Other top-level productivity domains are isolated as pages—src/pages/Notes/Notes.jsx, src/pages/Calendar/Calendar.jsx, and src/pages/Habits/Habits.jsx—allowing their future implementation to share the application shell and state/storage boundaries without tightly coupling their UI.

Dashboard Aggregation

The dashboard is an aggregation surface rather than an independent data domain. src/pages/Dashboard/Dashboard.jsx composes a grid and header from src/pages/Dashboard/components/DashboardGrid/DashboardGrid.jsx and src/pages/Dashboard/components/DashboardHeader/DashboardHeader.jsx, then renders focused widgets such as tasks, recent boards/notes, calendar preview, habits, and deadlines. These widgets should consume existing domain data through services/context, not establish parallel persistence.

Styling and Cross-Cutting Utilities

Global visual foundations and shell styling are kept separate from feature-local styles in src/styles/globals.css, src/styles/layout.css, and src/styles/variables.css. Shared non-UI logic for identifiers, dates, constants, and validation resides in src/utils/ids.js, src/utils/dates.js, and src/utils/validation.js. The principal control flow is: browser entry → app/provider → shared layout/navigation → selected workspace/page → domain service → validated/migrated local storage.