애플리케이션의 데이터 흐름을 조정하기 위해 Effect를 쓰지 마세요

유즈 이펙트 사용 목적 : 컴포넌트를 React가 아닌 위젯, 네트워크, 또는 브라우저 DOM과 같은 외부 시스템과 동기화

 

어떤 코드가 Effect에 있어야 하는지 이벤트 핸들러에 있어야 하는지 확실하지 않은 경우 이 코드가 실행되어야 하는 이유를 자문해 보세요. 컴포넌트가 사용자에게 표시되었기 때문에 실행되어야 하는 코드에만 Effect를 사용하세요.

 

핵심 패턴:

1. 렌더링 로직 내에서 파생 상태 계산:
   • 어떤 상태 $A가 변경될 때 $B 상태도 $A에 기반하여 변경되어야 한다면, $B를 별도의 useState로 관리하기보다는 $A로부터 파생된 값으로 렌더링 로직 내에서 직접 계산합니다.
   • 이것은 $B가 $A의 변화에 즉각적으로 반응하여 재계산되어야 할 때 가장 효율적인 방법입니다.
2. 이벤트 핸들러 내에서 여러 상태 동시 업데이트:
   • 사용자 상호작용(예: 버튼 클릭, 입력 필드 변경)으로 인해 여러 상태가 동시에 변경되어야 할 때, 해당 이벤트 핸들러 함수 내에서 set 함수들을 순차적으로 호출하여 업데이트합니다.
   • React는 여러 set 호출을 하나의 렌더링 배치(batch)로 묶어 처리하므로 효율적입니다.
3. 함수형 업데이트를 통한 이전 상태 기반 업데이트:
   • 이전 상태 값에 기반하여 새로운 상태 값을 계산해야 할 때, set 함수에 값을 직접 전달하는 대신 콜백 함수를 전달하는 함수형 업데이트(setCount(prevCount => prevCount + 1))를 사용합니다.

---

1. props 또는 다른 상태에 기반한 상태 업데이트

• 문제점: firstName과 lastName이라는 두 개의 상태가 있을 때, 이들로부터 fullName이라는 새로운 상태를 파생시켜 Effect 안에서 업데이트하는 방식입니다.
• 왜 Effect가 불필요한가: fullName은 firstName과 lastName이 변경될 때마다 단순히 계산되는 값입니다. Effect를 사용하면 추가적인 렌더링이 발생하여 비효율적입니다.
• 올바른 방법: fullName을 별도의 상태로 관리하지 않고, 렌더링 단계에서 firstName과 lastName으로부터 직접 계산하여 사용합니다. 이는 더 빠르고, 간단하며, 오류 발생 가능성이 적습니다. -> 연속적인 업데이트를 피할 수 있음. 

   

  function ProfileEditor() {
    const [firstName, setFirstName] = useState('John');
    const [lastName, setLastName] = useState('Doe');
  
    // 렌더링 시점에 직접 계산
    const fullName = `${firstName} ${lastName}`;
  
    // ... JSX에서 fullName 사용
  }
  

 

2. 비용이 많이 드는 계산 캐싱

• 문제점: todos 목록을 filter 값에 따라 필터링하여 visibleTodos를 만드는 상황에서, visibleTodos를 Effect 안에서 업데이트하는 방식입니다.
• 왜 Effect가 불필요한가: 필터링 로직(getFilteredTodos)이 가벼운 계산이라면, Effect 없이 렌더링 시점에 직접 계산해도 충분합니다. Effect를 사용하면 불필요한 재렌더링이 발생할 수 있습니다.
• 올바른 방법:
  • 계산이 가벼울 때: 렌더링 시점에 getFilteredTodos(todos, filter)와 같이 직접 함수를 호출하여 사용합니다.
  • 계산이 무거울 때: useMemo Hook을 사용하여 계산 결과를 캐싱합니다. useMemo는 todos나 filter와 같은 의존성 배열의 값이 변경될 때만 계산을 다시 수행하여 불필요한 재계산을 방지합니다.useMemo로 감싸는 함수는 렌더링 중에 실행되므로, 순수한 계산에만 작동.

  import { useMemo } from 'react';
  
  function TodoList({ todos, filter }) {
    // 계산이 무거울 때 useMemo로 캐싱
    const visibleTodos = useMemo(() => getFilteredTodos(todos, filter), [todos, filter]);
  
    // ... JSX에서 visibleTodos 사용
  }
  

 

3. props 변경 시 상태 초기화

• 문제점: ProfilePage 컴포넌트에서 userId prop이 변경될 때 comment 상태를 Effect 안에서 초기화하는 방식입니다. 이 역시 불필요한 재렌더링을 유발합니다.
• 왜 Effect가 불필요한가: React는 컴포넌트의 key prop이 변경되면 해당 컴포넌트를 완전히 새로 마운트(remount)하여 모든 상태를 초기화합니다.
• 올바른 방법: userId를 자식 컴포넌트(예: Profile)의 key prop으로 전달합니다. 이렇게 하면 userId가 달라질 때마다 React가 Profile 컴포넌트를 새로운 인스턴스로 간주하여 내부 상태를 자동으로 초기화합니다.

  function ProfilePage({ userId }) {
    // userId가 변경되면 Profile 컴포넌트가 다시 마운트되면서 내부 상태가 초기화됩니다.
    return <Profile key={userId} userId={userId} />;
  }
  

 

4. 사용자 이벤트 처리

• 문제점: 사용자의 클릭이나 입력과 같은 이벤트가 발생했을 때, 해당 이벤트에 대한 로직(예: API 요청, 알림 표시)을 Effect 안에서 처리하는 방식입니다.
• 왜 Effect가 불필요한가: 사용자 이벤트는 직접적인 상호작용의 결과이며, 이에 따른 부수 효과는 이벤트 핸들러 안에서 즉시 처리되어야 합니다. Effect는 렌더링 이후에 실행되므로, 사용자 경험에 지연을 초래하거나 로직 흐름을 복잡하게 만들 수 있습니다.
• 올바른 방법: 사용자 이벤트(행동)에 대한 로직은 해당 이벤트 핸들러 함수 내에서 직접 처리합니다.
   

  function BuyButton({ productId }) {
    const handleClick = () => {
      // 클릭 이벤트 발생 시 바로 API 호출 및 알림 표시
      fetch(`/api/buy/${productId}`);
      showNotification('구매 완료!');
    };
  
    return <button onClick={handleClick}>구매하기</button>;
  }
  

 

5. 데이터 패칭 (초기화)

• 문제점: Effect 안에서 데이터를 처음 가져오는(Workspace) 로직을 구현하는 것입니다.
• 왜 Effect가 불필요할 수 있는가: Effect를 사용한 데이터 패칭은 일반적이지만, 경쟁 상태(race condition) 처리, 캐싱 등 복잡한 문제를 야기할 수 있습니다. 특히 최신 React 프레임워크(Next.js, Remix 등)나 라이브러리(React Query, SWR)는 데이터 패칭을 위한 더 효율적이고 내장된 메커니즘을 제공합니다.
• 올바른 방법: 프레임워크가 제공하는 데이터 패칭 기능을 활용하거나, 데이터 패칭 로직을 재사용 가능한 커스텀 Hook으로 분리하여 관리하는 것이 좋습니다. 이를 통해 로직을 더 깔끔하게 정리하고, 잠재적인 최적화 기회를 얻을 수 있습니다.