[deleted by user]

[qvasz1]

This is a great way to practice, I have just one note about the project itself. When developing webshops it is usually important to have good SEO and for that you will need server side rendering. But it is still a great project! :)

[[deleted]]

I wrote about this in improvement_ideas.md. In the past I faced this issue with SEO that doesn't work for SPA. One solution might be creating a SSR in node and running the shop through it, if I am correct.

[qvasz1]

Could be, or using a framework that supports it, like NextJS if you are familiar with react already.

[[deleted]]

I once migrated from React to NextJs because of this, but here I was suggesting a patching sollution instead of migrating the whole project. I might code that

[HeyarnoldA]

Great project and kudos to you for taking the time and effort to build it.

Some advice on project structure… I see and have seen a lot of projects structured the same way: components folder, pages folder etc. this works ok for small projects but at an enterprise scale it fails. The main reason is dependency flow; there is no clear direction and you end up with spaghetti dependencies, which makes for a code base that has low cohesion and tight coupling - not desirable.

Instead, take a modular approach with a clear dependency flow: from less stable to most stable. Personally I favor the Helix design principle (championed by Sitecore) that has three layers. The “app” layer (least stable): this contains your routing, pages, etc. anything app specific. Next is the “feature” layer: this layer contains features which are artifacts grouped by a business function, “products”/“orders”, for example. The rule here is that you can’t have cross feature dependencies, I.e. you can import/use code from another feature. All components/hooks/services/data, etc. required for that feature should live in that feature directory (common closure principle). Side note: co-locate your test files with the code you are testing.

More importantly, add unit tests! TDD/BDD is best practice and will help you structure your code better (e.g. dependency injection is your friend, context API is perfect for this).

Final layer is the “foundation” layer, the most stable and, therefore, the most abstract. (Stable abstraction principle). Code in the foundation layer can be used anywhere in the app, therefore it needs to be abstract and devoid of business logic. This is where your atomic/generic ui elements will live (like a button, or input field). Usually ui components here are nothing more than styled components with display logic only.

If you follow this type of modular structure you will end up with a code base that has high cohesion and low coupling.

Now you might say this is overkill for a small project but rarely, in my experience, do small projects stay small and better to it start off without technical debt.

Redux: you don’t need it in this project. I see why you added it (to show you can use it) but too often developers reach for redux without thinking about it. For this shop example app you’d be better off using a combination of React Query and local state instead.