[번역] 리액트의 스케줄링 (Pull 방식 vs Push 방식)

 

이 글은 리액트의 디자인 원칙 중 '스케줄링' 부분을 의역한 글입니다.

 

함수 호출은 리액트가 한다.

리액트 컴포넌트를 함수로 표현하긴 하지만, 리액트가 그 함수들을 즉시 호출하는 것은 아니다. 

<LikeButton>과 같은 컴포넌트의 변경사항을 어느 시점에 재귀적으로 UI트리에 실제로 변경사항을 적용을 할지는, 순전히 리액트의 마음이다. 이는 미묘한 차이지만 큰 의미를 갖는다. 리액트 사용자가 직접 컴포넌트 함수를 호출하는 것이 아니라, 리액트가 이를 호출하기 때문에 필요할 경우 리액트는 함수 호출을 지연시킬 수 있다.

 

리액트는 pull 방식을 따른다.

많은 라이브러리에서는 새로운 데이터를 반영하기 위해 Push 방식을 사용하지만, 리액트는 꼭 필요한 때가 아니면 이를 지연시킬 수 있는 Pull 방식을 사용한다.

리액트는 범용적인 데이터 처리 라이브러리가 아니라, UI를 만들기 위한 라이브러리다. 화면에 표시되지 않고 있다면, 관련 로직은 지연시켜도 될 것이다. 혹은, 데이터가 프레임속도보다 일찍 도착해버렸다면, 일괄 업데이트를 처리해 줄 수 있다. 이처럼, 리액트는 유저 인터랙션으로부터 발생하는 작업들의 우선순위를 더 높게 설정하고, 덜 중요한 백그라운드 작업들은 더 낮게 설정해서 프레임이 떨어지는 것을 방지할 수 있다.

 

리액트는 스케줄링을 통해 UI를 업데이트한다. 

이런 자유도를 위해서 리액트는 스케줄링에 대한 제어권을 가지려고 하고, setState를 비동기로 처리하는 것이다. 개념적으로 리액트에서는 이를 "업데이트를 스케줄링"하는 것이라고 본다. 만약 사용자가 push방식으로 화면을 업데이트할 수 있는 방식이라면, 리액트에서 스케줄링에 대한 제어권을 갖는 것은 쉽지 않을 것이다.

리액트로 돌아가기 전 사용자의 코드가 수행되는 것을 최소화하는 것이 리액트의 핵심 목표이다. 이는 리액트가 UI에 대해 파악하고 있는 것을 바탕으로 작업을 스케줄링하고 청크로 분할하는 능력을 유지하기 위함이다.

리액트가 완전히 reactive한 것이 아니기 때문에 Schedule이라고 이름을 붙였어야 했다는 팀 내의 농담도 있다.

 

React is not fully reactive - Dan Abramov

 

참고자료

[React - Design Principles: Scheduling]