separation-of-concerns

separation-of-concerns

Use when component does too many things. Use when mixing data fetching, logic, and presentation. Use when code is hard to test.

4bintang
0fork
Diperbarui 1/23/2026
SKILL.md
readonlyread-only
name
separation-of-concerns
description

Use when component does too many things. Use when mixing data fetching, logic, and presentation. Use when code is hard to test.

Separation of Concerns

Overview

Each piece of code should do one thing. Data, logic, and presentation should be separate.

Mixed concerns create untestable, unreusable, unmaintainable code. Separation enables testing, reuse, and clarity.

When to Use

  • Component fetches, transforms, and displays data
  • Business logic mixed with UI code
  • Database queries in controllers
  • Hard to test a piece of code in isolation

The Iron Rule

NEVER mix data fetching, business logic, and presentation in one place.

No exceptions:

  • Not for "it's a small component"
  • Not for "it's simpler this way"
  • Not for "only used once"
  • Not for "it works"

Detection: Mixed Concerns Smell

If one file does fetch + transform + display, STOP:

// ❌ VIOLATION: Component does everything
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  
  useEffect(() => {
    // Data fetching
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => {
        // Business logic / transformation
        const fullName = `${data.firstName} ${data.lastName}`;
        const memberSince = new Date(data.createdAt).toLocaleDateString();
        const isVIP = data.orderCount > 100;
        
        setUser({ ...data, fullName, memberSince, isVIP });
        setLoading(false);
      });
  }, [userId]);
  
  // Presentation
  if (loading) return <div>Loading...</div>;
  
  return (
    <div className="user-profile">
      <h1>{user.fullName}</h1>
      {user.isVIP && <span className="vip-badge">VIP</span>}
      <p>Member since: {user.memberSince}</p>
    </div>
  );
}

Problems:

  • Can't test formatting without fetching
  • Can't reuse fetch logic
  • Can't reuse presentation
  • Component does 3 jobs

The Correct Pattern: Separated Layers

// ✅ CORRECT: Separated concerns

// 1. Data fetching (hook)
// hooks/useUser.ts
function useUser(userId: string) {
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);
  
  useEffect(() => {
    setLoading(true);
    fetch(`/api/users/${userId}`)
      .then(res => {
        if (!res.ok) throw new Error('Failed to fetch');
        return res.json();
      })
      .then(setUser)
      .catch(setError)
      .finally(() => setLoading(false));
  }, [userId]);
  
  return { user, loading, error };
}

// 2. Business logic (pure functions)
// utils/userFormatters.ts
interface FormattedUser {
  fullName: string;
  memberSince: string;
  isVIP: boolean;
}

function formatUser(user: User): FormattedUser {
  return {
    fullName: `${user.firstName} ${user.lastName}`,
    memberSince: new Date(user.createdAt).toLocaleDateString(),
    isVIP: user.orderCount > 100,
  };
}

// 3. Presentation (dumb component)
// components/UserCard.tsx
interface UserCardProps {
  fullName: string;
  memberSince: string;
  isVIP: boolean;
}

function UserCard({ fullName, memberSince, isVIP }: UserCardProps) {
  return (
    <div className="user-profile">
      <h1>{fullName}</h1>
      {isVIP && <span className="vip-badge">VIP</span>}
      <p>Member since: {memberSince}</p>
    </div>
  );
}

// 4. Composition (container component)
// pages/UserProfile.tsx
function UserProfile({ userId }) {
  const { user, loading, error } = useUser(userId);
  
  if (loading) return <LoadingSpinner />;
  if (error) return <ErrorMessage error={error} />;
  if (!user) return <NotFound />;
  
  const formatted = formatUser(user);
  
  return <UserCard {...formatted} />;
}

Benefits of Separation

Mixed Separated
Can't test formatting formatUser() tested in isolation
Can't reuse fetch useUser() reusable anywhere
Can't reuse UI UserCard reusable with any data
1 complex component 4 simple pieces

The Layers

1. Data Layer (Hooks, Services)

  • Fetching data
  • API calls
  • State management
  • No business logic

2. Logic Layer (Pure Functions)

  • Transformations
  • Calculations
  • Validations
  • Business rules

3. Presentation Layer (Components)

  • Rendering UI
  • Styling
  • User interactions
  • No data fetching

4. Composition Layer (Containers)

  • Connects layers
  • Handles loading/error states
  • Passes data down

Pressure Resistance Protocol

1. "It's a Small Component"

Pressure: "For simple cases, separation is overkill"

Response: Small becomes large. Start clean, stay clean.

Action: Separate even for small components. It costs little.

2. "It's Simpler This Way"

Pressure: "Everything in one place is easier to understand"

Response: Mixed concerns seem simple but are hard to test, debug, and modify.

Action: Separation is simpler in the long run.

3. "Only Used Once"

Pressure: "This component is unique, won't be reused"

Response: Testability matters even for unique components.

Action: Separate for testability, not just reuse.

Red Flags - STOP and Reconsider

  • useEffect with fetch + transform + setState
  • Business logic in render functions
  • Database queries in route handlers
  • API calls in utility functions
  • Components with 100+ lines

All of these mean: Separate the concerns.

Quick Reference

Concern Where It Belongs
API calls Hooks / Services
Data transformation Pure functions
Business rules Pure functions
UI rendering Presentation components
Connecting pieces Container components

Common Rationalizations (All Invalid)

Excuse Reality
"Small component" Small grows. Separate now.
"Simpler together" Separated is simpler to test/modify.
"Only used once" Testability matters.
"It works" Working ≠ maintainable.
"Over-engineering" This is just engineering.

The Bottom Line

Data fetching in hooks. Logic in pure functions. UI in components.

Separation enables testing, reuse, and maintainability. A component should either fetch data, transform it, or display it - never all three.

You Might Also Like

Related Skills

coding-agent

coding-agent

179Kdev-codegen

Run Codex CLI, Claude Code, OpenCode, or Pi Coding Agent via background process for programmatic control.

openclaw avataropenclaw
Ambil
add-uint-support

add-uint-support

97Kdev-codegen

Add unsigned integer (uint) type support to PyTorch operators by updating AT_DISPATCH macros. Use when adding support for uint16, uint32, uint64 types to operators, kernels, or when user mentions enabling unsigned types, barebones unsigned types, or uint support.

pytorch avatarpytorch
Ambil
at-dispatch-v2

at-dispatch-v2

97Kdev-codegen

Convert PyTorch AT_DISPATCH macros to AT_DISPATCH_V2 format in ATen C++ code. Use when porting AT_DISPATCH_ALL_TYPES_AND*, AT_DISPATCH_FLOATING_TYPES*, or other dispatch macros to the new v2 API. For ATen kernel files, CUDA kernels, and native operator implementations.

pytorch avatarpytorch
Ambil
skill-writer

skill-writer

97Kdev-codegen

Guide users through creating Agent Skills for Claude Code. Use when the user wants to create, write, author, or design a new Skill, or needs help with SKILL.md files, frontmatter, or skill structure.

pytorch avatarpytorch
Ambil

Implements JavaScript classes in C++ using JavaScriptCore. Use when creating new JS classes with C++ bindings, prototypes, or constructors.

oven-sh avataroven-sh
Ambil

Creates JavaScript classes using Bun's Zig bindings generator (.classes.ts). Use when implementing new JS APIs in Zig with JSC integration.

oven-sh avataroven-sh
Ambil