React v16.3.0 번역

Haegul Pyun
6 min readApr 4, 2018

--

새로운 라이프 사이클이 추가된 React v16에 관해 공부할 겸 React v16.3.0 Official 문서를 번역했습니다. 이해를 돕기 위해 의역한 부분도 있으므로 참고하여 읽어주시길 바랍니다.

Official Context API

수 년 동안, React는 Context를 위한 실험적인 API를 제공해 왔습니다. API는 강력한 도구임에도 불구하고, 상속문제로 인해 사용이 권장되지 않았습니다. 또 항상 더 나은 API로 대체하려고 했기 때문입니다.

Note:: 오래된 Context API는 마이그레이션을 하기 위한 시간을 필요로 하기 때문에 React 16.x 버전에는 계속 유지될 예정입니다.

다음은 새로운 Context API를 사용하여 “Theme”를 사용하는 방법을 보여주는 예제 입니다.

새로운 context API 에 대해서 배우고 싶으면 여기를 클릭하세요.

createRef API

이전에는 React에선 refs를 관리하기 위해 두가지 방법을 제공했습니다: legacy string ref API와 callback API. lagacy string ref API가 더 편리하지만 두 가지 단점이 있었기 때문에 공식적으로 callback API를 사용하는 것이 더 좋습니다.

16.3 버전에는 string ref API방식의 두가지 단점을 보완한 새로운 ref 관리 방법이 추가되었습니다.

Note:: 새로운 createRef API가 추가되었어도 callback ref API는 계속 지원 될 예정입니다. 여러분의 Components에 있는 callback ref API를 교체할 필요는 없습니다. callback ref API는 더욱 유연한 기능이기 때문에 고급 기능으로 계속 남아있을 예정입니다.

새로운 createRef API에 대해서 배우고 싶으면 여기를 클릭하세요.

forwardRef API

Higher-order components(또는 HOCs)는 일반적으로 컴포넌트간 재사용을 위해이용됩니다. 위에서 언급한 “Theme” Context 예제를 바탕으로 현재 “Theme”를 주입하는 HOC를 만들 수 있습니다.

위의 HOC를 사용하여 ThemeContext를 직접 사용할 필요없이 구성 요소를 ThemeContext에 연결 할 수 있습니다.

HOC는 일반적으로 래핑하고있는 컴포넌트로 props를 전달합니다. 그러나 안타깝게도 refs는 전달할 수 없습니다. 만약 우리가 “FancyThemedButton을 사용할 때, “FancyButton”에 ref를 붙일 수 없다는 것을 의미합니다. 그래서 이 경우 focus() 함수를 호출 할 수 있는 방법이 없습니다.

새로운 forwardRef API는 ref를 props로 전달 할 수 있는 방법을 제공함으로써 이 문제를 해결하고 있습니다.

Component Lifecycle Changes

React 클래스 컴포넌트의 API들은 몇년간 조금씩 변화해오고 있습니다. 그러나 몇가지 고급 기능을 추가하면서(예를들면 error boundaries 또는 곧 추가될 async rendering mode) 설계 모델이 의도하지 않은 방향으로 확장되고 있었습니다.

예를 들면, 현재 API에서는 필수적이지 않은 초기 렌더링을 차단하기가 너무 쉽습니다. 부분적으로 주어진 task를 완료하는데 너무 많은 방법이 제공되어서 어떤 방법이 최적의 방법인지를 찾기가 쉽지 않습니다. 오류를 처리할 때 발생하는 인터럽트는 고려되지 않았으며 메모리 누수가 발생할 수 있다는 것을 인식했습니다. (이것은 향후 async rendering mode에 영향을 미칠 수 있습니다.) 또한 현재 클래스 컴포넌트 API는 React Compiler Prototype 작성과 같은 작업을 복잡하게 만듭니다.

이러한 많은 이슈들은 컴포넌트 생명주기(Component lifecycle) 중 componentWillMount, componentWillReceiveProps, ComponentWillUpdate에 의해 발생하게 됩니다. 이들은 또한 React 커뮤니티에서 가장 혼란을 일으키고 있는 lifecycle이기도 합니다. 이러한 이유로 더 나은 방법을 제공하기 위해 위 method들은 deprecate될 예정입니다.

이 변화가 기존 구성 요소에 많은 영향을 미친다는 것을 알고 있습니다. 때문에 마이그레이션은 가능한 한 점진적으로 진행하여 천천히 개선할 수 있게 제공할 예정입니다.(페이스북에서는 50000개 이상의 컴포넌트들이 유지되고 있습니다. 우리 또한 영향을 받고 있습니다.)

Note:: 16.x버전에서는 deprecation warning이 나타날 예정입니다. 그러나 legacy lifecycle들은 17 version까지 여전히 작동할 예정입니다.

17 version에서도 계속 사용할 수 있지만 문제가 발생할 수 있음을 나타내기 위해서 “UNSAFE_” prefix가 지정됩니다. 또한 자동으로 이들을 바꿀 수 있는 스크립트도 준비하고 있습니다.

추가로 unsafe lifecycle들 대신에 우리는 새로운 lifecycle들을 제공하고 있습니다.

  • getDerivedStateFromProps는 componentWillReceiveProps의 대안으로 추가되었습니다.
  • getSnapshotBeforeUpdate는 안전하게 property들(예를들면 update로 인해 만들어지기전 DOM으로 부터)을 읽을 수 있도록 제공하고 있습니다.

새로운 lifecycle에 대해서 배우고 싶으면 여기를 클릭하세요.

StrictMode Component

StrictMode는 응용 프로그램의 잠재적인 문제점을 파악하기 위한 도구입니다. 그러나 Fragment, StrictMode는 가시적으로 보이는 UI가 없습니다. 이들은 추가적인 확인을 위한 경고들을 활성화 합니다.

Note:: StrictMode는 개발 환경에서만 동작합니다. Production build에는 영향을 미치지 않습니다.

StrictMode가 모든 문제를 해결할 순 없지만, 여러가지로 도움이 될 수 있습니다. 만약 당신이 strict mode에서 경고창을 보게 된다면 async rendering에 대한 버그를 발견할 수 있을 것입니다.

16.3 version에서는 다음과 같은 내용이 도움이 될 것입니다.

  • 안전하지 않은 lifecycle에 대한 식별
  • legacy string ref API를 사용할 때 경고
  • 예상하지 못한 부작용(side effect)들을 탐색

React의 향후 릴리즈에는 더 많은 기능이 추가 될 예정입니다.

StrictMode 구성 요소에 대한 자세한 내용은 여기를 참고하세요.

React v16.3.0에서 가장 주목할만한 부분은 lifecycle API의 변화인 것 같습니다. async rendering mode에 대해서도 여러번 언급한 만큼 이 기능이 향후 React를 선택하게 되는 강력한 기능이 되지 않을까 조심스럽게 생각해 봅니다.

--

--