frontend-patterns - SKILL.md Agent Skill

name: frontend-patterns description: Framework-agnostic UI development patterns for component composition, state management, data fetching, forms, accessibility, performance, and animation. Applies to React, Vue, Svelte, Rails views, Flutter, and any UI framework.

UI Development Patterns

Universal patterns for building maintainable, performant user interfaces. These principles apply across all UI frameworks — React, Vue, Svelte, Angular, Rails ERB/Hotwire, Flutter, SwiftUI, and beyond.

Component Composition

Build UIs from small, single-responsibility, composable units.

Principles:

Each component does ONE thing well
Prefer composition over inheritance — combine simple components to build complex ones
Use slot-based composition for flexible layouts (children, named slots, content blocks)
Compound components share state through context/providers — the parent holds state, children consume it
Extract reusable components when a pattern appears 2+ times

Anti-patterns:

God components that handle rendering, data fetching, and business logic
Prop drilling through 4+ levels — use context/providers instead
Tightly coupling components to specific data shapes — accept generic props

State Management

Three categories of state — choose the simplest option that works:

Local State — Component-scoped, not shared. Toggle visibility, form input values, animation state. Keep it local.

Shared State — App-wide, multiple components need it. Auth status, theme, shopping cart. Use your framework's store/context mechanism. Don't over-architect — start local, elevate only when needed.

Server State — Cached API data with loading/error/stale semantics. Treat separately from UI state. Use dedicated data-fetching patterns (see below). Server state has unique concerns: caching, revalidation, optimistic updates.

Anti-patterns:

Putting everything in global state — most state is local
Duplicating server data in client state instead of caching
Managing derived state manually — compute it from source state

Data Fetching

Every data fetch has 3 states: loading, success, error. Handle all 3.

Principles:

Show loading indicators for operations > 200ms
Display meaningful error messages with retry options
Cache responses when appropriate — avoid redundant network calls
Debounce search/filter inputs (300-500ms)
Use optimistic updates for instant-feeling interactions (update UI before server confirms)
Handle stale data — show cached data while revalidating in background

Anti-patterns:

Ignoring error states — users see blank screens
Fetching on every render without caching
Blocking the entire UI during a single fetch

Form Handling

Principles:

Use controlled forms with explicit state
Validate on submit (not on every keystroke, unless UX requires inline validation)
Show errors near the relevant field, not in a generic banner
Clear field errors when the user starts correcting
Handle submission states: idle → submitting → success/error
Disable submit button during submission to prevent double-submit
Preserve form data on validation failure — never clear the form on error

Anti-patterns:

Silent validation failures — user doesn't know what's wrong
Validating on every keystroke without debounce (distracting)
Resetting the form on error (user loses their input)

Accessibility

Semantic HTML first — use button, nav, main, article, header, footer, section, label, fieldset — not div for everything. Correct semantics give you keyboard support and screen reader support for free.

ARIA when semantics aren't enough:

aria-label for icon-only buttons
aria-expanded for collapsible sections
aria-live for dynamic content updates
role="dialog" with aria-modal="true" for modals

Keyboard navigation:

Arrow keys in lists and menus
Escape to close overlays/modals
Enter/Space to activate buttons and links
Tab order follows visual layout

Focus management:

Trap focus inside modals (Tab cycles within modal, not behind it)
Restore focus to trigger element when modal closes
Auto-focus the first interactive element in new views

Color contrast: WCAG AA minimum (4.5:1 for text, 3:1 for large text).

Performance

Principles:

Lazy load heavy components — don't load what the user hasn't requested
Virtualize long lists — rendering 1000 items kills performance; render only visible items
Memoize expensive computations — recalculate only when inputs change
Code-split by route — each page loads only its own code
Minimize re-renders — avoid unnecessary state updates that cascade through the component tree
Optimize images — use appropriate formats (WebP/AVIF), lazy load below-fold images, provide srcset for responsive sizes

Anti-patterns:

Rendering 1000+ list items without virtualization
Loading all routes upfront in a SPA
Re-computing derived data on every render
Importing entire libraries when you need one function

Animation

Principles:

CSS transitions for simple state changes (hover, focus, visibility)
Scroll-triggered animations for engagement — elements animate as they enter viewport
Staggered reveals for lists — each item animates with a small delay (animation-delay: calc(index * 50ms))
Micro-interactions on hover/focus for polish — scale, shadow, color shifts
Prefer CSS-only solutions — they're lighter and more performant
Use framework animation libraries (Framer Motion, Vue Transitions, CSS Animations API) for complex orchestrated sequences
Respect prefers-reduced-motion — disable animations for users who opt out

High-impact moments:

Page load: one well-orchestrated staggered reveal creates more delight than scattered effects
State transitions: smooth crossfades between views, not jarring cuts
Feedback: button press effects, form submission confirmations

Anti-patterns:

Animation on every element (overwhelming, distracting)
Long durations (>500ms feels sluggish for UI transitions)
Ignoring reduced-motion preferences

Remember: Choose patterns that fit your project's complexity. A simple form doesn't need a state machine. A static page doesn't need virtualization. Apply the right level of architecture for the problem at hand.