Next.js에서의 상태관리

일반적으로, next.js에서 사용한다고 해서 특별하게 더 효율적이거나 자주 사용하는 상태관리 라이브러리가 있는 것은 아닌 모양이다. 그도 그럴 것이, Next로 만든 어플리케이션이라고 해도, 그 내부는 대부분 react 컴포넌트로 구성되어 있어 react에서 사용하던 상태관리 라이브러리를 대부분 그대로 사용해도 문제가 없기 때문일 것이다. 주로 사용하는 라이브러리는 다음과 같다.

Redux

Recoil

Jotai

Zustand

Redux

상태관리로 가장 많이 사용
중심화된 store에서 통합적으로 state 관리(Top-down 방식)
다소 복잡한 구조(action, reducer, selector, store, ...)
Redux Toolkit으로 조금 더 간단하게 사용 가능하긴 함

Recoil

atom 형태로 기능별(혹은 원하는 기준)로 나눠 global state를 관리(Bottom-up 방식)

Jotai

atom 형태로 기능별(혹은 원하는 기준)로 나눠 global state를 관리(Bottom-up 방식)
Recoil과 아주 비슷
Recoil에 비해 활발한 업데이트 진행중, 조금 더 간단한 구조(atom에 key 설정할 필요 X)

Zustand

jotai 개발진이 만들어 jotai와 유사
중심화된 store에서 통합적으로 state 관리(Top-down 방식)

비교

러닝커브

Redux > Recoil > Jotai == Zustand
트렌드(npm 다운로드 수)

Redux > Zustand > Recoil > Jotai
방향성

Top-down: Redux, Zustand Bottom-Up: Recoil, Zustand

상태관리 라이브러리의 필요성

그렇다면, 이번 프로젝트에서 위와 같은 (전역)상태관리 라이브러리가 필요한지 따져보았다.

전역으로 관리해야 할 상태가 있는가?

크게 없다고 생각한다. Glee는 SNS + Messanger 서비스를 제공한다. 따라서, FE에서 서버에 저장된 데이터를 fetching하고, 실시간 소통하는 기능을 구현하는 것이 핵심이다. 이 때, 서버 데이터의 state나 실시간 통신은 React-Query와 Socket 라이브러리(미정)를 통해 진행할 예정이다. 그 이외의 부수적인 기능을 위해 따로 상태관리 라이브러리를 사용하는 것은 과투입일 수 있다.
상태관리 라이브러리를 대체할 수 있는 방법이 있나?

지금까지 기획된 Glee의 기능에서 사용될 state들은 react hook인 useState로도 충분히 관리할 수 있을 것이라고 생각한다. 서버사이드 렌더링을 사용하는 이유가 서버 차원에서 대부분의 렌더링을 끝내 클라이언트 측에서의 로딩을 줄이는 것이라고 생각하는데, 너무나 많은 state(특히, 전역 state)를 사용하여 지속적으로 re-rendering을 발생시킨다면 SSR의 장점을 상쇄시키는 것이라고 생각한다. 또한, next에서는 url의 쿼리 스트링을 통해서 필요한 상태를 기록해두는 형태도 많이 사용하고 있고, 만약, 리렌더링 이후에도 보존되어야 할 데이터가 있다면 local storage나 cookie에 저장해도 될 것이다.

만약 사용한다면?

간단하게 찾아봤을 때, next에서 특히 뛰어난 성능을 보이는 상태관리 라이브러리는 따로 없는 것 같아 위의 라이브러리 중 하나를 고르면 될 것 같다. Recoil과 Jotai는 atomic하게 나뉘어 상태를 관리하기 때문에 useState로도 충분히 대체할 수 있을 것이라고 생각한다. 따라서, 전역 상태관리가 필요하다면 Redux나 Zustand 사용하면 좋을 것 같고, 개인적으로는 최근에 떠오르고 있고, 비교적 러닝커브가 낮은 Zustand를 사용해보면 좋을 것 같다.

Reference

상태관리 라이브러리 비교 https://velog.io/@wjdwl002/React-%EC%83%81%ED%83%9C%EA%B4%80%EB%A6%AC-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC-%EB%B9%84%EA%B5%90%EB%B6%84%EC%84%9D-Redux-Recoil-%ED%8E%B8

Jotai VS Zustand https://programming119.tistory.com/263

상태관리 라이브러리

Redux

React의 특성인 단방향 바인딩이 추구하는 Flux 패턴

패키지 크기가 크고 보일러 플레이트 코드도 복잡해서 지금 하는 프로젝트에는 안맞을거 같음

Recoil

Atomic 패턴 상태관리 라이브러리 상태관리할 데이터가 쪼개진 하나의 단위를 atom이라 하고 각 컴포넌트가 이를 구독하는 방식.

Redux에 비해 굉장히 쉽고 러닝커브가 낮음.
React 전용 라이브러리이기 때문에 높은 호환성을 보임

Jotai

Recoil와 같은 atomic 패턴의 상태관리 라이브러리. Context의 리렌더링 문제 해결을 위해 만들어진 React 특화 상태관리 라이브러리(리렌더링에 대한 최적화 good) bottom-up으로 상태는 atom으로 구성되고, 원자들 사이에서 서로 결합 및 상태에 관여가 가능 Recoil과는 달리 atom에 unique key가 필요없음(보일러 플레이트 코드 감소)

사용방법이 굉장히 심플하고 패키지 사이즈가 작음.
타입스크립트 중심이기 때문에 타입스크립트 환경에서 우수한 DX 제공.
중~대 규모의 앱에 권장. 작은 상태들을 대량으로 읽거나 쓰는 성능 중심 앱의 경우 적합.
다른 라이브러리들에 비해 참고할만한 문서나 소스가 많지 않음.

Zustand

Redux와 같은 Flux 패턴의 상태관리 라이브러리.(단순화된 Flux 패턴) 상태가 하나의 객체이다.(top-bottom) 따라서 하나의 단일 스토어를 가진다.(여러개의 개별 저장소를 만들수는 있음) Context Provider로 감쌀필요 없음. 렌더링 최적화는 selector를 사용해서 수동으로 적용해야함.

핵심 로직 코드수가 적어서 사용이 간편하고 코드양도 적음.
큰 규모의 앱에 권장. 대부분의 앱에 적합하다. 
우리에게 친숙한 Top-down 방식으로 여러개의 스토어를 도메인 단위로 쪼개서 쉽게 관리 가능.

Context API

React에서 자체적으로 제공하는 툴.

아주 심플
상태가 변경될 때마다 해당 Context를 사용하는 모든 컴포넌트를 리렌더링하는 성능 문제 발생
규모가 작고 복잡도가 낮은 앱에 적합

Jotai 공식문서에서 추천하는 상태관리 라이브러리

NPM trend

향후 확장성 & 스터디를 위해서 Jotai, Zustand 중에서 하나를 사용하는 것이 좋아보임. 서비스가 많이 복잡할거 같지는 않아서 러닝커브는 비슷하지 않을까... Zustand + immer + ReactQuery 조합이 좋다는 글을봤는데 한번 봐야할거같아요

참고 문서

https://react-redux.js.org/introduction/getting-started https://recoiljs.org/ko/docs/introduction/getting-started https://jotai.org/ https://docs.pmnd.rs/zustand/getting-started/introduction

https://devblog.kakaostyle.com/ko/2022-01-13-2-jotai-recipe/ https://leetrue-log.vercel.app/recoil-jotai-zustand

Cling-Glee / glee-front

상태관리 라이브러리 서치 #2