[Adding Interactivity] Queueing a Series of State Updates | 일련의 상태 업데이트를 대기열에 넣기

상태 변수를 설정하는 것은 또 다른 렌더링을 대기열에 넣는 거예요. 그러나 때때로 다음 렌더링을 대기열에 넣기 전에 다양한 연산을 하고 싶을 수도 있어요. 이를 하기 위해서는 리액트가 상태 업데이트를 어떻게 배칭하는지를 이해하면 도움이 될 거예요.

 

이 페이지에서는

　- "배칭"이란 무엇이고 리액트는 여러 상태 업데이트를 수행할 때 이를 어떻게 사용하는지
　- 어떻게 동일한 상태변수에 연속적으로 여러 업데이트를 적용하는지

를 알아볼 거예요.

---

React batches state updates | 리액트는 상태 업데이트를 배칭해요

"+3" 버튼을 클릭하면 setNumber(number + 1)이 3번 호출되기 때문에 카운터가 3번 증가한다고 생각할 거예요.

 

 

그러나 이전 섹션을 다시 부를때, 각 렌더링의 상태 값을 변하고 첫 번째 렌더링의 이벤트 핸들러에 있는 number의 값은 setNumber(1)을 몇 번 호출하든 항상 0이에요.

setNumber(0 + 1);
setNumber(0 + 1);
setNumber(0 + 1);

 

하지만 한 가지 사실을 더 고민해야해요. 리액트는 상태 업데이트를 진행하기 전에 이벤트 핸들러의 모든 코드가 동작할 때까지 기다려요. 그렇기 때문에 리렌더링은 모든 setNumber() 호출 후에 발생해요.

 

아마 웨이터가 식당에서 주문을 받는 예시가 생각날 거예요. 웨이터는 첫 번째 요리를 주문 받자마자 부엌으로 달려가지 않아요. 대신, 주문을 모두 받고, 주문에 대한 변경 사항을 모두 적고, 심지어는 다른 테이블에 있는 다른 사람들의 주문을 모두 받아요.

 

Illustrated by Rachel Lee Nabors (출처: react.dev)

 

이러한 특성은 과도한 리렌더링을 발생시키지 않고서도 여러 상태 변수를, 심지어는 여러 컴포넌트에 있는 여러 상태 변수를 업데이트 해줘요. 하지만 이는 UI가 이벤트 핸들러와 그 안의 모든 코드가 종료된 이후까지 업데이트 되지 않는다는 것을 의미하기도 해요. 배칭이라고 알려진 이 동작은 리액트 앱이 더욱 빠르게 동작하도록 만들어줘요. 또한 어떤 변수만 업데이트 된 상태인 "반만 끝낸" 리렌더링과 만나지 않도록 해줘요.

 

리액트는 클릭과 같은 여러개의 의도적인 이벤트를 배칭하지는 않아요. 각각의 클릭은 독립적으로 처리돼요. 리액트는 일반적으로 안전한 경우에만 배칭을 하니 안심하세요. 예를 들어 만약 첫 번째 버튼이 폼에서 사용이 불가능하면 두 번째 버튼은 다시 제출되지 않는다는 것을 보장해요.

---

Updating the same state multiple times before the next render | 다음 렌더링 전에 같은 상태를 여러번 업데이트 하기

이는 일반적으로 사용되지 않아요. 하지만 만약 다음 렌더링 전에 같은 상태 변수를 여러번 업데이트 하고 싶다면, setNumber(n => n + 1)과 같은 다음 상태 변수를 전달하는 대신 setNumber(n => n + 1)과 같이 큐 안에 있던 이전의 함수에 기반하여 다음 상태를 계산하는 함수를 전달하세요. 이는 리액트에게 단순하게 상태를 대체하지 말고 "상태 변수로 무언가를 하세요"라고 이야기하는 방법이에요.

 

이제 카운터를 증가시켜 보세요.

 

 

여기서 n => n + 1은 업데이터 함수라고 해요. 상태 setter에 이 함수를 전달하면

1. 리액트는 이벤트 핸들러의 모든 다른 코드를 실행한 후에 작동하도록 이 함수를 대기열에 넣어요.
2. 다음 렌더링 동안, 리액트는 이 큐를 통과하여 최종적으로 업데이트된 상태를 전달해요.

setNumber(n => n + 1);
setNumber(n => n + 1);
setNumber(n => n + 1);

 

이벤트 핸들러를 실행하는 동안 리액트가 이 코드를 실행하는 방법은 다음과 같아요.

1. setNumber(n => n + 1) : n => n + 1은 함수에요. 리액트는 이것을 큐에 넣어요.
2. setNumber(n => n + 1) : n => n + 1은 함수에요. 리액트는 이것을 큐에 넣어요.
3. setNumber(n => n + 1) : n => n + 1은 함수에요. 리액트는 이것을 큐에 넣어요.

다음 렌더링 동안 useState를 호출하면 리액트는 큐를 통과해요. 이전의 number 상태는 0이었기 때문에 리액트는 첫 번째 업데이트 함수에 n 인자로 전달해요. 그리고 나서 리액트는 이전 업데이터 함수의 반환 겂을 가져와서 다음 업데이터 함수의 n에 이 값을 전달해요.

대기열에 있는 업데이트	n	반환값
n => n + 1	0	0 + 1 = 1
n => n + 1	1	1 + 1 = 2
n => n + 1	2	2 + 1 = 3

 

리액트는 최종값으로 3을 저장하고 useState에서 이를 반환해요.

 

위의 예시에서 "+3"을 클릭하면 3으로 값을 업데이트 해주는 이유가 바로 이 과정을 거쳤기 때문이에요.

 

What happens if you update state after replacing it | 상태를 대체한 후 업데이트를 하면 일어나는 일

이 이벤트 핸들러는 어떨까요? number가 다음 렌더링에서 어떻게 될 것 같나요?

<button onClick={() => {
  setNumber(number + 5);
  setNumber(n => n + 1);
}}>

 

 

아래의 함수는 이 이벤트 핸들러가 알려주는 리액트의 할 일이에요.

1. setNumber(number + 5): number는 0이기 때문에 setNumber(0 + 5)가 돼요. 리액트는 큐에 "5로 대체한다"를 추가해요.
2. setNumber(n => n + 1): n => n + 1는 업데이터 함수예요. 리액트는 큐에 이 함수를 추가해요.

다음 렌더링 동안 리액트는 상태 큐를 통과해요.

대기열에 있는 업데이트	n	반환값
5로 대체하기	0(미사용)	5
n => n + 1	5	5 + 1 = 6

 

리액트는 최종 값으로 6을 저장하고 useState에서 이 값을 반환해요.

노트
setState(5)가 실제로는 setState(n => 5)로 작동하지만 n은 사용되지 않는다는 사실을 기억하세요!

---

What happens if you replace state after updating it | 상태를 업데이트 한 후에 상태를 대체한다면 일어나는 일

한 가지 예시를 더 볼게요. number가 다음 렌더링에서 어떻게 될 것 같나요?

<button onClick={() => {
  setNumber(number + 5);
  setNumber(n => n + 1);
  setNumber(42);
}}>

 

 

이벤트 핸들러를 실행하는 동안 리액트가 이 코드를 실행하는 방법은 다음과 같아요.

1. setNumber(number + 5): number는 0이기 때문에 setNumber(0 + 5)가 돼요. 리액트는 큐에 "5로 대체한다"를 추가해요.
2. setNumber(n => n + 1): n => n + 1은 업데이터 함수예요. 리액트는 큐에 이 함수를 추가해요.
3. setNumber(42): 리액트는 큐에 "42로 대체한다"를 추가해요.

다음 렌더링동안 리액트는 상태 큐를 통과해요.

대기열에 있는 업데이트	n	반환값
5로 대체하기	0(미사용)	5
n => n + 1	5	5 + 1 = 6
42로 대체하기	0(미사용)	5

 

그리고 나서 리액트는 최종값으로 42를 저장하고 useState에서 이 값을 반환해요.

 

요약하자면 setNumber 상태 세터함수에 전달하는 방법은 이렇게 말할 수 있어요.

• 업데이터 함수(예. n => n + 1)를 큐에 추가해요.
• 이미 큐에 있는 값은 무시하고 다른 값들을 "5로 대체한다"를 큐에 추가해요.

이벤트 핸들러가 완료된 후에 리액트는 리렌더링을 발생시켜요. 리렌더링 동안 리액트는 큐를 처리해요. 업데이터 함수는 렌더링을 하는 동안 실행하기 때문에 업데이터 함수는 순수해야만 하고 결과만을 반환 해야해요. 업데이터 함수 안에서 상태를 설정하지 마세요. 만약 이를 지키지 않는다면 사이드 이펙트가 발생해요. 엄격한 모드에서 리액트는 실수를 찾기 위해 각각의 업데이터 함수를 두 번 실행해요. (하지만 두 번째 결과는 무시해요.)

---

Naming conventions | 네이밍 컨벤션

업데이터 함수의 인자를 해당 상태 변수의 첫 글자로 이름 짓는 것은 흔한 패턴이에요.

setEnabled(e => !e);
setLastName(ln => ln.reverse());
setFriendCount(fc => fc * 2);

 

만약 조금 더 상세한 코드를 선호한다면 setEnabled(enabled => !enabled)와 같은 상태 변수 전체 이름을 반복하는 것이나 seEnabled(prevEnabled => !prevEnabled)와 같은 접두사를 사용하는 것도 또 다른 흔한 컨벤션이에요.

---

Recap | 요약

• 상태를 설정하는 것은 이미 완료한 렌더링에서 변수를 바꾸지 않고 새 렌더링을 요청해요.
• 리액트는 이벤트 핸들러가 동작을 종료한 후 상태 업데이트를 처리해요. 이를 배칭이라고 불러요.
• 한 이벤트에서 상태를 여러 번 업데이트 하려면 setNumber(n => n + 1) 업데이트 함수를 사용하세요.

---

Challenges | 도전과제

1. Fix a requset countr | 요청 카운터 고치기

사용자가 동시에 여러 예술품을 주문할 수 있는 예술품 시장 앱을 만들고 있어요. 사용자가 "Buy" 버튼을 누를 때마다 "Pending" 카운터는 1씩 증가해요. 3초 후에 "Pending" 카운터는 감소해야하고 "Completed" 카운터는 증가해야해요.

그러나 "Pending" 카운터는 의도한 대로 동작하지 않아요. "Buy"를 누르면 (나오면 안되는 수인) -1로 감소해요. 그리고 만약 빠르게 두 번 누르면 두 카운터는 예측하지 못한 동작을 해요.

 

왜 이렇게 작동할까요? 두 카운터를 고쳐보세요.

 

Solution

handleClick 이벤트 핸들러 내부에서 pending과 completed 값은 클릭 이벤트가 발생한 시점의 값과 일치해요. 첫 번째 렌더링에서 pending은 0이기 때문에 setPending(pending - 1)은 setPending(-1)이 되고 이는 틀렸어요. 카운터를 증가시키거나 감소시키고 싶다면, 클릭할 때 정해진 고정된 값으로 설정하지 말고 업데이터 함수에 전달하세요.

 

 

이는 카운터를 증가시키거나 감소시킬 때 클릭한 시점의 상태 값이 아니라 마지막 상태 값으로 수행한다는 것을 보장해요.

 

2. Implement the state queue yourself | 상태 큐를 스스로 구현하기

이 도전 과제 에서는 스크래치에서 리액트의 아주 작은 부분을 재구현 할거예요. 어렵지 않아요.

 

샌드박스 미리보기를 스크롤하세요. 4개의 테스트 케이스를 볼 수 있어요. 이들은 이 페이지에서 이미 보았던 예시와 상응하는 테스트 케이스에요. 여러분의 할 일은 getFinalState 함수를 구현하여 각 케이스에서 알맞은 결과를 반환하는 거예요. 만약 알맞게 구현했다면 네 개의 테스트를 통과할 거예요.

 

두 개의 인자를 받을 거예요. baseState는 (0과 같은) 초기 상태이고 queue는 (5와 같은) 숫자와 순서대로 추가된 n => n + 1과 같은 업데이터 함수예요.

 

여러분의 과제는 최종 값을 반환하는 거예요. 이 페이지에서 보여준 줬던 표처럼요!

 

만약 막막하다면 아래의 코드로 시작하세요.

 

export function getFinalState(baseState, queue) {
  let finalState = baseState;

  for (let update of queue) {
    if (typeof update === 'function') {
      // 할 일 : 업데이터 함수를 적용하세요
    } else {
      // 할 일 : 상태를 대체하세요
    }
  }

  return finalState;
}

 

빈 곳을 채워보세요!

Solution

 

이 페이지에 설명된, 리액트가 최종 상태를 계산하는데 사용하는 정확한 알고리즘이에요.

 

 

이제 리액트의 이 부분이 어떻게 작동하는지를 알게 되었어요!