[React] 상태 관리(2) - redux 편

Gyu.marin·2021년 9월 30일
0

redux를 왜 꼭 써야할까...

라는 생각을 react 학습 초기에 참 많이 가지고 있었습니다.
'react가 단방향 데이터 바인딩 이기 때문에' 현재 상태(state)를 다른 컴포넌트에 전달하기 어렵다. 라는 것을 지금은 알고 있죠.

회사에서도 결제를 올리려고 하면 상위의 결정권자들을 거쳐야 하기에, 엄~청 높거나, 완~전 다른 부서에 결제를 받으려면 꽤나 복잡한 과정을 거치죠.
혹시라도 중간 결제자를 실수로 등록하지 않았다면, 다시 처음부터 결제를 신청하는 경우도 있구요.

하지만 이 Redux라는 놈은 체계적으로 잘만 작성해 둔다면, 사단장님께 직통 ⭐️ 마음의 편지 ⭐️ 를 보낼 수 있습니다.

Redux

출처 : https://chanyeong.com/blog/post/21
↑ 참조하면서 글 작성 중이었는데.. 이게 그냥 저기 들어가서 보세요.ㅋㅋㅋㅋ 훨씬 깔끔하게 잘되어 있습니다.

Redux의 기본 개념

  1. Component에서 Action Creator를 통해 Action을 생성
  2. Action을 Dispath함수로 실행시켜준다.
  3. Store에서 해당 Reducer로 매칭되는 Action이 있는지 확인하고 Store에 저장된 상태를 변경

처음에는 이해가 잘 안됬는데 단순하게 생각하면,

컴포넌트 쪽에서 사용할 구현 함수를 Dispatch()를 통해 특정 Action으로 호출,
Store로 이동한 다음 Reducer에게 '너 그 액션있어?' 라고 묻습니다. 있으면 해당 로직에 따라 함수를 수행한다!그럼 컴포넌트 쪽 뷰에 뿌려지고 있는 Redux의 State가 변화하게 되는 것입니다.

Redux의 3가지 규칙

  1. 하나의 Application하나의 Store가 있다.
  2. 상태는 읽기 전용이다.
  3. 변화를 일으키는 함수, Reducer는 순수한 함수여야 한다.

(1)은 아마 상태들의 모니터링을 위한 규칙인거 같아요. '여러개의 store를 이용할 수는 있지만 권장하지 않는다.' 라는데, 사실 우리가 React에서 단방향 데이터 바인딩을 하는 이유가 그 상태들의 일관된 데이터 관리 로직을 위해 하는 것인데 여기저기 데이터(상태)들이 분산되어 있다면 React의 가치? 방향성? 과 멀어지기 때문이지 않을까 싶네요..(사견입니다.)

(2)는 뭐 useState와 같이 불변성 유지를 위한 것이죠.

(3)은 same input, same output 원칙이 순수한 함수라는 가치관에서 가지는 규칙인거 같아요.
↑ 이 놈 때문에 thuck도 모르는데 외부 API를 박을라다가 몇 일 날려 먹었죠 🤪

Redux 구조를 짤 때 저는 기본적으로는

  1. Action type (액션 타입)
  2. Action creator (액션 생성 함수)
  3. initialState (리덕스 상태들의 초기값)
  4. Reducer (Action에 따라 store의 상태에 변화를 주기 위한 switch 구조 함수)

4가지 구조로 분리해서 사용하는 편이에요.

사람들의 취향이나, 프로젝트의 상황에 따라 저 4개를 한 페이지에 구현(Ducks 패턴) 하기도 하고, 혹은 분리해서 구현하기도 하더라고요. 저는 아직 큰 규모의 프로젝트를 해본적이 없어서 왠만하면? 클론 학습 외에는 한페이지 작성하는 편이에요. 각각의 함수들이 어떤 기능을 하는지만 이해한다면, 상관 없겠죠?

리덕스 구현 순서(내 취향)

  1. src/modules/리덕스명Reducer.js를 파일 생성
    1) initalState에 사용할 상태들 구현
    2) 리덕스명Reducer 함수 생성

  2. src/modules/index.js에 rootReducer를 생성
    --> 여러개의 리듀서들을 함께 사용하기 위해

  3. src/store.js 파일 생성
    --> createStore 함수를 통해 rootReducer를 연결하고, 필요에 따라 미들웨어를 추가하기 위해

  4. src/index.js 파일에 를 추가.

이 순서대로 구조를 만들어 놓고 시작하는 편이에요.
뭐랄까... 저 순서가 마치 의수를 맞춰놓고 팔에다 꼽는 과정 같달까..?
사용은 가능한 뼈대를 만들어 놓고 이제 필요에 따라, 하나씩 추가하는 편이에요.

왠진 모르겠지만, 돌아가지 않으면 아무의미 없다? 이런 편이라서 그런가봐요.

Thuck(비통기 통신용 미들웨어)

처음엔 이거에 대한 정리를 쫌 할려했는데... 딱히 할 필요는 없을 듯 합니다.
그냥 store에 미들웨어 추가하고...

  try {
       const payload = await promiseCreator(param);
       dispatch({ type: SUCCESS, payload, param });
  } catch (e) {
       dispatch({ type: ERROR, payload: e, error: true });
  }
 

해당 구조로 관리하면 되는 거라서... 흠

링크 : https://react.vlpt.us/
리액트 개발자의 정석 밸로퍼트님 참 이해하기 쉽게 잘정리되어 있어요.

자세한건 설명은 벨로퍼트님께 맡기겠습니다.. 끝

profile
임베디드 학과 출신에 웹을 배우고 모바일 개발을 하는 개발자

0개의 댓글