robiulislam08/pos-frontend

1. This repo is primarily a React-based POS front end, organized as a feature-driven single-page application. The visible stack is Vite + React, with Tailwind for styling and a small set of UI primitives for toasts, tooltips, and shared form/table controls.

2. The application is split by business domain under src/features, which is the main architectural boundary. Major modules include auth, inventory, sales, purchase, expense, barcode, backups, settings, help, and several “masters” screens for customer/supplier/user/product administration.

3. Shared UI and layout concerns live outside the feature folders. src/components/layout contains the app shell pieces like AppLayout, Header, Navbar, and MobileNav, while src/components/common holds reusable building blocks such as DataTable, FormField, PageTitle, SummaryBar, and action button groups.

4. State and cross-cutting concerns are handled through React contexts. AuthContext governs session/login state, and LanguageContext drives internationalization. This makes authentication and locale selection app-wide concerns rather than feature-local ones.

5. Routing is centralized in src/routes/Routes.jsx, with navigation definitions separated into src/config/nav.config.js. That suggests a clear split between route composition, menu generation, and page implementation, which is useful for diagrams of user navigation flow.

6. The data access layer is explicitly separated from the UI. src/services/*.service.js contains domain-specific API clients for auth, products, sales, purchases, stock, suppliers, customers, expenses, credits, settings, barcodes, and user management. These services likely all wrap a shared HTTP client in src/services/api.js.

7. Above the services, domain hooks in src/hooks provide feature-friendly state management and side effects. Hooks like useProducts, useSales, useStock, useSuppliers, useUsers, and useExpenses act as the bridge between pages and the API layer, keeping component code focused on rendering and user interaction.

8. The main runtime data flow is: user action in a page → feature hook → service call → shared API client → backend API → hook state update → UI refresh. Error and success messaging are handled through toast utilities in src/lib/toast-helpers.js and the UI toast components.

9. Internationalization is a first-class subsystem. Translations live in src/i18n/en.json and src/i18n/ar.json, indicating bilingual support, likely with Arabic as a right-to-left use case that affects layout and text rendering.

10. The repo includes a backend-facing story, but the frontend is the core artifact. backend-api-implementation/, server.js, and the Windows start scripts suggest a companion Node-based local server or deployment wrapper, while vercel.json indicates the front end can also be deployed as a web app.

11. Operationally, the project includes build/test/tooling boundaries: Vite for bundling, Vitest for tests, ESLint/PostCSS/Tailwind for code and styling, and public/robots.txt plus index.html for web deployment. These are supporting layers around the main POS UI and API integration architecture.

12. For an architecture diagram, the most important nodes are: the app shell/layout, feature pages, shared contexts, domain hooks, service/API layer, and the external backend. The business flow centers on POS operations like sales, inventory movement, purchases, credits, and reporting, with auth and language as global controls.