리덕스 (js의 라이브러리)는 가장 사용률이 높은 상태관리 라이브러리이다. 리덕스를 사용하면, 컴포넌트들의 상태 관련 로직들을 다른 파일들로 분리시켜서 더욱 효율적으로 관리 할 수 있다. 또한, 컴포넌트끼리 상태를 공유하게 될 때 여러 컴포넌트를 거치지 않고도 손쉽게 상태 값을 전달 할 수 있다.
추가적으로, 리덕스의 미들웨어라는 기능을 통하여 비동기 작업, 로깅 등의 확장적인 작업들을 더욱 쉽게 할 수도 있게 해준다.
위 그림처럼 Redux는 데이터의 흐름이 단방형으로 흐르는 구조이다.
action, reducer, selector, store를 세팅하는 보일러플레이트 코드는 유지보수라는 장점을 가지고 있지만,
상태의 개수가 적더라도 보일러플레이트 코드가 크다는 단점이 있다.
Redux 라이브러리의 경우 store에 모든 상태를 저장하는 중앙집중방식이다.
store는 외부 요소이기 때문에 리액트 내부에 접근할 수 없다.
그리고 비동기 데이터 처리를 하려면 saga와 같은 별도의 라이브러리를 추가적으로 사용해야 한다.
- Redux는 오직 하나의 store만 가지며, 하나의 객체 트리를 가지기 때문에 디버깅이 용이하다.
- store 내부 상태는 action 객체에 의해서만 변경이 가능하다. 모든 state 변화들이 하나의 store에만 집중되어 있고 단방향으로 일어나기 때문에 예측 가능한 결과가 나타난다.
- reducer는 순수함수이기 때문에 상태를 변경하는 것이 아닌 새로운 상태를 반환한다.
상태 변화는 리렌더링을 초래하기 때문에 상태 구성 요소를 최소화하는 것이 좋다. 하지만, SPA에서 시간의 흐름에 따라 상태 구성 요소는 분명 많아질 수 밖에 없다. 리덕스는 결국, 많아진 상태 구성 요소들을 보다 효율적으로 관리할 수 있도록 도와준다.
스토어를 사용하여 상태를 컴포넌트 구조 바깥에 두고 스토어라는 중간자를 통해 상태를 업데이트하거나, 새로운 상태를 전달받는다.
즉, 리덕스를 사용하면, 위와 같이 상태값을 컴포넌트에 종속시키지 않고, 상태관리를 바깥에서 할 수 있게 해준다.
Redux의 단점
우선 코드작성이 '초기에는 복잡'하다. 스테이트 업데이트에 맞는 액션값들과 디스패치함수들 그리고 리듀서들 등등 초기에 미리미리 전부 만들어 줘야하는 복잡성이 있다. 위의 그림은 단 2가지 상태값밖에 없지만 프로젝트가 커지고 복잡해지면 액션값들이 몇십개는 늘어날 것이다.
👉🏻 이 단점을 보완하기위해 여러가지 라이브러리들이 출시되었다. 그중 리덕스 툴킷이 제일 유명하다.
Redux를 사용하면 좋을 경우
- 앱의 여러 위치에서 필요한 많은 양의 상태들이 존재할 때 (전역 상태가 필요하다고 느껴질 때)
- 상태들이 자주 업데이트 될 때
- 상태를 업데이트 하는 로직이 복잡할 때
- 앱이 중간 또는 큰 사이즈의 코드를 갖고 있고 많은 사람들에 의해 코드가 관리될 때
- 상태가 업데이트되는 시점을 관찰할 필요가 있을 때
* 리덕스 추가 정리
추가, 삭제와 같은 각각의 액션타입을 정의합니다. 액션 함수는 각각의 액션 타입과 파라미터를 입력받아 액션을 객체 형태로 반환해준다. 상태의 변화가 필요해진다면, 디스패치가 액션을 발생시켜 스토어에게 알린다. 스토어로 전달된 액션은 스토어의 리듀서 함수를 호출시키고, 호출된 리듀서 함수는 이전 상태와 액션타입을 파라미터로 전달받아 정의된 로직대로 현재 상태값을 변화시켜 변화된 상태를 반환한다. 반환된 상태는 스토어에 저장된다.
+) Flux 란? (mvc 패턴 연관)
Flux란 애플리케이션의 데이터 흐름을 관리하는 패턴을 말한다. 중요한 것은 데이터의 흐름이 단방향으로 흐른다는 것이다.
Flux 사용이유
- 예측가능성을 높여준다.
- 데이터의 일관성을 유지하기 쉽게 만들어준다.
- 버그를 발견하기 쉽게 해준다.
- 테스트를 쉽게 해준다.
Flux의 구조
- Dispatcher
- Store
- Action
- View
+) prop drilling이란 무엇이고, 어떻게 피할 수 있는가?
Prop Drilling 은 props를 오로지 하위 컴포넌트로 전달하는 용도로만 쓰이는 컴포넌트들을 거치면서 React Component 트리의 한 부분에서 다른 부분으로 데이터를 전달하는 과정이다.
우선 Prop Drilling 은 문제가 되지 않는다. prop 전달이 3~5개 정도의 컴포넌트라면 말이다.
하지만 prop 전달이 10개, 15개 같이 더 많은 과정을 거치게 된다면 어떻게 될까? 코드를 읽을 때 해당 prop을 추적하기 힘들어진다.
그렇기 때문에 유지보수도 더욱 어려워지게 된다.
그럼 어떻게 해야할까?
과도한 Prop Drilling를 피하기 위해 전역 상태관리 라이브러리 사용할 수 있다.
Redux, Apollo client, Context API, Recoil 등 상태관리 라이브러리들을 사용한다. 우리가 상태관리할 '동적인 information data' 들을 어떠한 공간에 모아 그 곳에서 모든 정보를 관리하고 컴포넌트들에게 내려주는 것이다. 이 것을 '스토어'라고 명칭한다.
전역 상태관리 라이브러리를 사용해 해당 값이 필요한 컴포넌트에서 직접 불러서 사용할 수 있다.
reference
https://hannut91.github.io/blogs/flux