nayan97/sass-invoice-in-react

1. This is a client-side React single-page application built with TypeScript and Vite. The repo is primarily a front-end shell; its main runtime responsibilities are routing, layout composition, form/modal interactions, and API-backed state management.

2. The app is split into two major surfaces: a public/user area and an admin area. Public pages currently include authentication screens (Login, Register) and a user-facing PricingPage. The admin surface contains dashboard and CRUD-heavy management screens for currencies, invoices, companies, subscriptions, coupons, plans, and transactions.

3. Routing and access control are enforced at the component level. ProtectedRoute acts as the main authentication gate, while AdminLayout provides the structural wrapper for admin pages. This suggests route groups like public vs authenticated vs admin-only, rather than a single flat page tree.

4. The admin UI is organized around a shared chrome: Header and Sidebar under src/components/admin, with the layout likely composing these around page content. This is the primary visual boundary for the admin subsystem and the place where global navigation and page framing live.

5. The application’s data layer is centralized under src/store and appears to use Redux Toolkit Query-style API slices. There is a baseApi plus domain-specific slices for auth, home, company, company addresses, company users, currencies, invoices, main invoices, subscriptions, subscription plans, coupons, and transactions. The pattern indicates pages fetch and mutate server state through these slices rather than direct fetch calls scattered across components.

7. The domain model is highly CRUD-oriented. Each business area has its own page set and in many cases modal dialogs for create/edit/delete flows, such as CurrencyModal, PlanModal, CouponModal, SubscriptionEditModal, InvoiceDeleteModal, and company user/address modals. That means the UI pattern is page list + modal form + API mutation.

8. Invoices are a major subsystem and are split into multiple entry points: main invoices, company invoices, invoice details, add invoice, and wrapper components for specific routes. This suggests invoice handling has route-level segmentation and potentially multiple views over the same backend model depending on context.

9. Company management is another distinct admin domain. It includes company listing, addresses, and users, which implies a nested ownership model where companies have related sub-resources and separate management screens.

10. Subscriptions are modeled as a family of screens rather than a single page: subscriptions, subscription plans, coupons, invoices, and transactions. This indicates a billing/commerce subsystem with distinct but related entities, likely sharing API data and admin workflows.

11. Shared UI primitives live in src/components/ui and are likely reusable design-system wrappers. The presence of button, carousel, and sheet components, plus components.json, strongly suggests a generated component library pattern similar to shadcn/ui, used to keep modal, drawer, and button styling consistent.

12. The top-level app bootstrap is standard Vite/React: main.tsx mounts the app, App.tsx likely wires routing and layouts, and index.css/App.css provide global and app-specific styling. src/lib/utils.ts likely holds small shared helpers used by UI components.

14. In short, the repository is a modular admin console with a small public-facing entry area, built around route protection, shared admin chrome, and a centralized API-state layer for several business domains.