참고 너무 꼼꼼하게 읽으시면 안됨 내용이 좀 쉬울 수 있어서 (생각보다 쉬웟는데 다른거 완전 찾기엔 늦어서 ㅎ..) 꼼꼼하게 다 읽으면 제 발표 시간이 무의미 할 수 잇음..!!! 허허

cascading renders 경고

“Warning: Calling setState synchronously within an effect can trigger cascading renders.”

useEffect 내부에서의 setState

const [query, setQuery] = useState('');
const [results, setResults] = useState([]);
const [isLoading, setIsLoading] = useState(false);

useEffect(() => {
  if (!query.trim()) {
    setIsLoading(false);
    setResults([]);
    return;
  }
  setIsLoading(true);
  debouncedSearch(query, searchType);
}, [query, searchType]);

return (
...
	<input
	    type="text"
	    placeholder="이름을 입력하세요"
	    value={query}
	    onChange={(e) => setQuery(e.target.value)}
	/> 
)

사용자의 입력 → onChange의 setQuery를 통한 query 변경
↓
query 변경에 따른 

이러한 Cascading Render가 왜 문제일까요?

• 불필요한 UI 깜빡임:
  • 사용자 입장에서 query가 화면에 그려진 아주 짧은 순간 이후에 로딩 스피너가 나타납니다. 브라우저가 화면을 한 번 그린(Paint) 직후에 다시 그려야 하므로 미세한 지연이나 깜빡임이 느껴질 수 있습니다.
• 성능 낭비:
  • 컴포넌트 내부의 로직이 무겁거나 자식 컴포넌트가 많을 경우, 모든 keystroke(키 입력)마다 불필요한 연산을 두 번씩 수행하게 됩니다.
• 예측 불가능한 데이터 흐름:
  • useEffect는 비동기적으로 실행되기 때문에, 복잡한 상태가 얽혀있을 경우 우리가 의도한 시점보다 상태 업데이트가 늦게 반영되어 버그를 유발할 가능성이 커집니다.

React 가 말하는 잘못된 effect 패턴

1. effect에서 props를 그대로 state로 복사

function Component({ data }) {
  const [items, setItems] = useState([]);

  useEffect(() => {
    setItems(data)

문제점

• data가 바뀌면 : 렌더 → effect 실행 → setItems (추가렌더)
• 하지만 결국은 items === data

  → 아무 의미 없는 렌더 한 번 추가

왜 문제인가?

• items는 독립적인 상태가 아닌 props에서 완전히 파생된 값

더 나은 방법

functionComponent({ data }) {
	const items = data;
}

2. 로딩 상태를 effect에서 “즉시” 켜는 경우

useEffect(() => {
	setLoading(true);
	fetchData().then(() =>setLoading(false));
}, []);

문제점

• effect는 이미 화면이 그려진 뒤 실행됨
• 그 안에서 setLoading(true) 하면

  렌더 → commit → paint 다시 발생 : 불필요한 중간 상태 렌더링

결과

• UI 깜빡임
• 렌더 사이클 1회 추가
• ESLint의 cascading render 경고

3. 데이터 변환을 effect에서 수행

useEffect(() => {
	setProcessed(rawData.map(transform));
}, [rawData]);

문제점

• processed는 rawData로부터 항상 계산 가능
• effect + state는 중복된 추상화

더 나은 방법

const processed = rawData.map(transform);

4. props에서 파생된 상태를 effect로 관리

function SearchList({ items, query }) {
  const [filteredItems, setFilteredItems] = useState([]);

  // 불필요한 연쇄 렌더링
  useEffect(() => {

문제점

• props → effect → state → 렌더

더 나은 방법

function SearchList({ items, query }) {
  // 별도의 State와 Effect 없이 직접 계산
  const filteredItems = items.filter(item => item.name.includes(query));

  return (
    <

리액트 useEffect 를 써야하는 곳

• setInterval이나 setTimeout을 설정하고 해제할 때
• window.addEventListener로 브라우저 이벤트를 구독할 때
• 특정 검색어에 맞춰 서버에서 데이터를 가져올 때 (Data Fetching)
• 외부 시스템
  • API 네트워크 호출, 브라우저 DOM 직접 조작(타이틀 변경 등), 리액트로 만들어지지 않은 위젯(jQuery 등)
• 내부 시스템
  • Props가 바뀌어서 State를 업데이트하는 것, State가 바뀌어서 또 다른 State를 바꾸는 것

ref에서 온 값으로 state 설정 시 사용

functionTooltip() {
	const ref = useRef(null);
	const [tooltipHeight, setTooltipHeight] = useState(0);

	useLayoutEffect(() => {

왜 이건 괜찮을까?

• tooltipHeight는 렌더 시점에 알 수 없다
  • ref.current.getBoundingClientRect()

    → 실제 DOM이 화면에 존재해야만 측정 가능

• props, state, 렌더 중 계산 모두 해당되지 않음

  → 렌더 이후(커밋 이후)에만 얻을 수 있는 값

이런 경우가 리액트가 권장하는 effect의 사용 목적 → 외부 시스템(DOM, 브라우저 API) 과 동기화 하는 사례!

왜 useLayoutEffect 예시일까?

• useEffect → paint 이후 실행
• useLayoutEffect → DOM 반영 직후, paint 이전 실행

  → 높이를 측정하고 state를 바꿔도 사용자는 중간 상태(깜빡임)를 보지 않음

  → 그럼 항상 useLayoutEffect 가 좋을까?

  useLayoutEffect는 paint를 막기 때문에(브라우저가 화면 그리는 걸 멈춰놓은 상태)

  무거운 연산, 네트워크 요청, 반복적인 setState 는 하면 안됨

기존 props나 state로부터 “계산할 수 있는 값”이라면 state로 저장하지 말고, 렌더링 중에 계산해야 한다.

반대로, DOM 측정처럼 “렌더 이후에만 알 수 있는 값”은 effect + setState가 정당하다

useEffect를 걷어내는 실전 방법들

1. Race Condition과 Cleanup

문제 상황

• 사용자가 빠르게 입력 (주 → 주토 → 주토피아)
• 3개의 요청이 거의 동시에 전송
• 네트워크 특성상 이전 요청이 더 늦게 도착할 수 있음
• 결과적으로 최신 query가 아닌 결과가 화면에 남는 문제

useEffect(() => {
  let ignore = false;

  async function fetchResults() {
    const data = await searchMedia(query);
    if (!

왜 이게 동작할까?

• query가 바뀌면
  1. 이전 effect의 cleanup 실행 (ignore = true)
  2. 새로운 effect 실행
• 이전 요청이 늦게 도착해도
  • 이미 ignore === true
  • 상태 업데이트 무시

Effect는 실행이 아니라 외부 시스템과의 동기화다. 그러니 사용 시 항상 이 외부 작업은 언제 무효가 되는가?를 함께 생각해야 함

2. Key를 이용한 상태 초기화

• 예시
  • 유저 변경 시 작성 중이던 폼 초기화
  • 게시글 id 변경 시 편집 상태 초기화

export default function ProfilePage({ userId }) {
  return (
    <Profile
      userId={userId}
      key={userId}
    />
  );
}

왜 이게 더 좋은가?

• key 변경 → React는 완전히 다른 컴포넌트로 인식
• 이전 컴포넌트:
  • cleanup
  • unmount
• 새 컴포넌트:
  • mount
  • 모든 useState 초기화

3. 렌더 중 상태 조정 (Advanced)

function Profile({ userId }) {
  // 이 state 및 아래의 다른 state는 key 변경 시 자동으로 재설정됨
  const [prevItems, setPrevItems] = useState(userId); //동균
  // ..
  if (userId !== prevItems) {

• effect보다 빠름
  왜 effect보다 빠를까?

  • useEffect
    • render → commit → paint → effect → setState → 다시 render
    • 중간 상태가 화면에 그려질 수 있음
  • 렌더 중 setState:
    • 조건 만족 시 현재 렌더를 즉시 폐기
    • 바로 재렌더
    • commit / paint는 최종 상태만
• 중간 상태 paint 방지
• 공식 문서에서 드물게 허용함

처음 문제 개선 사항 나아가기

1단계: Race Condition(경쟁 상태) 해결

useEffect(() => {
  let ignore = false;
  async function fetchResults() {
    const data = await searchMedia(query);
    if (!ignore

2단계: 구조적 개선 - 커스텀 훅으로의 분리 (선언적 코드)

// 커스텀 훅
function useSearch(query) {
  const [data, setData] = useState(null);
  const [isLoading, setIsLoading] = useState(false);

3단계: 라이브러리 도입

// 라이브러리를 사용하면 Effect와 State 관리 필요가 없음
const { data, isLoading } = useQuery({
  queryKey: ['search', query],
  queryFn: () => fetchSearch(query)
});

• 참고자료
  • https://react.dev/reference/eslint-plugin-react-hooks/lints/set-state-in-effect
  • https://react.dev/learn/you-might-not-need-an-effect