Features own capabilities. Pages compose them.

@Component({
  selector: 'app-user-card',
  templateUrl: './user-card.component.html'
})
export class UserCardComponent {
  @Input() user: User;

  constructor(
    private userService: UserService,
    private router: Router
  ) {}

  editUser() {
    this.router.navigate(['/admin/users/edit', this.user.id]);
  }
}

The rigidity isn't in the code you can see. It is in what the component assumes about where it is rendered: which route, which page, which data. The view is the most volatile thing in a frontend. Couple a component to it and the component inherits that volatility, and so does every page that uses it.

Stop asking

How do I make this component reusable everywhere?

Start asking

How do I make features composable on pages?

Components that try to be generic fail, because genericness is bought with props. Features go the other way: specific to one business capability, and composable anywhere. The page decides where a feature appears and what happens around it. The feature decides everything about how it works.

• features/

  Business capabilities

  Self-contained mini-applications. Everything for user management, components, state, services, lives in one folder.

  • user-management/
  • product-catalog/
  • order-processing/

• pages/

  Orchestrators

  Conductors. They arrange features on screen, handle navigation and hold zero business logic.

  • dashboard/
  • admin/
  • customer-portal/

• shared/

  Truly generic

  Buttons, pipes and utilities that work anywhere and belong to no business domain.

  • components/
  • utils/

• core/

  App foundation

  Authentication, the layout shell and configuration. Things genuinely global to the app.

  • auth/
  • layout/
  • config/

Features own business capabilities. Pages compose features. That is it.

allowedforbidden

1. 01

   Pages touch a feature's public API. Nothing else.

   Never a container class, component, service, store, action or selector. A page that reaches past the barrel breaks the day the implementation changes, which is precisely the coupling the pattern exists to prevent. If a page needs more, widen the facade on purpose.

2. 02

   Features never import features.

   The violation that quietly undoes everything: once two features are coupled, neither can be tested, moved or reused alone. When they need to talk, the page carries the value. If that feels absurd because they are inseparable, they are one feature.

3. 03

   A component that injects a service is not a component.

   It is a container wearing the wrong label. Move the logic up into the container and pass the result down as an input, or admit what the file is and move it to containers/.

<app-date-picker-container
  (dateRangeChanged)="range = $event">
</app-date-picker-container>

<app-sales-chart-container
  [dateRange]="range">
</app-sales-chart-container>

@Component({ templateUrl: './dashboard.html' })
export class DashboardPage {
  constructor(private router: Router) {}

  onUserSelected(id: string): void {
    this.router.navigate(['/users', id]);
  }
}

<!-- dashboard.html -->
<div class="dashboard-grid">
  <app-analytics-container mode="summary"></app-analytics-container>
  <app-user-management-container
    mode="compact"
    [maxItems]="10"
    (userSelected)="onUserSelected($event)">
  </app-user-management-container>
</div>

// pages/DashboardPage.tsx
import { AnalyticsContainer } from '@/features/analytics';
import { UserManagementContainer } from '@/features/user-management';

export function DashboardPage() {
  const navigate = useNavigate();

  return (
    <div className="dashboard-grid">
      <AnalyticsContainer mode="summary" />
      <UserManagementContainer
        mode="compact"
        maxItems={10}
        onUserSelected={(id) => navigate(`/users/${id}`)}
      />
    </div>
  );
}

<!-- pages/DashboardPage.vue -->
<script setup lang="ts">
import { useRouter } from 'vue-router';
import { AnalyticsContainer } from '@/features/analytics';
import { UserManagementContainer } from '@/features/user-management';

const router = useRouter();
</script>

<template>
  <div class="dashboard-grid">
    <AnalyticsContainer mode="summary" />
    <UserManagementContainer
      mode="compact"
      :max-items="10"
      @user-selected="id => router.push(`/users/${id}`)"
    />
  </div>
</template>

<!-- routes/dashboard/+page.svelte -->
<script lang="ts">
  import { goto } from '$app/navigation';
  import { AnalyticsContainer } from '$lib/features/analytics';
  import { UserManagementContainer } from '$lib/features/user-management';
</script>

<div class="dashboard-grid">
  <AnalyticsContainer mode="summary" />
  <UserManagementContainer
    mode="compact"
    maxItems={10}
    on:userSelected={(e) => goto(`/users/${e.detail}`)}
  />
</div>

The concept map

The series writes its examples in Angular. The React, Vue and Svelte mappings are an adaptation of the same rules, kept in the repository as framework-translation.md.

Agents that don't load skills read AGENTS.md at the repository root: the whole pattern in four lines, the rules that must not break, and where every new file goes.

Three ways in

• Teams actively building

  New features only

  New work goes into features/ and pages/. Old code stays where it is.

  Immediate

• Teams with one bad page

  Extract one messy page

  Split the worst page into small features, one concern per pass.

  1–2 sprints

• Stable codebases

  Refactor when you touch it

  Boy Scout rule: extract only the part you are already changing.

  No dedicated time

The first feature is the hardest. It gets easier.