renderpx

Pattern Browser

Quick reference guide to all patterns. Framework-level patterns link to the full framework; implementation patterns have dedicated pages with the full 7-part template (problem → naive → improvement → production → when to use → gotchas).

Search coming soon

Implementation Patterns

Deep-dive pages: problem, naive approach, first improvement, remaining issues, production pattern, when I use this, gotchas.

Optimistic Updates

Use when: Instant feedback for likes, follows, toggles

Data & State
Read full pattern →

Infinite Scroll

Use when: Feeds, timelines, long lists

Data & State
Read full pattern →

Debouncing & Throttling

Use when: Search, scroll, resize, high-frequency events

Data & State
Read full pattern →

Form Validation (Client + Server)

Use when: Signup, checkout, any form with rules

Forms
Read full pattern →

Loading States

Use when: Skeletons, spinners, pending vs refetch

UI
Read full pattern →

Error Boundaries

Use when: Catch render errors, show fallback, retry

UI
Read full pattern →

Cache Invalidation

Use when: After mutations, keep cache in sync

Data & State
Read full pattern →

Polling vs WebSockets

Use when: When to poll, when to push, hybrid

Data & State
Read full pattern →

Multi-Step Forms

Use when: Checkout, onboarding, long wizards

Forms
Read full pattern →

Virtualized Lists

Use when: Long lists, feeds, tables (500+ rows)

UI
Read full pattern →

Stale-While-Revalidate

Use when: Show cached data, refresh in background

Data & State
Read full pattern →

Autosave / Draft

Use when: Editors, long forms, prevent lost work

Forms
Read full pattern →

Dependent Fields

Use when: Country → city, product → variant, conditional options

Forms
Read full pattern →

Toasts

Use when: Success/error feedback, non-blocking notifications

UI
Read full pattern →

Modal Management

Use when: Dialogs, focus trap, escape, stacking

UI
Read full pattern →

Compound Components

Use when: Card.Header, Tabs + panels, flexible structure

Components
Read full pattern →

Render Props vs Hooks

Use when: Reuse behavior, inject state into UI

Components
Read full pattern →

Controlled vs Uncontrolled

Use when: Forms, inputs, value vs ref

Components
Read full pattern →

HOCs vs Composition

Use when: Auth guards, wrappers, inject logic

Components
Read full pattern →

Code Splitting & Lazy Loading

Use when: Smaller bundles, load on demand

Performance
Read full pattern →

Memoization (useMemo, React.memo)

Use when: Expensive derivations, skip re-renders

Performance
Read full pattern →

State Management

Component Composition

Data Fetching

Rendering Strategy

Quick Decision Trees

State: Where should this data live?

Q: Where is data accessed?
├─ One component → Local State
├─ 2-3 siblings → Lifted State
├─ Needs URL? → URL State
├─ From API? → Server State
└─ Complex app-wide → Global State

Components: How should they communicate?

Q: What's the relationship?
├─ Parent-child → Props
├─ Need behavior injection → Render Props
├─ Flexible structure → Compound Components
└─ Full styling control → Headless Pattern

Common Anti-Patterns

❌ Context for High-Frequency

Using Context for data that updates on every keystroke causes entire tree to re-render.

Fix: Use Zustand with selectors or keep state local

❌ Manual API State

Managing loading/error/data state manually with useEffect.

Fix: Use React Query for all API data

❌ Premature Global State

Adding Redux/Zustand before feeling pain of prop drilling.

Fix: Start local, lift when it actually hurts

❌ URL for UI Chrome

Putting sidebar/modal state in URL when it's not shareable.

Fix: Use local state or localStorage for UI preferences