반응형

Recoil 배경

Recoil은 Facebook이 만든 상태관리 라이브러리로

리액트의 상태관리를 위해 만들어진 라이브러리다.

매우 React스러운 Recoil에 대해 알아보자.

 

Recoil 구성요소

Recoil은 크게 2가지 요소로 나뉜다.

Atom과 Selector

 

Atom은 상태의 단위로, 상태를 정의하거나 불러올 수 있다.

Atom이 업데이트 되면 Atom을 구독하는 컴포넌트들이 업데이트된다.

Atom은 고유한 key와 default 값을 갖는 객체로 구성된다.

const phoneState = Atom('UserPhone', {
  key: 'Phone',
  default: ''
});

const [phone, setPhone] = useRecoilState(phoneState);
// const phone = useRecoilValue(phoneState);
// const setPhone = useSetRecoilState(phoneState);

useEffect(() => {
  getUserPhone()
}, [])

const getUserPhone = async () => {
  const { data } = await axios.get(uri);
  setPhone(data);
}

 

Selector는 고유한 key와 get과 set으로 구성되어 순수 함수로써 동작한다.

순수함수로써 동작한다는 것은 같은 입력이 주어진다면 항상 같은 결과를 반환해야 한다는 것이다.

내부의 다른 요소로 인해 결과가 바뀌는 등의 상황이 없어야 한다는 것.

const phoneState = Atom('UserPhone', {
  key: 'Phone',
  default: ''
});

const getPhoneSelector = () => selector({
  key: 'UsePhone',
  get: async ({ get }) => {
    try {
      const { data } = await axios.get(uri);
      return data;
    } catch(error) {
      throw error;
    }
  },
  set: ({ set }, newValue) => {
    set(phoneState, newValue);
  }
})

반드시 비동기 요청을 위해 쓸 필요는 없지만

위와 같이 비동기 요청을 위해 사용할 수 있다.

 

비동기 요청 로직을 분리하여

요청 후 결과를 atom에 set하는 형태를 갖출수도 있지만,

selector를 이용해  응집도를 높일 수 있다.

 

뿐만 아니라, selector는 캐싱 기능이 있다.

캐싱 기능의 장점은 이미 받아왔던 값을 기억하고 있어

같은 응답을 보내는 api call에 대해서는 추가적으로 요청하지 않아

성능적으로 훨씬 유리하다.

 

* 캐싱과 관련해 주의할 부분

사용자가 항상 최신의 데이터를 확인해야 하는 화면에서

캐싱 기능은 데이터 무결성을 초래하는 위험 요소가 될 수 있다.

따라서, 항상 최신의 데이터를 확인해야 할만한 상황에 대해서 미리 파악 해두어야한다.

예를들어

  - 사용자가 화면을 보고있을 때

  - 페이지가 전환되며 새 페이지에 진입했을 때

  - 페이지 전환없이도, 무언가 추가적인 데이터를 요청할 때

등이 있을 수 있다.

이러한 상황 외에는 적극적으로 캐싱 기능을 활용한다면

자원을 아끼고 효율을 높일 수 있을 것이다.

Recoil 비동기 처리?
Recoil에서도 비동기 요청 처리에 있어

Redux에서 처럼 error, loading 등의 상태를 확인할 수 있을까?

selectoruseRecoilValudLoable을 함께 쓴다면 가능하다.

 

const phoneLoadable = useRecoilValueLoadable(getPhoneSelector);

phoneLoadble.state
// hasValue, hasError, loading 세가지의 현재 상태를 갖음

phoneLoadable.contents
// hasValue 상태 일때: value 정보
// hasError 상태 일때: error 정보
// loading 상태 일때: Promise

 

참고1

참고2

반응형
반응형

React 개발을 하다보면

state, props로는 depth가 너무 깊어지는

props drilling문제가 발생하는 시점이 온다.

 

또한,

단계별 진행이나 페이지 변경 후에도 상태를 유지해야 하는 List뷰 등에서

어려움을 겪게된다.

 

이러한 문제들을 해결해주는 것이

global state관리를 도와주는 라이브러리들이다.

그 중에서 local global state라고 부르도록 하겠다.

 

주요 상태관리 라이브러리

1. Context API

2. Recoil

3. MobX

4. Redux

 

위 4가지 정도가 있는데,

1에서 4로 갈수록 러닝커브가 높다고 생각하는 바이다.

그럼에도 각 장,단점이 있으니 알아보도록 하자.

 

1. Context API

ContextAPI는 4가지 중에 유일하게
React 내장 상태관리 기능이다.

즉, 별도의 라이브러리 설치 없이 사용 가능하다는 말이다.

 

Docs를 보고 처음 사용 하는 사람도
쉽게 적용할 수 있는 수준이니

러닝커브 또한 낮다고 할 수 있다.

 

ContextAPI가 처음 나왔을때는

언어설정이나 색상테마 등

잘 변경되지 않는 상태를 관리할때 쓰였다.

 

그러나 지금은

전역상태 관리로 사용하던

지역상태 관리로 사용하던

개발자의 자유일뿐

상태 관리 기능으로써 충분한 지원을 하고있다.

 

참고

 

그럼에도 다른 라이브러리들을

추가 설치해 사용하는 이유가 있다.

 

 

2. MobX

언급할 내용은 MobX뿐 아니라

Redux, Recoil등 다른 라이브러리들을

사람들이 사용하는 이유이다.

 

4가지 모두 상태관리라는 컨셉을 가지고 있지만 그 안에서 나뉘는 개별 특징들이 있다.

그중에 내게 맞는 특징을 갖는 라이브러리를 택하면 되는것이다.

 

MobX는 전역상태관리 기능을 제공한다.

뿐만 아니라 상태 업데이트 로직을 View Component 밖에서(코드 분리) 할 수 있도록 도와준다.

Redux에 비해 적은 보일러 플레이트 코드, 직관적인 코드를 갖는다는 특징도 있다.

 

다만, MobX에서는 여러개의 Store를 둘 수 있는데

그로인해 예상치 못한 업데이트 등이 발생할 수 있다는 단점아닌 단점이 있다.

 

3. Redux

Redux도 MobX와 마찬가지로

전역상태관리 + 상태 업데이트 로직 분리를 돕는다.

 

하나의 Store를 갖는 특징으로

상태가 업데이트 될때 정확하게(직관적으로)

해당하는 상태를 갖는 컴포넌트들만 업데이트 된다는 장점이 있다. (유지보수의 편안함)

 

다만, Redux는 비동기 처리를 위해

thunk, saga 등 추가적으로 라이브러리들이 붙게되고

보일러플레이트 코드가 너무 많아진다는 단점을 가지고 있다.

 

4. Recoil

최근 각광받고 있는 Recoil은

react를 개발/운영하고 있는 Facebook(Meta)에서 개발한 만큼

가장 react 친화적이라는 장점을 가지고있다.

뿐만 아니라 매우 사용 방법이 매우 간단하고 직관적이다.

 

ContextAPI가 상태를 일일이 만들어야 하는 과정을 가진데 반해

Atom을 통해 매우 간결하게 상태관리를 할 수 있다.

캐싱을 통한 최적화 기능은 보너스이다.

 

 

 

최근,

이직 준비를 하며 많은 기업들에서 Recoil을 도입하고 있는것을 보게되었다.
사이드 프로젝트에 적용해 공부중인데 매우 합리적인 선택지라는 생각이 든다.

 

현직 개발자들은 대부분 현명하고, 최선의 선택을 하기위해 노력하는 만큼

Recoil이 사랑받는데는 분명히 이유가 있다.

 

 

 

(수정할 사항이 있다면 자유롭게 알려주세요. 저에게 큰 도움이 됩니다.)

반응형