TIL 50일차 -  [React] Redux 1

• React에서는 상태와 속성(props)을 이용한 컴포넌트 단위 개발 아키텍처를 배웠다면,
  Redux에서는 컴포넌트와 상태를 분리하는 패턴을 배운다.

• 상태를 다루기 위해 컴포넌트 안에서 상태 변경 로직이 복잡하게 얽혀있는 경우가 많았다.
  그러나 상태 변경 로직을 컴포넌트로부터 분리하면 표현에 집중한,
  보다 단순한 함수 컴포넌트로 만들 수 있다.

• Redux는 React 없이도 사용할 수 있는 상태 관리 라이브러리다.

• 상태 관리 라이브러리가 왜 필요한지 이해할 수 있다.

  o
  상위 컴포넌트의 state를 props를 통해 전달하고자 하는 컴포넌트로 전달하기 위해 props를 전달하는 용도로만 쓰이는 그 사이에 있는 컴포넌트들을 거치면서 데이터를 전달하는 Props Drilling이 있다.

  이러한 Props Drilling은 규모가 크고 복잡한 경우에 사용하면,
  코드 가독성이 나빠지고, 유지 보수 또한 힘들어지고, 불필요하게 관여된 컴포넌트 또한 리렌더링 되어 웹성능이 떨어지는 문제점이 있다.

  이러한 문제점을 해결하기 위해서는
  컴포넌트와 관련된 state는 될 수 있으면 가깝게 유지하거나
  Redux, Context.api, Mobx, Recoil 등의 상태 관리 라이브러리를 사용한다.

• Redux에서 사용하는 Action, Dispatcher, Reducer 그리고 Store의 의미와 특징을 이해할 수 있다.

  o
  👇 [React에서의 데이터 흐름]

  

  이 애플리케이션은 컴포넌트3, 컴포넌트6에서만 사용되는 상태가 있다.
  이 경우, 상태는 부모 컴포넌트인 최상위 컴포넌트에 위치시킨다.
  그러나 다음과 같은 문제가 발생한다.

  1. 해당 상태를 직접 사용하지 않는
     최상위 컴포넌트, 컴포넌트1, 컴포넌트2도 상태 데이터를 가짐
  2. 상태 끌어올리기, Props 내려주기를 여러 번 거쳐야 함
  3. 애플리케이션이 복잡해질수록 데이터 흐름도 복잡해짐
  4. 컴포넌트 구조가 바뀐다면, 지금의 데이터 흐름을 완전히 바꿔야 할 수도 있음

  ---

  👇 [Redux를 사용했을 때의 데이터 흐름]

  

  이러한 문제들을 상태 관리 라이브러리인 Redux를 사용하면,
  전역 상태를 관리할 수 있는 저장소인 Store를 제공함으로써 해결할 수 있다.

  ---

  👇 [Redux 구조]

  

  Redux는 다음과 같은 순서로 상태를 관리한다.

  상태가 변경되어야 하는 이벤트가 발생하면,
  (위의 그림에서는 count : 1에서 +를 클릭하면
  상태가 count : 2로 변경 되어야 하는 이벤트가 발생한다.)

  변경될 상태에 대한 정보(count : 1 +1)가 담긴 Action 객체가 생성된다.

  이 Action 객체는 Dispatch 함수의 인자로 전달된다.

  Dispatch 함수는 Action 객체를 Reducer 함수로 전달해 준다.

  Reducer 함수는 Action 객체의 값을 확인하고,
  그 값에 따라 전역 상태 저장소 Store의 상태를 변경한다.(count : 2)

  상태가 변경되면, React는 화면을 (count : 2로) 다시 렌더링 한다.

  즉, Redux에서는 Action → Dispatch → Reducer → Store 순서로
  데이터가 단방향으로 흐르게 된다.

• Redux의 3가지 원칙이 무엇이며, 주요 개념과 어떻게 연결되는지 이해할 수 있다.

  o

  1. Single source of truth
     '동일한 데이터'는 항상 '같은 곳'에서 가지고 와야 한다.
     즉, Redux에는 데이터를 저장하는 'Store(저장소)'라는
     단 하나뿐인 공간이 있음과 연결이 되는 원칙이다.

  2. State is read-only
     '상태'는 '읽기 전용'이라는 뜻으로,
     React에서 상태 갱신 함수로만 상태를 변경할 수 있었던 것처럼,
     Redux의 상태도 직접 변경할 수 없음을 의미한다.
     즉, Action 객체가 있어야만 상태를 변경할 수 있음과 연결되는 원칙이다.

  3. Changes are made with pure functions
     변경은 순수함수로만 가능하다는 뜻으로,
     상태가 엉뚱한 값으로 변경되는 일이 없도록
     순수함수로 작성되어야 하는 Reducer와 연결되는 원칙이다.

+) 추가학습

• 다소 복잡한 Redux의 코드를 개선하는 데 도움이 되는
  Redux Toolkit에 대하여 학습하기

• Redux Toolkit의 createAsyncThunk를 활용하여
  비동기 코드 처리 방법에 대하여 학습하기

---

과제1 - Blogging : Redux

• 블로깅 과제 충족 조건: 다음의 키워드를 포함해야 한다.

  • Redux의 데이터 흐름 ✓
  • FLUX 패턴 ✓

    기존 양방향 데이터 흐름의 MVC(Model-View-Controller)패턴은
    구조가 너무 복잡해지고 예측성이 떨어지는 문제점이 있어 이를 보완하고자
    단방향 데이터 흐름의 Flux 패턴이 등장했다.

    👇 [MVC 패턴]

    

    👇 [Flux 패턴]

    

[레퍼런스 링크]

• robinwieruch 블로그: Redux
  • What is Redux? / Basics in Redux without React를 참고
• FLUX 패턴 공식 문서

---

과제2 - Cmarket Redux

앞서 진행했던 Cmarket Hooks 과제의 상태를
React Hooks가 아닌 Redux로 관리할 수 있도록 만들어본다.

과제를 진행하면서 Redux에서 어떻게 상태 변경 로직이
컴포넌트로부터 분리되는지 살펴봄으로써
이 과제의 목적은 Redux를 사용한 상태 관리를
처음부터 구현해 내는 데에 있는 것이 아니라
Redux의 원리와 구조,
즉 설계를 알아가는데 포커스가 더욱 맞춰져 있다.

코드를 완성해 나가면서 Redux를 더 깊게 이해하고 사용법을 익힌다.

• Redux의 주요 개념인 Action, Dispatch, Reducer, Store를 작성하고 연결하여 사용할 수 있다.

  o

• Redux hooks(useSelector, useDispatch)를 사용해 Store를 업데이트할 수 있다.

  o

---

소감

🔡➡️💻➡️🤓👍

어제 Redux를 사용하지 않고 과제를 구현했을 때는
막막하고 어디서부터 시작해야 할지 감을 잡기 어려웠는데,
오늘은 강의 자료를 보면서 감을 찾을 수 있었다.

Redux를 사용하니 훨씬, 상태를 다루기 쉬웠고,
코드를 복잡하게 작성하거나, props를 내려줄 필요도 없었다.

어제는 페어분과 머리를 싸매고 고민하다가 다 풀지 못했는데 🤯
오늘은 페어분과 의견을 나누며, 너무 재밌게 페어 활동을 했다. 🤩👍