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.
| Structure | Trade-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 feature | Everything 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.jsxexportsProductCard) – on import, it's IMMEDIATELY clear what the file contains. - Custom hooks: ALWAYS with the
useprefix (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;hasErrorwould have been more consistent than ourerrorstate, 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 prettierA 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.