컴포넌트 계층 구조에서 상위 컴포넌트에서 하위 컴포넌트로 props를 전달할 때, 해당 props를 딱히 필요로 하지 않는 중간에 낀 컴포넌트까지 거쳐가야 할 때가 있다. 한두개 거치면 그러려니 하지만 고조 할아버지의 고조 할아버지 컴포넌트에서 아들손자 컴포넌트로 전달하려고 한다면 아주 킹받는 상황이 될 것이다. 킹받기만 하면 다행이다. 애플리케이션 규모가 커질 수록 코드의 유지 보수가 어려워지고, 컴포넌트 수정이 이루어질 경우 props의 전달 경로도 같이 고려해야 해서 복잡해질 우려가 크다.
전역 상태 관리 라이브러리는 이러한 props-drilling 문제를 해결하는데에 빛을 발한다. 그중 보편적으로 사용되는 Redux!!를 아미루고미루다 드디어 공부해보았다.
Redux의 데이터 흐름은 단방향이다. Action 객체가 dispatch 함수의 인자로 전달되면, dispatch가 Action 객체를 Reducer 함수로 전달해준다. 그리고 Reducer 함수의 결과값으로 store에 저장된 state이 갱신된다.
백문이 불여일견이므로, 단방향 데이터 흐름을 경험해보기 위해 redux를 사용하여 간단히 memo 기능을 구현해보았다.
memo input과 + 버튼을 만들고
간단히 데이터를 추가, 삭제하는 기능을 구현하며 Redux가 선사하는 단방향 데이터 흐름을 느껴보자.
Action
나는 addMemo와 deleteMemo라는 action을 각각 정의해보았다. 이 둘은 객체를 return 해야한다.
dispatch (Action 객체를 reducer에게 인자로 전달해주는)
- 버튼을 누르면 ADD action을, - 버튼을 누르면 DELETE action을 각각 reducer 함수에 전달하려고 한다. dispatch를 이용하여 전달 가능하며, 이를 onClick에 연결하기 위해 각각 handleAdd와 handleDelete 함수를 선언했다.
onChange 함수와 useState를 이용하여 newMemo라는 state에 input에 있는 현재 값을 담았다.
dispatch를 호출할 때는 각각 {id: Date.now(), content: newMemo}를 payload로 전달한다.
reducer (action을 인자로 받음)
action의 type이 ADD일 경우, spread 연산자를 이용하여 새로운 payload를 추가시킨다.
action의 type이 DELETE일 경우, filter를 사용하여 payload의 id와 같은 기존 데이터를 필터링해버린 배열을 return한다.
store (reducer가 return 하는 새로운 state으로 갱신하여 보관)
createStore를 사용하여 state을 보관하며, 이는 user가 보는 화면에 곧 뿌려질 것이다.
view (갱신된 state을 유저에게 보여주자)
useSelector를 이용하여 state을 memos라는 변수에 담고
map을 이용하여 뿌려준다.
메모를 입력하고 + 버튼을 누르면 아래에 리스트가 화면에 보여지도록 하였다.
그리고 메모마다 옆에 있는 -버튼을 누르면 메모가 삭제되도록 하였다.
이렇게 아주 작은 기능만 구현해보아서 사실 redux를 쓰지 않고 구현했어도 props가 왔다갔다 할일은 딱히 많지 않았을 것 같긴 하다. 하지만 전역 상태를 관리해주는 곳이 별도로 있으니 store 한 곳만 신경 쓰면 되어서 app 규모가 커져도 많이 편해질 것이라는 생각은 강력하게 든다. 그리고 redux toolkit도 얼른 공부해서 토이 프로젝트 해볼 때 많이많이 써보자. 화이팅!!!
