hasibur14/dinedorm-client

1. Overall shape

- This is a single-page React frontend built with Vite and styled with Tailwind CSS.

- The repository is primarily the client for “Dine Dorm”; the README indicates it talks to a separate Node/MongoDB backend for meals, reviews, users, JWT auth, and Stripe payments.

2. App entry and shell

- The runtime starts from index.html → src/main.jsx.

- Global styling lives in src/index.css.

- The app shell is split into two main presentation boundaries:

- src/Layout/Main.jsx for the public-facing site

- src/Layout/DashboardLayout.jsx for authenticated dashboard screens

3. Routing and access control

- Route composition is centralized in src/Routes/Routes.jsx.

- Protected navigation is enforced with:

- src/Routes/PrivetRoute.jsx for authenticated routes

- src/Routes/AdminRoute.jsx for admin-only routes

- This creates the main boundary between public pages, user dashboard pages, and admin dashboard pages.

4. Authentication and identity

- Firebase is the client-side auth integration point via src/firebase/firebase.config.js.

- src/Provider/AuthProvider.jsx likely exposes auth state and session actions to the rest of the app.

- src/hooks/useAuth.jsx and src/components/SocialLogin/SocialLogin.jsx suggest multiple auth entry points, including social sign-in.

- The app uses JWT for secured backend requests, separate from Firebase’s auth session.

5. API/data access layer

- Server communication is abstracted behind custom hooks in src/hooks/.

- useAxiosPublic.jsx and useAxiosSecure.jsx are the key transport boundaries:

- public requests for unauthenticated data

- secure requests that attach JWT and handle protected endpoints

- Domain hooks such as useMeal.jsx, useReview.jsx, useUser.jsx, useUpcomingMeal.jsx, and useRequestMeal.jsx isolate page components from raw API details.

6. Public site pages

- The public experience is organized under src/pages/Home/ plus standalone pages like About, Contact, AllMeals, MealDetails, UpcomingMeal, and JoinUs.

- Home is composed of modular sections: banner, meal categories, membership, testimonials, and “why choose us”.

- public/whyChooseUs.json is a static content source used by the marketing/landing experience.

7. Meal discovery and content browsing

- The meal-centric flow is a major domain area:

- AllMeals/Meals.jsx for browsing and filtering

- MealDetails/MealDetails.jsx for a meal’s full record and reviews

- Home/MealCategory/* for category-based discovery

- UpcomingMeal/UpcomingMeal.jsx for teaser content tied to subscription upsell

- The README’s search/filter feature is reflected in this area, where pages likely consume meal hooks and render category/price/keyword-driven views.

8. Payments and premium flow

- The premium subscription path is handled in src/pages/Home/Checkout/.

- Checkout.jsx and CheckoutForm.jsx indicate a dedicated payment boundary, with Stripe mentioned in the README.

- This flow likely connects the UI to a backend payment intent endpoint, then updates user membership status after successful payment.

9. User dashboard subsystem

- User-specific state and actions live under src/pages/Dashboard/User/.

- Main features:

- MyProfile for account info

- MyReviews and ReviewEdit for review management

- RequestedMeals for meal requests

- PaymentHistory for subscriptions/payments

- These screens are protected by the auth/JWT layer and use secure API hooks.

10. Admin dashboard subsystem

- Admin functions are grouped under src/pages/Dashboard/Admin/.

- This area covers:

- meal creation and updates

- meal publication/serving workflow

- review moderation

- user management

- upcoming meal scheduling

- admin profile

- AdminRoute.jsx is the boundary that keeps this area separate from normal users.

11. Shared UI and cross-cutting components

- Reusable visual elements live in src/components/:

- titles, containers, loading state, notifications, review modal, social login

- Shared navigation and chrome live in src/pages/Shared/:

- Navbar, Sidebar, Footer, and dropdown menus

- These components form the common UI layer used across both public pages and dashboard views.

12. Stateful interaction patterns

- NotificationDropDown and ReviewModal indicate modal/dropdown-driven interactions layered on top of page data.

- LoadingSpinner.jsx represents async fetching states across the app.

- The app likely follows a pattern of: page component → custom hook → axios client → backend → render/update UI state.

13. Deployment and infrastructure

- firebase.json, .firebaserc, and the .firebase/ directory show the frontend is deployed on Firebase Hosting.

- The live site is hosted at the Firebase URL in the README.

- Build tooling is standard Vite with Tailwind/PostCSS and ESLint, so the repo is focused on client delivery rather than backend runtime concerns.

14. What to show in an architecture diagram

- Draw the frontend as a React SPA with three major zones:

- public marketing/meals browsing

- authenticated user dashboard

- admin dashboard

- Put AuthProvider/Firebase auth and JWT-secured axios clients as shared infrastructure services across all protected flows.

- Treat the backend as an external system providing meals, reviews, users, requests, payments, and admin mutations; Firebase Hosting is the deployment target for the client.