React-Redux는 상태관리 도구인 'Redux'를 React에서 쉽게 사용할 수 있도록 도와주는 라이브러리이다. React-Redux는 Redux store와 React component를 연결하여, Redux store의 데이터를 React 컴포넌트에서 사용할 수 있도록 해준다.
React-Redux의 핵심적인 개념 몇 가지를 살펴봤다.
Provider
React-Redux에서 provider란, React App 내에서 Redux store에 대한 access를 제공하는 component이다. 한마디로 provider라는 component를 사용해야 여러 state가 저장되어 있는 Redux store에 접근할 수 있다는 뜻이다.
최상위 component인 App component를 provider componenet로 감싸주었고(사용), provider component에는 props로서 store가 있는 것(접근)을 확인할 수 있다.
Action
React-Redux에서 액션(Action)이란, 애플리케이션 내부에서 작동하는 특정한 이벤트를 설명하는 정보를 담은 자바스크립트 객체를 의미한다.
Action 객체는 최소한 type이라는 속성을 포함하고 있어야 하며, 일반적으로 payload라는 이름의 추가적인 속성을 가질 수 있다.
type 속성은 문자열 상수이며, event의 종류를 식별하는 데 사용된다. payload 속성은 선택적으로 action에 대한 추가적인 data를 전달하기 위해 사용된다.
위 예시에 해당 개념을 적용해서 설명해 보면 다음과 같다. 각각의 action은 증가와 감소라는 특정한 event를 포함한 객체이고, type이 이벤트의 종류를 나타내주고 있음을 확인할 수 있다. 추가적으로 payload라는 함수의 매개변수와 같은 역할을 하는 속성이 구체적으로 어떤 action을 작동시킬 것인가에 관한 내용을 포함하고 있다.
useDispatch
그렇다면 위 코드에서 아직 해결되지 않은 dispatch라는 개념을 살펴봐야 한다. action의 실행을 위해 사용하는 함수가 바로 useDispatch이다.
dispatch 함수는 action 객체를 인수로 받고, 해당 액션에 대한 처리를 위해 Redux store에 등록된 reducer 함수에 전달하는 역할을 수행한다.
Reducer
Reducer는 현재 상태와 action 객체를 parameter로 받아서, 새로운 상태를 return하는 함수이다.
action 객체가 dispatch 되면, 각 reducer function은 해당 action 객체에 따라 자신이 관리하는 상태를 업데이트하고, 이러한 상태들을 종합하여 전체 App의 상태를 갱신한다.
위 코드를 보면 본능적으로 {...state}의 개념을 해결해야겠다는 느낌을 전달받는다. {...state}는 불변 객체(Immutable Object)를 뜻한다.
결국에 reducer라는 함수는 dispatch를 통해 특정한 action을 전달받는데, state의 변경이라는 일련의 과정을 수행할때마다 원본 data가 변형된다면 ...끔찍하다. 이전 state 객체와는 다른 참조를 갖도록 하기 위해 '...state' 구문을 활용하는 것이다.
여기서 끝내기에는 아쉽다. 자바스크립트의 얕은 복사(Shallow Copy)와 깊은 복사(Deep Copy) 개념을 공부했다. 이 두 가지 개념은, 원본 데이터 구조와 복사된 데이터 구조가 어떤 구조를 참조하고 있는가에 관한 문제를 다룬다.
Shallow Copy
Deep Copy
useSelector
useSelector는 Redux store의 상태를 조회할 때 활용하는 React Hook이다.
count라는 state를 활용하고자, useSelector를 통해 count를 조회하고 있다.
전체 과정
개념이 너무 복잡해서 조잡하게나마 정리해 봤다.
회고
개발 문서를 읽다가 '톺아보다'라는 말을 알게 되었다. '톺다'라는 말은 "틈이 있는 곳마다 모조리 더듬어 뒤지면서 찾다."라는 뜻을 갖고 있다. 오늘은 Redux를 정말이지 '톺아본' 하루가 아니었나 생각한다.
휴학 기간에 한 회사에서 6개월간 아르바이트를 했는데, 사장님께서는 어떠한 문제의 원인을 찾는 데 지나치게 집착하셨다. 당시에 내가 보기엔 그랬다. 가령 어떤 product가 제대로 동작하지 않다가 테스트를 통과하면 '왜 통과했는가'하는 점을 끝까지 물고 늘어지셨다.
그때의 나는 "결과적으로 잘 동작하면 그만 아닌가?" 하는 naive한 생각을 갖고 있었던 것 같다. 결과에 종속되지 않고 원인을 톺아보시던 사장님의 태도가, 요즘 들어 새삼 중요하게 느껴진다.
종류야 어찌 됐건 product를 개발하는 사람이라면 '톺아보는' 태도를 반드시 갖추어야 한다고 생각한다. 톺아보는 태도가 부재한 개인은 성장할 수 없고, 그런 개인이 이끌어가는 조직은 반드시 자멸한다. 열심히 톺아보자! 내일도 화이팅!
