anoop-kumar-31/queueflow

1. Repository scope

- This repo is the QueueFlow frontend only: a React 18 + Vite single-page app that talks to an external REST API and a Socket.io backend.

- There is no server code here; the architectural boundary is the browser UI, Redux state, and service adapters.

2. App bootstrap

- src/main.jsx is the entry point that mounts the React app and connects it to the Redux store.

- src/App.jsx is the top-level route/shell coordinator, while src/store.js wires together the feature slices.

3. Routing and screen boundaries

- src/pages/ contains the primary route-level screens: Login, Register, Dashboard, ProjectBoard, TasksBoard, AnalyticsDashboard, and Profile.

- This suggests a role-driven SPA where authenticated users move between workspace, task, analytics, and profile views rather than separate server-rendered pages.

4. Global application shell

- src/components/AppLayout.jsx plus the src/components/layout/ folder form the persistent UI shell.

- The shared header/sidebar area includes AppSidebar, SearchBar, NotificationBell, and ThemeToggle, which implies navigation, global search, real-time alerts, and theme state are always available across authenticated screens.

5. State management layer

- Redux Toolkit is the central state boundary in src/features/.

- The slices are split by domain: authSlice.js for session/user state, projectSlice.js for workspace/project data, and tasksSlice.js for task/board state.

- This is the main client-side source of truth for both REST-fetched and socket-driven updates.

6. Backend integration layer

- src/services/api.js is the REST adapter, likely handling CRUD, auth, project membership, tasks, and analytics fetches.

- src/services/socket.js is the real-time adapter, responsible for connecting to Socket.io and broadcasting/receiving collaborative events.

- The architecture separates request/response traffic from push-based updates instead of mixing them in components.

7. Real-time collaboration flow

- User actions such as task moves, project membership changes, invite generation, and notes feed into the API and/or socket service.

- Socket events then update Redux slices, which immediately refresh the Kanban board, notification feed, and activity timeline without a page reload.

- This push-based loop is the core interaction model of the app.

8. Project and task workflows

- Project-level actions are surfaced through modal components such as CreateProjectModal, JoinProjectModal, GenerateInviteModal, and ManageAccessModal.

- Task-level actions are handled by CreateTaskModal and TaskDetailsModal, indicating most mutations happen in focused overlays rather than full-page forms.

- TasksBoard and ProjectBoard are the main working surfaces for these flows.

9. Collaboration and visibility features

- ActivityTimeline.jsx represents the event stream for workspace history.

- NotificationBell.jsx provides unread, real-time awareness of teammate actions.

- These are separate from the main board, which helps distinguish operational work from audit/visibility surfaces.

10. Analytics and reporting

- AnalyticsDashboard.jsx is a dedicated reporting surface for workflow intelligence.

- It likely consumes task/project state from the store and/or API responses to render bottlenecks, completion trends, and workload views.

- This is a read-heavy subsystem distinct from the task mutation path.

11. Authentication boundary

- Login.jsx and Register.jsx isolate unauthenticated access from the rest of the workspace.

- The rest of the app appears to assume an authenticated session and role-aware UI, so auth is a gateway dependency for all project/task features.

12. Shared UI and loading state

- Loading.jsx is a standalone boot/loading experience, separate from normal navigation.

- src/App.css and src/index.css provide app-wide styling, while src/assets/ holds static UI assets.

- Visual presentation is likely utility-first with Tailwind, but the architectural point is that styling is centralized and shared across all screens.

13. External systems

- The frontend depends on a backend REST API and a Socket.io server, configured through the Vite environment variable noted in the README.

- The app is built and served as a static SPA via Vite, so all business logic shown here is client-side orchestration around those backend services.

14. High-level data flow

- User interaction starts in a page or modal, dispatches Redux actions, calls the REST API for persistence, and then receives socket broadcasts for cross-user synchronization.

- The store updates drive the visible UI: boards, timelines, analytics, notifications, and access management all read from the same shared client state.