어드민 개편
Last updated
Was this helpful?
Last updated
Was this helpful?
리듀서는 상태를 처리하고 책임진다. 리듀서가 뚱뚱해질 수 있는데 이 문제를 해결하기 위해 reducer를 slice하여 combineReducer로 합칠 수 있다.
그래서 여튼 나는, 리듀서를 관심사 별로 분리하는 걸 지향한다. () 관심사 분리를 통해 리듀서의 책임을 분명히 할 수 있고 무엇보다도, 테스트 하기 너무 쉽다. slice된 리듀서만큼으로 독립된 환경에서 테스트할 수 있다.
여담이지만 순수함수는 진짜 쵝오다. 그리고 리듀서는 순수함수다. 순수함수는 부수효과가 없고 동일 input 동일 output이다. 리듀서는 동일 action 객체에 동일 상태를 리턴한다. 테스트는 단순해진다. 동일 action 객체를 전달하여 내가 기대한 상태(객체)를 반환하는지 확인만 하면된다.
어떤 상태를 redux global vs component local 이 고민은 많이 해본거라 깃허브 에서 금방 찾을 수 있다.
요약 + 내생각엔
global : 지속되어야하는 도메인 데이터, 컴포넌트간에 공유하는 UI 상태
local : 글로벌하지 않고 짧게 지속(임시로 사용)되는 상태는 컴포넌트 내뷰화 캡슐화하자.
모든 상태는 redux에서..? ㄴㄴ 이러면 비효율적이고 쓸데없는 보일러 플레이트를 많이 만들게 된다.
그래서 상황에 맞게 redux 상태에 혹은 local state에 넣어준다.
도메인 & 기능단위로 나눈다.
임시로 사용하고 버릴 값은 혹은 글로벌하게 사용되지 않은 값 모두 local 상태를 사용한다. (input 안의 상태 값이 대표적이다.) 만약 input안에 텍스트 입력시마다 action -> dispatch -> store -> reducer -> store -> component가 일어난다고 해보자... 비효율이다. 인터랙션 처리에 필요한 상태는 local State에서 관리하고, 처리된 텍스트를 통해 API 호출 등이 필요하면 그 때 리덕스를 이용하자.
당연하지만 action은 리듀서와 1:N 관계다.
action type 이름은 리듀서한테 이렇게 상태를 바꿔줘! 보다는 이런 동작이 일어났어! 로 작명한다.
이유는 이렇게 상태를 바꿔줘 는 리듀서와 1:1 관계가 되기 쉽다.
이렇게 동작이 일어났어 라고 타입을 지정해줘야 N개의 리듀서가 상태를 변환하는게 더 확장하기 쉽다고 생각한다.
(근데 때에따라 이렇게 상태를 바꿔줘가 명확할 때도 있으니 케바케다.)
container는 리덕스와 presentational의 연결고리다. 각종 이벤트 핸들러, 리덕스의 상태를 내려주는 책임을 가진다.
컨테이너 컴포넌트는 connect(hook을 사용한다면 useSelector)를 통해 원하는 (형태를 가진)상태를 받을 수 있다. 컨테이너 컴포넌트는 구독방식이다. connect에서는 shallow compare를 하는데 하나라도 값이 달라져있으면 리렌더링을 진행한다.
불필요한 리렌더링을 막기 위해 여러가지 방법이 있다.
이 컨테이너 컴포넌트가 불필요하게 많은 상태를 mapStateToProps에서 유지하는가?
극단적으로 댓글을 보여주는 컴포넌트인데 state 트리를 구독한다고 해보자.
state 트리의 유저이름이 변경되었는데도 이 컴포넌트는 리렌더링 된다.
렌더링 될때마다 셀렉터 함수에서 어떤 연산을 거쳐서 새로운 객체가 반환되지는 않는가?
1번의 경우,