💾 pre 스택오버플로우 클론 / 전역 상태관리를 왜 하는지 알겠어요(상태관리 라이브러리, Recoil 도입)

 

🐖 Piggy 프로젝트와 '상태관리'

piggy 프로젝트를 하며 상태관리 라이브러리의 필요성을 절감했다.

사실 piggy는 그야말로 뭐라도 해보려고 시작한 프로젝트라서, 최소한의 컴포넌트(딱 CRUD만)로 구현하려 했다.

그래서 props, state만 써도 충분할 줄 알았다.

하지만... 팀프로젝트가 되고, 나름 애정이 생기고, 유저플로우를 생각하다보니 생각보다 컴포넌트가 아주 많이 늘어났다.

게다가 나중에 로그인 기능도 추가했고, 이렇게 페이지와 기능이 늘다보니 데이터 요청도 늘어났다.

이 과정에서 우린 props, state 지옥을 경험했다.

 

 

 

💡 상태관리 라이브러리 도입

처음 Pre 프로젝트를 시작할 때는 상태관리 라이브러리를 쓸 생각은 없었다.

하지만 로그인 구현부터 직감했다. 안하면 큰일 나겠구나.

그래서 상태관리 라이브러리를 쓰기로 했고, Redux냐, Recoil이냐를 두고 고민했다.

 

 

 

🌟 Redux vs Recoil

Redux

React처럼 단방향 데이터 흐름 패턴을 따른다.

상태가 언제나 예측 가능하고 변화를 추적하기 쉬워서 애플리케이션의 상태 변화를 관리하는 데에 용이하다.

 

Redux의 핵심 개념

• Store: 애플리케이션의 상태를 단일 객체로 저장하는 저장소
  상태를 관리하고 상태가 변경되면 이벤트를 발행하여 관련 컴포넌트들이 새로운 상태를 받아 업데이트할 수 있도록 한다.
• Action: 애플리케이션에서 발생하는 어떠한 이벤트를 나타내는 객체
  Action은 일반적으로 JavaScript 객체이며, 반드시 "type"이라는 필드를 포함해야 한다. Action은 상태를 변경하는 요청으로 사용된다.
• Reducer: Action에 따라 상태를 변경하는 함수
  이전 상태와 Action을 받아 새로운 상태를 반환한다. 이때 Reducer는 불변성을 유지하여 기존 상태를 직접 수정하지 않는다.
• Dispatch: 액션을 발생시키는 메서드로, 상태를 변경하기 위해 액션을 Store에 보내는 역할
• Subscribe: 상태 변화를 감지하고, 상태가 변경될 때마다 등록된 콜백 함수를 호출
  이를 통해 UI 컴포넌트가 상태 변화를 인지하고 새로운 상태를 반영할 수 있다.

리덕스의 작동 방식은 '예측 가능'하다.

단일 상태 트리를 사용하므로 애플리케이션의 상태 변화를 추적하기 용이하며, 디버깅과 테스트에도 편리하다.

따라서 복잡한 상태 관리를 필요로 하는 애플리케이션에 적합함.

 

Recoil

리코일(Recoil)은 Meta(구 Facebook)에서 개발한 상태 관리 라이브러리로, React 애플리케이션의 상태를 관리하는데 사용된다. 리덕스와 비슷한 역할을 수행하지만, 리덕스보다 더 간편하고 직관적인 API를 제공한다.

• 상태(Atom): 상태는 "Atom"이라고 불리는 단위로 관리됨
  Atom은 읽기 및 쓰기가 가능한 상태를 나타내는 것으로, React 컴포넌트에서 사용되는 데이터입니다. Atom은 일반적으로 JavaScript 변수와 유사하며, atom 함수를 사용하여 생성한다.
• 선택자(Selector): 선택자는 하나 이상의 Atom에서 파생된 값을 반환하는 함수
  이를 통해 여러 상태를 조합하거나 변형하여 새로운 값으로 만들 수 있다.
• RecoilRoot: Recoil로 관리되는 상태를 사용하기 위해 컴포넌트의 계층 구조 최상위에서 사용
  이를 통해 모든 자식 컴포넌트에서 상태에 접근할 수 있다.
• useRecoilState: Atom의 값을 읽고 쓰는 데 사용
• useRecoilValue: Atom의 값을 읽는 데 사용
• 상태 갱신: Recoil은 React의 가상 돔(Virtual DOM)과 조합하여 상태 변경을 효율적으로 처리함
  상태가 갱신되면 해당 상태를 사용하는 컴포넌트들이 자동으로 업데이트된다.

리코일은 간단하고 직관적인 상태 관리를 제공하므로, Redux처럼 복잡한 설정 없이도 쉽게 상태 관리를 할 수 있다.

리덕스보다 간단한 API와 직관적인 디자인으로 빠른 개발과 유지보수를 지원한다.

 

 

 

🧑‍💻  Recoil을 사용하기로 했다

나와 팀원은 이전에 Redux를 사용해본 적이 있다. 

'단방향 흐름' 컨셉이어서 리액트에서의 데이터 흐름에 대해 더 자세히 알 수 있었다.

하지만 보일러플레이트를 설정하는 데에 시간이 많이 들었던 기억이 있다.

반면, 조사 결과 Recoil은 Redux에 비해 훨씬 직관적이고 설정도 간편하다고 한다.

Redux는 사용해 보았고, 장점과 단점에 대해 파악했으니 이번에는 Recoil을 사용하기로 했다.

 

 

 

 

💡 Recoil은 정말 간편해

Recoil을 사용하기 위해 간단하게 공부하고, 공부하는 과정에서 작성한 문서를 팀원과 공유했다.

주요 함수만 정리해둔 문서였는데, 그것만 있어도 사용하는 데 어려움이 없을 정도로 간편했다.

공부하는 데 20분 정도 걸렸고 팀원과 화면 공유하며 함께 연습하고 바로 사용했다.

 

사용한 뒤 느낀 점은, '전역 상태를 React Hook useState로 관리하는 것 같은' 느낌이다.

React Hook만 써봤다면 아무 무리 없이 바로 사용할 수 있다.

함수도 여러가지라서 하위 컴포넌트에서 전역으로 상태를 set, get 필요한 대로 사용 할 수 있다.

상태 초기화, 삭제도 가능하다.

 

 

 

💬 느낀점: 전역상태 관리를 왜 하는지 알겠어요

사실 props 지옥을 맛봤던 Piggy 프로젝트도 완벽하게 설계 했다면 지옥까진 아니고 삼도천에 발담그기.. 정도였고,

지금까지 만든 것들이 대부분 useState, props 선에서 해결되는 프로젝트들이었다.

그래서 상태관리의 필요성을 그렇게 크게 느끼지 못했고, 리덕스를 배울 때도 이 복잡한 게 왜 필요한가 생각했었다.

하지만, 리코일을 쓰고 보니 전역에서 상태를 관리한다는 게 얼마나 간편하고, 효율적이고, 신뢰가 되는지 알게됐다!!!

 

리코일 너무 좋아~