sahrior/10-day-10-react-projects

1. This repository is a collection of standalone React mini-apps, not a single integrated product. Each project lives in its own folder with its own Vite setup, dependencies, and source tree, so there is no shared runtime or cross-project code path.

2. The common architecture across nearly all projects is the same: index.html loads the app shell, src/main.jsx mounts React, and src/App.jsx is the top-level composition point. Styling is usually local to the project through src/index.css, src/App.css, or CSS modules.

3. The main technical stack is React + Vite + plain JavaScript, with some projects using CSS modules and a few using a more componentized folder layout. The repo is front-end only in most cases; backend concerns are mostly absent except for the Firebase-backed contact app.

4. Several projects are simple landing-page or marketing UIs with very shallow architecture. Examples include Brand_Page, Responsive_Navbar, Foody_zone, Car_Service, and BMI_Calculator. Their structure is usually a small set of presentational components like navbar, hero, header, or section blocks.

5. A second pattern is navigation-centric single-page apps where the main boundary is “shared layout + page components.” Car_Service has a Navbar plus page components for Home, OurServices, Careers, and ContactUs. My shop and app also follow this pattern with a navbar, page views, and reusable cards/search results.

6. The most stateful app in the set is Dice_Game. Its architecture is split into gameplay subsystems: score/total tracking, number selection, dice rolling, rules display, and start/gameplay states. The component tree suggests a central game state in App.jsx passed down to smaller UI units.

7. Expense_Tracker is another state-heavy project, organized around financial summaries and input/listing flows. It separates earning and expense concerns into dedicated components, with totals and list components acting as derived views over the entered data.

8. My shop is the clearest example of a data-driven UI. Static product data lives in src/data/products.js, then flows into Productcard and Homecard components, while pages like Home, Cart, and Contact represent the main user navigation boundaries.

9. Contact_Us_Page/Contact_us is more componentized than the simpler projects. It splits the UI into Navigation, ContactHeader, ContactForm, and Button, with CSS modules keeping styles scoped to each component boundary.

10. Contact_App_Firebase is the only project with an obvious external service boundary. Its src/config/firebase.js indicates a Firebase integration layer, and App.jsx likely sits above that config to connect UI interactions with cloud-backed contact data.

11. Some projects are intentionally minimal and serve as practice exercises rather than full applications. Student_Managment, Todo_List, Project5/app, and Project7/BMI_Calculator appear to have smaller component footprints and likely keep most logic inside App.jsx with a few supporting components.

12. From an architecture-diagram perspective, the most important boundary is per-project isolation: each folder is a self-contained front-end app with its own build pipeline, assets, and UI composition. Inside each app, the key flow is typically main.jsx -> App.jsx -> feature components -> local data/assets, with only the Firebase project crossing into an external backend service.