Redux의 상태관리의 주요 개념, 상태관리 비교

redux의 주요 개념

• store
  저장소, 즉 전역상태를 저장하는 공간.
  자바스크립트 객체 형태로 저장되어 있으며 오직 Reducer를 통해서만 접근 가능하다.
  보통은 최상단의 index.js에 정의하며 여러개의 context를 만들 수 있는 ContextAPI와 다르게 redux의 store은 1개만 존재한다.
• Action
  reducer에게 보내는 Store에 대한 행동을 정의하는 객체이다.
  상태에 어떠한 변화가 필요할 때 액션을 발생시키며 "이렇게 상태를 변경해줘"라고하는 주문서의 역할을 한다고 보면 이해하기 좋다.
  Action을 reducer에게 전달하기 위해서는 dispatch메소드를 사용해야한다.
  dispatch는 store의 내장함수 중 하나인데, 액션 객체를 넘겨줘서 상태를 업데이트 한다. 이벤트 트리거 역할을 한다.
• Reducer
  이전 상태와 액션을 받아, 다음 상태를 반환하는 역할을 하는 순수함수이다.
  reducer를 통해서만 전역 상태를 변경하고 업데이트할 수 있다. 어떤 액션이 들어오는지 그 유형에 따라 이벤트를 처리하는 이벤트 리스너라고 볼 수 있다. 여기서 중요한 점은 이전 상태를 변경한다는 점이 아니라, 새로운 상태 객체를 생성해서 반환해야한다.
• action -> dispatch -> reducer -> store의 단방향을 가지고 있으며, reducer의 경우 순수함수여야한다.
  ** 외부요인으로 인해 다른값이 나오면 안되기 때문

참고블로그) https://medium.com/@ca3rot/아마-이게-제일-이해하기-쉬울걸요-react-redux-플로우의-이해-1585e911a0a6

참고 블로그)https://velog.io/@jeju_daun/React-Redux

---

Context API와 redux,recoil 비교
1.contextAPI

//context 선언
const context = React.createContext(defaultValue)

//Provider 선언
const App = () => {
	return (
		<Context.Provider value={context}>
			...
		</Context.Provider>)}

//context 구독
const state = useContext()

** 문제점)

provider : 앱 최상단에 위치한다. 이것은 context를 구독하는 컴포넌트들에게 context의 변화를 알리는 역할을 한다.

이때 context를 구독하는 컴포넌트들은 provider의 value가 바뀔때마다 다시 렌더링된다.

즉, context가 변경될때마다 useContext()를 사용한 모든 컴포넌트가 리렌더링된다는 것, 성능상 비효율성이 높다.

값 변화가 자주 일어나지 않는 변수들을 context로 관리해주는게 좋다.

 

2.redux

데이터가 한 방향으로 흐르기 때문에 오류가 생길 경우 관리가 쉽다.

프로젝트 구조가 커짐에 따라 보일러 플레이트가 아주 방대해질것이다. 이를 해결하기 위해서 reduxToolkit이 나왔지만 다른 것에 비해 어려울 수 있다.

 

3.recoil

제일 핵심되는 개념은 atom이다. atom은 state를 말하며 컴포넌트들이 구독할 수 있는 단위이다.

atom의 값을 읽는 컴포넌트들을 암묵적으로 atom을 구독한다.

atom->selector->view의 흐름을 가진다.

 

** 문제점)

손쉬운 전역상태 관리 만큼 예측하기 어려운 상태변경

어느 컴포넌트라도 전역상태에 직접 접근하여 상태를 업데이트 할 수 있다. 즉, 어느 컴포넌트가 언제 전역상태를 변경하는지 알 수 없다는것

그리고 redux에 비해 좋은 개발자 도구가 없어서 상태변경 파악하기 어렵다.

 

 

참고 블로그)

https://techblog.yogiyo.co.kr/recoil%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%86%90%EC%89%AC%EC%9A%B4-%EC%83%81%ED%83%9C%EA%B4%80%EB%A6%AC-b70b32650582