component-patterns

name	component-patterns
description	Component patterns — container/presentational for React/Vue/Angular.

Component Patterns

Container / Presentational (Smart / Dumb)

The core idea: separate what data comes from (container) from how it looks (presentational). Presentational components receive everything via props/inputs — they own no side effects and no data fetching.

Aspect	Container (Smart)	Presentational (Dumb)
Responsibility	Fetch data, manage state, handle business logic	Render UI, emit user events
Dependencies	API clients, stores, router	None beyond UI primitives
Reusability	Low — tied to a specific domain	High — usable anywhere
Testability	Test behavior + integration	Test with prop snapshots / storybook
State	Owns or subscribes to state	Receives everything via props/inputs

When to split: as soon as a component both fetches data AND renders UI, extract the rendering into a presentational child. This makes the UI testable without mocking the network.

---

Rules

• One reason to change: if a component would change for a UI tweak AND for an API change, split it.
• No business logic in templates: move conditionals, transforms, and computations to hooks, composables, or services — not inline in JSX/template.
• Props down, events up: data flows down via props/inputs; user intent flows up via callbacks/emits/outputs.
• Max ~150 lines per component: a component that exceeds this is doing too much; split before it grows further.
• Prop sprawl: more than 5–7 props is a design smell — consider decomposition or a configuration object.
• No cross-feature imports: a component in features/orders must not import directly from features/users; go through a shared layer.

---

React

// Container — owns data fetching and state
function OrderListContainer() {
  const { data, isLoading, error } = useOrders()
  if (isLoading) return <Spinner />
  if (error) return <ErrorMessage error={error} />
  return <OrderList orders={data} />
}

// Presentational — pure render, fully testable with props alone
function OrderList({ orders }: { orders: Order[] }) {
  return (
    <ul>
      {orders.map(o => <OrderItem key={o.id} order={o} />)}
    </ul>
  )
}

React-specific rules:

• Custom hooks are the idiomatic container layer — prefer useOrders() over class-based containers.
• Wrap page-level components in an ErrorBoundary; presentational components should not catch errors themselves.
• Use React.memo on stable presentational components to avoid unnecessary re-renders from parent state changes.

---

Vue

<!-- Container -->
<script setup lang="ts">
const { orders, isLoading, error } = useOrders()
</script>
<template>
  <Spinner v-if="isLoading" />
  <ErrorMessage v-else-if="error" :error="error" />
  <OrderList v-else :orders="orders" />
</template>

<!-- Presentational -->
<script setup lang="ts">
defineProps<{ orders: Order[] }>()
</script>
<template>
  <ul>
    <OrderItem v-for="o in orders" :key="o.id" :order="o" />
  </ul>
</template>

Vue-specific rules:

• Composables (useX) are the Vue equivalent of React hooks — put all fetching and state logic there.
• Use defineProps with explicit types; avoid prop drilling beyond two levels — use provide/inject or a store.
• Emit events with defineEmits and typed payloads; never mutate a prop directly.

---

Angular

// Container — smart component, injects service
@Component({
  selector: 'app-order-list-container',
  template: `
    <app-spinner *ngIf="isLoading" />
    <app-error-message *ngIf="error" [error]="error" />
    <app-order-list *ngIf="!isLoading && !error" [orders]="orders" />
  `
})
export class OrderListContainerComponent implements OnInit {
  orders: Order[] = []
  isLoading = false
  error: Error | null = null

  constructor(private orderService: OrderService) {}

  ngOnInit() {
    this.isLoading = true
    this.orderService.getOrders().subscribe({
      next: orders => { this.orders = orders; this.isLoading = false },
      error: err => { this.error = err; this.isLoading = false }
    })
  }
}

// Presentational — dumb component, only @Input / @Output
({
  : ,
  : 
})
   {
  () : [] = []
}

Angular-specific rules:

• Container components inject services; presentational components declare only @Input and @Output.
• Use OnPush change detection on presentational components — they receive immutable inputs, so there's no need for the default dirty-check cycle.
• Global error handling goes in a class that implements ErrorHandler and is provided at the root level ({ provide: ErrorHandler, useClass: AppErrorHandler }); do not swallow errors silently.
• Prefer async pipe over manual subscriptions to avoid memory leaks from forgotten unsubscribe() calls.

---

Svelte

<!-- Container -->
<script lang="ts">
  import { onMount } from 'svelte'
  let orders: Order[] = []
  let isLoading = true

  onMount(async () => {
    orders = await fetchOrders()
    isLoading = false
  })
</script>

{#if isLoading}<Spinner />{:else}<OrderList {orders} />{/if}

<!-- Presentational -->
<script lang="ts">
  export let orders: Order[]
</script>
<ul>{#each orders as o}<OrderItem order={o} />{/each}</ul>

Svelte-specific rules:

• Presentational components export only typed props; avoid $: reactive declarations that reach outside the component boundary.
• Use Svelte stores (writable, derived) as the shared-state layer rather than passing deeply nested props.
• Wrap route-level components in <svelte:boundary> (Svelte 5) for error isolation.

---

Anti-Patterns

Anti-Pattern	Problem
Fetching inside a presentational component	Makes the component untestable without network mocking
Business logic in template expressions	Hard to test, hard to read
Prop drilling beyond two levels	Use a store, context, or composable instead
God component	One component handling routing, fetching, form state, and rendering
Direct store mutation in presentational components	Breaks the unidirectional data flow contract