Where Page, Layout, Component, and Hook Decisions Belong

The problem

A lot of frontend architecture degrades because the team creates layers but never defines their role.

On paper there are:

• page
• layout
• component
• hook

In practice, any of them can end up doing anything.

Then the predictable symptoms appear:

• a giant page deciding UI details
• a layout that knows business rules
• a component triggering fetch, transformation, and navigation
• a hook hiding coupling behind a nice name

Mental model

These pieces do not exist to make the tree look prettier.

They exist to separate responsibilities.

Short version:

frontend architecture scales better when each layer decides only the kind of thing that makes sense for that layer to decide.

It does not need to become a religious rule.

But it does need a consistent intuition.

Breaking the problem down

The role of the page

Page is usually a good place to:

• compose the screen
• connect navigation context
• decide the main flow
• align the input data of that route

Page usually should not carry:

• micro visual detail
• generic layout rules
• reusable logic buried there for no reason

The role of the layout

Layout is about structural framing.

Examples:

• the app shell
• sidebar
• header
• persistent areas
• arrangement of screen regions

When layout starts deciding specific domain rules, it becomes a leak point.

The role of the component

Component is where concrete UI takes shape.

It is usually a good place for:

• rendering
• local interaction
• visual composition
• small immediate behavior decisions

The problem starts when it becomes the owner of:

• data fetching strategy
• cross-cutting domain rules
• synchronization across too many layers

The role of the hook

Hook is useful when there is repeatable behavior or integration logic worth encapsulating.

It should not exist only to “move code out of the screen.”

Signs of a good hook:

• it names a real behavior
• it hides incidental detail
• it gives consumers a clearer API

Signs of a bad hook:

• it became a drawer for loose code
• it mixes state, fetch, analytics, navigation, and business rules without criteria
• it only moved the problem to another file

Simple example

Imagine a billing screen.

A cleaner split could be:

• the page decides which account is in focus and composes the screen
• the layout handles the common admin shell
• components render the table, filters, and summary blocks
• a hook encapsulates pagination and list loading logic

Bad version:

• the page fetches
• the page transforms data
• the page decides visual state
• the page knows navigation
• the component knows query params
• the hook does half of this with no clear boundary

In that scenario, the problem is not lack of abstraction.

It is abstraction with no owner.

Common mistakes

• Creating a hook to hide volume, not to encapsulate responsibility.
• Putting screen decisions inside the layout.
• Turning the page into an all-powerful file.
• Making a component know too much about backend and navigation at the same time.

How a senior thinks

People who see frontend architecture more clearly usually ask:

• which layer should know this?
• is this decision structural, visual, flow-related, or reusable behavior?
• am I separating responsibility or only spreading code across more files?

That filter usually improves the codebase more than any folder convention.

What this changes for the team

When the layers stop competing with each other:

• reading gets easier
• reuse becomes more natural
• review gets less ambiguous
• evolving the screen requires less archaeological digging

In the end, a lot of “frontend architecture” is just good decision boundaries.

If every layer decides everything, no layer helps very much.

When each one knows its role, the codebase starts to breathe.