jubayer608/artifacts-tracker-client-a11

1. This repository is the frontend client for “Historical Artifacts Tracker.” The tree contains a React application plus Firebase hosting/config files, but no backend source code. The README describes a separate backend stack (Express, MongoDB, Firebase Admin, JWT) that this client is expected to talk to.

2. The app is built with React 19 + React Router v7 and bootstrapped through src/main.jsx, src/App.jsx, and src/router/router.jsx. Routing is the central composition layer: it decides which page module renders, and it likely wraps the app in shared providers and layout components.

3. There is a clear app shell / layout boundary in src/RootLayout/RootLayout.jsx, plus shared route-level concerns in src/routes/TitleManager.jsx and src/routes/NotFound.jsx. This suggests every page is rendered inside a consistent frame with document-title management and a fallback 404 route.

4. Authentication is a major subsystem. src/firebase/firebase.init.js initializes Firebase Auth, and src/contexts/AuthContext/AuthProvider.jsx + AuthContext.jsx expose auth state to the tree. src/routes/PrivateRoute.jsx enforces access to protected pages, and the README notes an HTTP-only JWT flow for secure access to private data/actions.

5. The protected user areas are clustered under src/pages/ArtifactCrud and include add/update/manage/liked artifacts. These pages represent the main “user-owned content” workflow: create artifact entries, edit them, and view liked or personal artifacts. This is the primary write-side of the app’s data model.

6. The public discovery side lives under src/pages/Home, src/pages/Search, src/pages/ArtifactDetails, src/pages/Collections, src/pages/Compare, src/pages/Comparison, and src/pages/Timeline. Together these modules cover browsing, filtering, detail views, collections, comparisons, and timeline-style exploration of artifacts.

7. The Home page is highly sectionalized rather than monolithic. It is composed from many small feature sections such as banner/slider, featured artifacts, reviews/testimonials, stats, newsletter, spotlight, recent items, and about content. This implies the landing experience is assembled from independent content blocks rather than a single feed.

8. Reusable presentation primitives live in src/pages/Shared and src/components. Notable shared components include NavBar, Footer, ArtifactCard, SocialLogin, ThemeToggle, LoadingSpinner, and AdvancedSearch. These are the cross-cutting UI building blocks used across multiple routes and feature pages.

9. Theme management is another app-wide concern. src/contexts/ThemeContext.jsx and its provider manage light/dark or theme-state behavior, and ThemeToggle is the user-facing control. This context likely wraps the entire app so theme state persists across routes.

10. The app’s external integrations are centered on Firebase and a separate backend API. Firebase handles authentication and hosting; the README says the backend uses JWT and Firebase Admin for token verification, so the client likely authenticates with Firebase, obtains/uses a token, then calls protected artifact endpoints.

11. Static assets are organized in src/assets by feature area (banner, login, register), which reinforces the page-centric structure. Styling is handled with Tailwind CSS v4 plus DaisyUI, with additional animation support from Framer Motion and carousel behavior from Swiper.

12. Build and deployment are front-end focused: Vite is the dev/build tool, firebase.json and .firebaserc indicate deployment to Firebase Hosting, and .firebase/ contains generated hosting cache/state. eslint.config.js and tailwind.config.js provide code-quality and styling configuration boundaries.

13. For an architecture diagram, the main flows are: user enters app → router selects page → root layout/shared shell renders → auth/theme contexts provide global state → page modules fetch or mutate artifact data → private routes gate protected CRUD and liked-artifact screens → Firebase Hosting serves the built SPA.