리덕스란?
중앙 데이터 저장소.
여러 컴포넌트에서 공통으로 사용하는 데이터(state)를
공통으로 관리한다.
과거 class 컴포넌트를 쓰던 시절에는 부모 컴포넌트가
자식에게 props로 내려주는 방식이였지만
리덕스가 나온 이후
리덕스가 통으로 관리하고 컴포넌트들에게 데이터를 뿌려주는 로직이 가능해졌다.
리덕스 장단점
장점
-
원리가 매우 간단해서 에러가 잘 발생하지 않고
발생해도 추적이 잘 되므로 앱을 안정적으로 개발할 수 있다.
(훅스의 useReducer, createContext, useContext 와 유사하다.) -
랜더링 로직과 비지니스 로직을 분리할 수 있다.
과거에는 컴포넌트안에서 데이터를 다루는 로직(비동기 api 요청)과
랜더링 로직을 둘 다 작성했는데
리덕스 덕분에 컴포넌트는 랜더링 로직에만 집중하고
데이터를 다루는 로직은 리덕스에 작성함으로서 로직을 분리할 수 있다.
단점
- 코드가 장황해진다. (리덕스 툴킷을 쓰면 어느정도 해결 가능 or mobx를 사용)
next-redux-wrapper
리액트와 리덕스 연동은 매우 까다롭다.
특히 next와 리덕스 연동은 더 까다롭다.
까다로운 연동 작업을 자동으로 해주는 모듈이
next-redux-wrapper이다.
리덕스 Provider
리덕스를 사용하면 Provider로 페이지를 감싸줘야 자식 컴포넌트들에게
데이터를 바로 줄 수 있다. (훅스와 createContext와 똑같다.)
근데 next-redux-wrapper의 createWrapper를 사용하면
알아서 Provider로 감싸준다.
Store란?
앱 전체의 state와 reducer를 포함해서 같이 부르는 명칭
redux-devtools-extension
리덕스와 크롬 데브툴즈와 연결 모듈
이 기능을 사용하면 action -> dispatch -> reducer가 될 때마다
히스토리가 남고 그 히스토리를 시간 여행할 수 있다. (혁명이다...)
리듀서 쪼개는 방식
상태 트리에서 새로운 객체가 생성되는 부분을 기준으로 쪼갠다.
combineReducers
쪼갠 리듀서들을 합쳐주는 함수
리듀서를 쪼개면서 트리 구조로 된 객체 state도 쪼갰는데
이를 다 합쳐준다.
리덕스 공식 문서를 보면 모든 상태는 하나의 저장소에 저장하라고 하기 때문에
꼭 합쳐줘야 한다.
그래야 createStore을 했을 때 하나의 저장소로 관리할 수 있다.
일기
강의를 보면서 느끼는 건데
프론트 개발 환경이 정말 많이 편해졌고 발전했다고 느낀다.
이미 저명한 개발자들이 모여서 만든 라이브러리와 모듈들을
공식 문서를 보며 사용하는 법만 익히면 되니까 참 감사할 따름이다.
