어쩌면 몰라도 되는 리액트 깊숙한 곳의 이야기
출처: https://reactjs.org/docs/design-principles.html#scheduling
컴포넌트가 함수로 작성되어 있을 지라도, 리액트를 사용하면 개발자가 직접 그 컴포넌트를 호출하지 않는다. 모든 컴포넌트는 render 되어야 할 것들의 description을 리턴하고 그 description은 <LikeButton>과 같은 user-written 컴포넌트와 div와 같은 platform-specific 컴포넌트 모두를 포함한다. <LikeButton>를 미래의 어느 시점에 unroll하는것 또는 재귀적으로 컴포넌트들의 render 결과에 따라 UI 트리에 변화를 실제 적용하는 것은 리액트의 책임(up to React)이다.
이는 미묘한 차이이지만 굉장히 강력하다. 개발자가 컴포넌트 함수를 호출하지 않고 리액트에 위임 (let React call it)하는 것은 리액트가, 필요하다면, 호출을 지연시키는 권한을 (has the power) 가지고 있다는 뜻이다. 현재의 리액트 (v.16 이전) tree를 재귀적으로 순회(walk)하고 single tick안에 모든 업데이트된 트리의 render 함수를 호출한다. 하지만 미래에는 리액트가 프레임 드랍을 방지하기 위해 몇몇 업데이트를 지연시키기 시작할 것이다.
이는 리액트 디자인 철학 중 하나의 보편적 주제다. 몇 유명한 라이브러리들은 새로운 데이터가 available 할 때 computation이 실행되는 방식의 'push' implementation으로 접근한다. 하지만 리액트는 연산을 정말 필요할 때 까지 지연시킬 수 있는 "pull" 방식을 고집하고자 한다.
리액트는 generic 데이터 processing 라이브러리가 아니라 유저 인터페이스를 빌딩하기 위한 라이브러리다. 우리는 (리액트팀은) 리액트가 어플리케이션에서 어떤 연산이 비교적 급한지 아닌지 알 수 있기에 유니크한 위치에 있다고 생각한다.
만약 어떤게 offscreen일때, 우리는 연관된 모든 로직을 지연시킬 수 있다. 만약 데이터가 frame rate보다 더 빨리 응답으로 도착한다면, 업데이트를 하나로 합치고 일괄처리 할 수 있다. 또한 프레임 드랍을 방지하기 위해 유저 인터렉션으로 부터 오는 work들의 우선순위를 정할 수 있다: high priority(버튼 클릭으로 인한 애니메이션) to low priority(네트워크로 부터 막 loaded된 컨텐츠를 그리는 일)
정확하게는 현재 이 장점을 살리고 있지 않다. 하지만 이러한 일들을 할 수 있는 자유 떄문에 리액트 팀은 스케쥴링 컨트롤 할 수 있는것을 선호하며, setState()가 비동기로 처리되는 이유이다. 개념적으로 우리는 이것들이 "업데이트를 스케쥴링"하는 것으로 생각한다.
사용자가 직접 Functional Reactive Programming의 일부 변형에서 흔히 볼 수 있는 "push" 기반 페러다임으로 직접 뷰를 구성(compose)하도록 둔다면 스케쥴링을 컨트롤 하는 것은 리액트팀에게 더 힘들것이다. 리액튼 팀은 "glue" 코드를 갖길 원한다.
React로 돌아가기 전에 실행되는 사용자 코드의 양이 최소가 되는 것이 React의 핵심 목표이다.
(아마 리액트가 직접 관여하는 부분이, 개발자의 코드로서보다, 많은 것을 ideal 하다고 생각한다는 뜻인듯?) 이렇게 하면 React가 UI에 대해 알고 있는 내용에 따라 작업을 예약하고 청크로 분할할 수 있는 기능을 유지할 수 있게된다.
There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”.
