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.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "separation-of-concerns" with this command: npx skills add yanko-belov/code-craft/yanko-belov-code-craft-separation-of-concerns

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

MixedSeparated
Can't test formattingformatUser() tested in isolation
Can't reuse fetchuseUser() reusable anywhere
Can't reuse UIUserCard reusable with any data
1 complex component4 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

ConcernWhere It Belongs
API callsHooks / Services
Data transformationPure functions
Business rulesPure functions
UI renderingPresentation components
Connecting piecesContainer components

Common Rationalizations (All Invalid)

ExcuseReality
"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.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

dont-repeat-yourself

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

keep-it-simple

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

lazy-loading

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

error-boundaries

No summary provided by upstream source.

Repository SourceNeeds Review