frontend-page-structure

What problem does it solve?

This guide eliminates inconsistent page layouts, unclear filenames, and brittle imports in frontend apps by prescribing a cohesion-driven screens folder convention and clear split rules so teams can navigate, maintain, and refactor pages with confidence.

Core Features & Use Cases

• Cohesion-driven screens folder: Keep route wrappers thin and place actual page components under src/screens to separate routing from page implementation.
• 500-line rule for splitting: Keep files under ~500 lines; split into *.sub, then into *.helper or *.ui when sub internals grow complex.
• Naming and folder conventions: Use context-page.tsx filenames, kebab-case, avoid barrel index exports, and prefer direct relative imports.
• Folder roles and @shared model: Use *.sub for subcomponents, *.views for alternative full UIs, *.helper for business logic, *.ui for presentational pieces, and an @shared three-tier hierarchy for cross-page reuse.
• Anti-pattern guidance: Avoid over-nesting, premature splitting, premature sharing, and generic filenames to preserve clarity and tree-shaking.

Quick Start

Create a new page by adding a context-page.tsx under src/screens/your-domain/your-context/, keep the file under 500 lines and split into *.sub or *.helper folders only when the content exceeds the 500-line guideline, and move any item into @shared as soon as it is used by two or more consumers.