나 홀로 코딩 - 장바구니 구현(리액트 상태관리 With Redux)

나 홀로 코딩 - 장바구니 구현(리액트 상태관리 With Redux)

아마존 클론 코딩 진행 시 수월하게 클론 코딩했지만 스스로 코딩 구현할 때는 실행이 잘 되지 않았습니다.
Redux도 다시 공부하기 위해 내용을 정리 해봅니다.

1. 폴더 구조 잡기

pages

• 페이지 단위의 컴포넌트 폴더로 구성
• ex) Login - Login.js, Login.scss / Main - Main.js, Main.scss
• 내 프로젝트 ⇒ List.js / Detail.js

components

• 공통 컴포넌트 관리 (Header, Footer, Nav 등)
• 내 프로젝트 ⇒ ProductList.js / ProductDetail.js

components vs pages

• 여러 페이지에서 동시에 사용되는 컴포넌트의 경우 components 폴더에서 관리
• 페이지 컴포넌트의 경우 pages 폴더에서 관리
• 해당 페이지 내에서만 사용하는 컴포넌트의 경우 해당 페이지 폴더 하위에서 관리하는 것이 좋음

2. 페이지 구성 하기

Home = 시작 화면
List = 상품 페이지
Cart = 장바구니
Detail = 상품 상세 페이지

구현하고 싶은 기능

1. 수량 증가, 감소 버튼이 있고, 장바구니 담기
2. 장바구니에 담기 상품들이 자동 계산
3. 장바구니에서 상품 삭제

문제점

• Redux 도입 -> 증가, 감소 버튼 추가되었지만 장바구니 담기와 연동 불가
  <참고>
  https://redux-toolkit.js.org/tutorials/quick-start

해결방법

 

 => 먼저, Redux  다시 공유해서 상태 관리 복습 필요

Redux란?

상태 관리 라이브러리 중 하나로 Redux 외에 Context API, MobX 등이 있습니다. Redux는 React뿐만 아니라 Angular, Vue에서도 사용할 수 있습니다.

리액트 상태 관리란?

리액트는 단방향 바인딩을 지원하기 때문에 부모에서 자식으로만 state를 props로 전달할 수 있고,

자식의 props를 부모에게 직접 전달할 수는 없습니다.

자식에서 부모의 상태를 바꾸려면 해당 상태를 컨트롤하는 함수를 props로 넘겨주어야 합니다.

하지만 이것이 반복되다 보면 엄청난 props drilling이 발생하게 된다는 문제가 있습니다.

또한 프로젝트의 규모가 커질수록 props가 증가하게 되고, 이는 불필요한 리렌더링을 유발할 수도 있습니다.

→ Component 간의 정보 공유

자식 컴포넌트들 간의 다이렉트 데이터 전달은 불가능합니다.

자식 컴포넌트들 간의 데이터를 주고받을 때는 상태를 관리하는 부모 컴포넌트를 통해서 주고받습니다.

그런데 자식이 많아진다면 상태 관리가 매우 복잡해집니다.

상태를 관리하는 상위 컴포넌트에서 계속 내려받아야 합니다. => Props drilling 이슈

상태 관리의 복잡성을 해결해주는 라이브러리를 활용하게 됩니다.

 

Context API

Context API를 이용하면 각 컴포넌트마다 데이터를 파라미터로 받거나 하위 컴포넌트에 데이터를 전달하는 과정이 생략됩니다.

⇒더 이상 여러 컴포넌트를 거쳐서 값을 전달해주는 것이 아니라, Context를 통해서 원하는 값이나 함수를 바로 쏴줄 수 있게 됩니다.

React에서만 사용할 수 있습니다.

Redux

리덕스는 상태의 중앙 관리를 위한 상태 관리 도구입니다.

React뿐만 아니라 Angular, Vue에서도 사용할 수 있습니다.

기존에는 부모에서 자식의 자식의 자식까지 상태가 흘렀었는데, 리덕스를 사용하면 스토어를 사용하여 상태를 컴포넌트 구조의 바깥에 두고, 스토어를 중간자로 두고 상태를 업데이트하거나, 새로운 상태를 전달받을 수 있습니다.

리액트에서 Context API 가 도입됨에 따라 어느 정도 해소가 되긴 했습니다. 그렇지만 Context API는 성능적인 이슈가 아직 존재합니다.

값에 변화가 발생했을 때 Context를 구독하고 있는 모든 컴포넌트들이 전체적으로 모두 리-렌더링이 발생합니다.

따라서 반복적이고 복잡한 업데이트와 관련된 부분에서는 비효율적일 수 있습니다.

반면 리덕스의 경우에는 자체적으로 리-렌더링과 관련된 부분에 최적화가 적용되어 있기 때문에, 부분적인 리-렌더링이 발생합니다.

또한 리덕스를 사용한다면 Context API에선 제공할 수 없는 여러 다양한 기능들을 미들웨어를 사용해 관리할 수 있는 장점 또한 존재합니다.

 

MobX

MobX의 경우 리덕스와 달리 store가 여러 개가 될 수 있는데요, 이는 분리가 용이해 편리할 수도 있는 반면 상태 변경 시 다수의 스토어가 영향을 받을 수 있습니다.

컴포넌트에 observer를 달아주고 그 내부에서 사용되는 observable state(옵저버로 관찰 중인 상태)의 변화가 감지되면 해당 컴포넌트를 리렌더링 시켜주는 라이브러리입니다.

MobX는 action으로 state가 바뀌었을 때, 단방향으로 데이터가 흐르게 됩니다. 그 결과 영향을 받는 뷰들이 update 됩니다.

Event가 발생하면 action으로 observable을 변경합니다.

observable이 변경된 것은 그 값에 의존하고 있는 computed와 side effect에게 전달됩니다.

 

 

참고, 인용

https://hanamon.kr/%ec%83%81%ed%83%9c%ea%b4%80%eb%a6%ac%eb%8f%84%ea%b5%ac-%ed%95%84%ec%9a%94%ec%84%b1/

https://hanamon.kr/redux%EB%9E%80-%EB%A6%AC%EB%8D%95%EC%8A%A4-%EC%83%81%ED%83%9C-%EA%B4%80%EB%A6%AC-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC/

[FE] 리액트 상태관리 1부.

리액트 상태 관리 가이드

상태관리 라이브러리, 뭘 쓸까?

리액트 16.3 에 소개된 새로워진 Context API 파헤치기

React Redux vs Context API

React 상태 관리 Tool 사용 & 비교 - (Redux VS MobX VS Context API)

상태 관리 라이브러리의 미학: Redux 또는 MobX 를 통한 상태 관리

MobX 코어 개념

MobX 코어 개념