Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Best Practices and Code Organization in React

Best Practices and Code Organization

~16 Min. Lesezeit Zuletzt aktualisiert am August 8, 2026

This chapter summarizes WHY our project is structured the way it is – a deliberate look back across both series ("React for Beginners" + "React for Professionals"), so you can carry the underlying principles into YOUR OWN, new projects.

The folder structure in hindsight: why by TYPE, not by feature

Our project organizes files by TECHNICAL TYPE: components/, pages/, hooks/, store/, api/. The alternative – a "feature-based" structure (features/cart/ with EVERYTHING cart-related inside: component, slice, tests, API calls) – often scales better for VERY large teams/apps, but is unnecessary upfront complexity for a project of this size.

StructureTrade-off
By type (our project)Easy to understand, low overhead, good for small-to-medium projects. With very many features, folders like components/ eventually get unwieldy.
By featureEverything related lives together, deleting a feature = deleting a folder. More upfront structural decisions needed, often overkill for small projects.

Tipp: Rule of thumb: under roughly 15-20 components, organize by type (as here), THEN switch to feature-based once components/ becomes an unwieldy, long list. A premature feature-based structure for a small app is just as much an over-engineering mistake as a missing structure for a huge one.

When to split a component?

ProductListPage has by now become one of our largest files (loading, error handling, search, pagination, Redux dispatch – all in ONE function). A common warning sign: if you have to scroll while reading a component to see the ENTIRE JSX return value, it's a candidate for splitting. Possible next steps for ProductListPage (deliberately NOT implemented in this tutorial, as an exercise for you): extracting the search/filter logic into a custom hook useProductSearch, moving the pagination UI into its own <Pagination /> component.

Naming conventions we consistently followed

  • Components: PascalCase filename = component name (ProductCard.jsx exports ProductCard) – on import, it's IMMEDIATELY clear what the file contains.
  • Custom hooks: ALWAYS with the use prefix (useDocumentTitle, useAuthStore) – React's ESLint rules (eslint-plugin-react-hooks) recognize hooks ONLY by this naming pattern and can't reliably check "rules of hooks" violations otherwise.
  • Event handlers: handle... prefix for local functions (handleFavoriteClick), on... prefix for props that are themselves callback functions (onAddToCart) – the distinction makes it immediately clear on reading WHO calls the function.
  • Boolean variables/props: is.../has... prefix (isFavorite, isPending; hasError would have been more consistent than our error state, which actually holds the error message itself, not a boolean).

Automation: ESLint and Prettier

Vite projects usually come pre-configured with ESLint (npm create vite asks about it). Add eslint-plugin-react-hooks if it's not already there – it catches exactly the mistakes we explained manually in "React for Beginners" chapters 8-12 (missing useEffect dependencies, hooks called inside conditionals). Prettier auto-formats code on save – formatting discussions in code reviews become completely unnecessary as a result.

npm install --save-dev eslint-plugin-react-hooks prettier

A pattern we repeated consistently

Notice the recurring loading/error/data triad? ProductListPage (chapter 23 of "React for Beginners"), similar patterns in SearchDemoPage, even our test suite from the last chapter implicitly checks this pattern. CONSISTENCY across a project is itself a form of quality – a new teammate who understands ONE example of this pattern immediately understands ALL other places using it.

Tipp: The most important best-practice advice, to close: CONSISTENCY beats "perfection". A project that applies a slightly suboptimal pattern EVERYWHERE the same way is more maintainable than one that picks the "theoretically best" individual solution for every feature. Agree on conventions as a team (folder structure, naming, error handling) and stick to them consistently – more important than WHICH exact convention gets chosen.