이 글은 setState가 왜 비동기 인가를 알아보다가 아래와 같은 글이 있어서 이해한 내용만 정리한 글입니다. 아래 글을 모두 번역하지 않았음을 알립니다.
https://github.com/facebook/react/issues/11527
브라우저 클릭 핸들러에 있고 Child 및 Parent 호출 setState 모두에있는 경우 Child를 두 번 다시 렌더링하지 않고 더티로 표시 한 다음 브라우저 이벤트를 종료 전에 다시 렌더링하는 것을 선호합니다.
왜 재조정을 기다리지 않고 setState를 즉시 업데이트 하면서 배치 (일괄작업) 이랑 똑같은 일을 할 수 없는지 물을 것입니다.
내부적으로 일관성을 보장해야 한다
state가 동기적으로 업데이트 된다고 했을때 props는 그렇지 않습니다. 부모 컴포넌트가 렌더링이 될때까지 props 값을 알 수 없습니다.
상태를 몇 개의 구성 컴포넌트에서 공유하려면 상위 상태로 이동해야합니다.
-this.setState({ value: this.state.value + 1 });
+this.props.onIncrement(); // Does the same thing in a parent
자식 컴포넌트에서 다음과 같은 코드가 있다고 했을 때,
console.log(this.props.value) // 0
this.props.onIncrement();
console.log(this.props.value) // 0
this.props.onIncrement();
console.log(this.props.value) // 0
부모를 다시 렌더링하지 않고 즉시 this.props를 플러시 할 수 없습니다. 이럴 경우 일괄처리를 할 수 없습니다.
즉, 위 코드가 정상적으로 동작하려면 onIncrement() 시마다 부모가 호출되어야 하고 이 경우에는 부모가 2번이나 호출이 되어야 한다는 것이다. 그럼 경우에 따라 성능 저하가 일어날 수도 있을 것이다.
그래서 React는 this.state, this.props 업데이트는 오직 reconciliation 이후에 진행됩니다. 이것은 state를 안전하게 부모로 올릴 수 있습니다.
동시성 있게 업데이트가 가능해야 한다
"비동기 렌더링"을 설명하는 한 가지 방법은 React가 이벤트 처리기, 네트워크 응답, 애니메이션 등의 발신 위치에 따라 setState () 호출에 다른 우선 순위를 할당 할 수 있다는 것입니다.
예를 들면 타이핑 할 시에, TextBox에 있는 setState() 호출은 즉시 반영이 되도록 필요합니다. 하지만 타이핑시에 새로운 메시지를 받았다고 가정했을때 새로운 new MessageBubble 을 렌더링 하는것을 특정 임계값 까지 지연시키는 게 쓰레드 블락으로 인해 타이핑이 버벅거리는것 보다 아마 나을 것입니다.
특정 업데이트가 "낮은 우선 순위"를 갖도록하면 렌더링이 몇 밀리 초의 작은 덩어리로 분할되어 사용자에게 눈에 띄지 않게 될 수 있습니다.
비동기 렌더링은 단지 성능 때문만은 아닙니다.
예를 들면 화면전환을 생각해 봅시다. 이때 새로운 스크린이 렌더링 되는동안 스피너가 돈다고 생각해봅시다.
충분히 네비게이션이 빠르다면 스피너는 즉시 사라지는 깜빡임 현상이 나타날 것입니다. 이것은 사용자 경험상 안좋은 경험이 될 수 있습니다.
만약 다른 비동기 의존성을 지닌 여러 레벨의 컴포넌트를 가지고 있다고 했을때 스피너는 한 번에 하나씩 짧게 깜박이는 일련의 스피너로 끝납니다.
이것은 시각적으로 불쾌하며 모든 DOM 리플 로우로 인해 앱 속도가 느려집니다.
조정 코드를 직접 작성하지 않고 업데이트가 특정 임계 값 (예 : 1 초)을 초과 한 경우 스피너를 표시하도록 선택하고 그렇지 않으면 완전히 새로운 하위 트리의 비동기 종속성이 발생할 때 React가 완벽한 전환을 수행하도록 할 수 있다고 상상해보십시오.
또한 기다리는 동안에 이전 화면을 유지 합니다.
이 말은 즉, ui의 업데이트를 일관성 있게 한다는 뜻인거 같습니다. 일관성없는 UI를 피하기 위해 백그라운드에서 만들어지고 한번에 업데이트 한다.