프로젝트에 대한 질문으로 Recoil을 왜 썼는지,
Recoil로 가능한 부분이 Context로 할 수 있는 건 아닌지에 대한 질문을 받았다.
생각해보니 Recoil로 구현하려는 부분은 context로 구현이 가능했다.
그렇다면 사람들은 왜 recoil을 쓰는 것인지 궁금해서 둘의 차이를 찾아봤다.
React Context
리액트에서 기본으로 제공하는 api는 props drilling을 해결하기 위한 가장 간단한 방법이다.
provider로 app을 감싸고 consumer를 통해 하위 컴포넌트에 상태를 전달할 수 있다.
간단한만큼 단점이 존재하는데 바로 불필요한 랜더링이다.
context는 상태값이 달라지면 구독하고 있는 하위 컴포넌트가 모두 다시 랜더링이 된다.
object는 식별자가 달라지기만 해도 렌더링이 일어나기 때문에 더욱 관리가 어렵다.
만약 단순히 props drilling 해결이 목적이고,
랜더링 최적화가 필요없는 상태(테마, 나이트모드)라면 Context로 충분히 해결할 수 있다.
아래는 공식문서 설명이다.
- context를 사용하면 컴포넌트를 재사용하기가 어려워지므로 꼭 필요할 때만 써야한다.
- Provider 하위에서 context를 구독하는 모든 컴포넌트는, Provider의 value prop가 바뀔 때마다 다시 렌더링 된다. Provider로부터 하위 consumer(.contextType와 useContext을 포함한)로의 전파는 shouldComponentUpdate 메서드가 적용되지 않으므로, 상위 컴포넌트가 업데이트를 건너 뛰더라도 consumer가 업데이트된다.
Recoil
Recoil은 페이스북에서 만든 상태관리 라이브러리로, 다음과 같은 장점을 가지고 있다.
-
적은 코드량, 쉬운 러닝 커브
Recoil은 상태 하나를 atom으로 정의하고, 그것을 구독하는 방식이다.
또한 이런 atom들로부터 파생된 상태를 selector로 선언한다.
이 selector들은 구독한 atom이 변화하면 자동적으로 변화한다.
데이터 흐름이 직관적이며, useState와 비슷하여 쉽게 배울 수 있다. -
렌더링 최적화
Context에서는 상태변경시 구독한 하위 컴포넌트들이 모두 재렌더링 되는 문제가 있었는데, Recoil은 atom, selector를 구독하면 구독한 컴포넌트만 재렌더링이 일어난다. Redux useSelector로 일일히 최적화 해주던일을 굉장히 쉽게 실현할 수 있다. -
간편한 비동기 처리
Redux에서는 추가적인 api로 구현되었던 비동기 처리나 캐싱을 selector로 지원한다.
에러처리도 리액트의 suspense를 사용할 수 있고, useRecoilValueLoadable을 사용한다면, hasValue, loading, hasError 상태를 제공해서, 로딩완료시, 로딩시, 에러시 처리가 손쉽게 가능하다.
