on
상태 관리 도구 비교
Context Api
일반적인 React 애플리케이션에서 데이터는 위에서 아래로 (즉, 부모로부터 자식에게) props를 통해 전달되지만, 애플리케이션 안의 여러 컴포넌트들에 전해줘야 하는 props의 경우 (예를 들면 선호 로케일, UI 테마) 이 과정이 번거로울 수 있습니다.
이렇게 Props가 자식의 자식의 자식을 거쳐 계속 내려가는 현상을 Props Drilling이라고 한다.
하지만 이럴 때 context를 이용하면, 트리 단계마다 명시적으로 props를 넘겨주지 않아도 많은 컴포넌트가 이러한 값을 공유하도록 할 수 있습니다.
Redux
Redux 공식문서보러가기
위의 Context Api를 기반으로 만들어진 상태관리도구이다. 한 마디로, 리덕스는 ‘전역 상태’를 생성하고 관리하기 위한 라이브러리라고 볼 수 있습니다. 이렇게만 보면 Context Api와 크게 차이가 없어 보이지만 아래와 같이 몇가지 장점이 있습니다.
redux-saga, redux-thunk, redux-devtools 등 다양한 추가 라이브러리를 통해 우리가 조금 더 상태 관리를 수월하게하고 긴밀하고 정확한 코딩을 할 수 있도록 합니다. 여러 라이브러리가 모여 Redux라는 하나의 프레임워크가 되어 개발자에게 큰 도움을 주고 있는 것으로 볼 수 있습니다. 하지만 Context API는 이런 부가적인 기능을 제공하지 않아 다른 라이브러리를 통해 구현해야합니다.
Mobx
Redux와 마찬가지로 상태관리 라이브러리이다. 하지만 Redux보다 장점을 보이는 부분이 있습니다.
객체지향적
보다 객체지향적입니다 ES6에서 추가된 Class를 이름뿐인 Class가 아니라 객체지향적으로 사용하고 개발하는 것을 권장하고 있습니다.
도메인모델로 분리됨으로 써 집중된 비즈니스 로직은 적절히 분산되고 도메인간의 상호작용은 message를 주고 받는 형태로 구현 할 수 있습니다.
서버개발자들에게 친숙한 아키텍쳐
Java Spring Framework와 유사한 아키텍쳐구조를 지향하고 있어 서버개발자들에게 보다 친숙하고 낮은 러닝커브를 제공, 장점을 그대로 적용할 수 있습니다.
SWR
SWR 공식사이트 보러가기
SWR은 데이터를 가져오는데 특화된 라이브러리이다. 위의 redux등과는 조금 성격이 다르다고 할 수 있다. axios와 비교했을 때 몇가지 장점이 있는데 아래와 같다.
-
axios는 한 번 get으로 호출을 하면 다시 호출하지 않는 이상 이전의 데이터를 그대로 유지한다. 반면
swr은 최초 한 번만 호출해도 다른 곳으로 포커싱을 옮겼다가 다시 포커싱하면 새로운 데이터로 갱신된다. -
주기적인 호출이 쉽다. axios를 사용할 때는 setInterval 등을 통해 주기적으로 api를 호출하는 수밖엔 없었지만 swr은 간단하게 이러한 기능을 제공한다. 사용자의 설정에 따라 원하는 순간에 revalidate할 수도 있고 일정 시간 간격으로 revalidate할 수도 있다. -
캐시된 데이터를 이용한다. 만약에 데이터를 가져오는 데 오래 걸리는 호출이 있다고 가정하자. 한 5초 정도? 그럼 해당 페이지를 들어갈 때마다 axios는 5초동안 데이터를 가져올 것이다. 하지만 swr은 최초에 데이터를 수집한 후에는 계속해서 오래 걸리는 호출 방식을 고수하는 것이 아니라 캐시된 데이터를 이용해서 효율적인 동작을 만들어낸다. 물론 캐시 이후에는 자동적으로 revalidate하여 데이터의 일관성을 유지해준다.