- Redux 그리고 Recoil은 react를 위한 상태관리 라이브러리
- redux 는 Flux 아키텍쳐 기반
- recoil 은 Atomic 모델 기반
(Atom 이라는 작은 상태 단위로 관리하고 Atom 을 결합하여 데이터를 가공)
Redux
- flux 아키텍쳐의 데이터 흐름은 단방향
- Action 은 Action 을 생성하여(type, payload) 이를 Dispatcher 에게 전달
- Dispatch 는 모든 Action 을 전달받아 Store에 전달
- Store 는 State 를 가지고 있고 State 를 변경
- Store 에서 State 변경 시, change 이벤트가 발생하고 View 에게 State 가 변경되었다는걸 알려줌.
(이때 View 에서 사용하는 State 는 업데이트가 일어난다 -> Rerender)
redux는 중앙집중식으로 상태관리가 이루어짐. 실제로 전체 모델은 복잡한 편이 아님
(여태 복잡한줄 알고 있었다..)
언제 Redux가 필요할까?
1) 리덕스를 사용한 개발 스타일이 너무 마음에 들 때
- 적당한 상황에서 쓰면 정말 편하고 좋은 도구이고, 불필요한 상황이면 번거롭고 불편할 수도 있음.
- 처음 공부하는 과정에서 사용해야 하는 이유를 정확히 이해하지 못하고
무조건 사용하는 경우엔 불편하게 느껴질 것.
- 모든 상태 업데이트를 액션으로 정의, 액션 정보에 기반하여 리듀서에서 상태를 업데이트하기에
상태를 더욱 쉽게 예측 가능하게 하여 유지보수 측면에 긍정적인 효과가 있음.
2) 미들웨어
- 리덕스는 다른 라이브러리와는 다르게 많은 미들웨어가 존재.
- 특정 액션이 디스패치 됐을 때 상태 업데이트외의 다른 작업들을 따로 처리 가능.
- 보통 API 요청을 할 때 미들웨어를 사용함.
- [!] 이전에는 API 요청을 위하여 리덕스와 미들웨어를 사용하는 것이 당연했지만
이제는 SWR 과 react-query 같은 라이브러리가 있기에
단순 API 요청을 위하여 미들웨어를 사용 할 필요는 없음
- 비동기 작업에 대한 플로우에 대하여 더 많은 컨트롤을 필요로 할 때는
미들웨어가 유용하게 사용될 수 있음.
3) 기타 이유
- 그냥 많이 사용 돼서: 유지보수하고 있는 프로젝트가 리덕스를 사용할 확률이 높다거나..
- 서버사이드 렌더링, 더 쉬운 테스팅, 컴포넌트가 아닌 글로벌 상태를 사용하거나 업뎃 할 때
이 이유들이 아니라면 굳이 Redux를 사용할 필요는 없음
Recoil
- ContextAPI 만을 사용하여 글로벌 상태 관리를 하는 것이 어느정도 제한이 있어서 만들어진 라이브러리
- recoil 은 다른 개념을 제시.
Atom 이라는 상태 단위로 상태를 관리하며 컴포넌트는 이 Atom 을 구독하기만 하면 됨.
- 저장소 개념보다는 작은 상태 단위(Atom)로 관리
- recoil 은 redux 와 비교했을때 학습곡선 비용이 적으며 동시모드를 지원
- 상태 변경으로 인한 불필요한 렌더링이 발생하지 않음 (상태를 구독한 컴포넌트만 리랜더링 발생)
- selector 를 통해 캐싱 (기본적으로 값을 캐싱함)
Atom & Selector?
Atom: 상태(state)의 일부를 나타내며, Atoms는 어떤 컴포넌트에서나 읽고 쓸 수 있음. (상태 조각)Selector: Selector는 파생된 상태(derived state)의 일부를 나타냄. 파생된 상태는 상태의 변화
- 파생된 상태를 어떤 방법으로든 주어진 상태를 수정하는 순수함수에 전달된 상태의 결과물.
(아톰에서 파생된 데이터 조각이며 데이터를 반환하는 순수함수)
흠.. Recoil?
- 아직 실험적인 단계에 있는 라이브러리
- 보수적으로 다가가고자한다면 조금 더 지켜봐야..
- 하지만 지금 있는 기능들은 많이 안정화가 되어 있음. (AtomEffect 기능은 개발 중)
- 프로덕션에서 사용해도 큰 문제는 없음
(리디에서도 일부 기능을 사용하고 있다하며, 다른 회사에서도 종종 사용되고 있음)
- recoil은 상대적으로 redux보다 적은 학습비용 & 코드량이 적음
- recoil은 성능이점을 얻을 수 있음
하지만, 대규모 프로젝트에 적용하기에는 좋은 사례라던가 레퍼런스들이 부족함
생각 정리
- recoil을 프로젝트에 쓰려면, 소규모의 프로젝트가 좋을 것 같음
- redux는 나온지도 오래되었고 관련 미들웨어도 많음
(하지만 점점 redux를 걷어내고 있다는 말도 들었어서, 고민해봐야함)
- recoil을 적용하기엔 위에 쓴 것처럼 대규모 프로젝트에 적용하기엔 좋은 레퍼런스가 부족
참고자료
추가 참고자료
만약 redux, recoil 둘 다 싫다면 예전에 해봤던 react의 ContextAPI + useReducer 조합은 어떨까?
(Atom 이라는 작은 상태 단위로 관리하고 Atom 을 결합하여 데이터를 가공)
Redux
(이때 View 에서 사용하는 State 는 업데이트가 일어난다 -> Rerender)
언제 Redux가 필요할까?
1) 리덕스를 사용한 개발 스타일이 너무 마음에 들 때
무조건 사용하는 경우엔 불편하게 느껴질 것.
상태를 더욱 쉽게 예측 가능하게 하여 유지보수 측면에 긍정적인 효과가 있음.
2) 미들웨어
이제는 SWR 과 react-query 같은 라이브러리가 있기에
단순 API 요청을 위하여 미들웨어를 사용 할 필요는 없음
미들웨어가 유용하게 사용될 수 있음.
3) 기타 이유
Recoil
Atom 이라는 상태 단위로 상태를 관리하며 컴포넌트는 이 Atom 을 구독하기만 하면 됨.
Atom & Selector?
Atom: 상태(state)의 일부를 나타내며, Atoms는 어떤 컴포넌트에서나 읽고 쓸 수 있음. (상태 조각)Selector: Selector는 파생된 상태(derived state)의 일부를 나타냄. 파생된 상태는 상태의 변화(아톰에서 파생된 데이터 조각이며 데이터를 반환하는 순수함수)
흠.. Recoil?
(리디에서도 일부 기능을 사용하고 있다하며, 다른 회사에서도 종종 사용되고 있음)
하지만, 대규모 프로젝트에 적용하기에는 좋은 사례라던가 레퍼런스들이 부족함
생각 정리
(하지만 점점 redux를 걷어내고 있다는 말도 들었어서, 고민해봐야함)
참고자료
(프리젠테이셔널 & 컨테이너 컴포넌트 더 이상 사용하지 않는 이유라던지..)
추가 참고자료
만약 redux, recoil 둘 다 싫다면 예전에 해봤던 react의 ContextAPI + useReducer 조합은 어떨까?