[React] Redux와 Redux saga 그리고 mobx

else·2023년 2월 7일
0

react

목록 보기
2/8

프로젝트를 하다보니 두 달정도의 시간이 사라졌다.

잠자고 숨쉬고 밥먹는 시간 빼고 리액트를 사용하다보니 조금씩 적응해가며

나에게 부족한 것이 무엇인지와 앞으로 주의해야할 것들이 눈에 들어왔다.

그 중 하나가 상태관리이다.


React의 가장 대표적인 상태관리 툴로는 redux와 mobX가 있다.

이번 프로젝트에서 사용한 라이브러리는 redux 이다.


Redux 와 Mobx의 차이

  • 불변성(Redux)

    • Redux를 공부하며 찾아본 모든 곳에서 전부 강조했던 특징이다.
    • 하나의 store만 가질 수 있다.
    • Redux의 모든 상태는 읽기전용 이다.
    • 상태를 변경하려면 기존의 상태를 변경하는 것이 아닌 완전히 새로운 것으로 대체해야한다.
      • 보통 스프레드 문법 (...arry)로 얕은 복사 후 대체한다.
    • Redux의 단점이자 장점이라 할 수 있는 부분이다.
      • 추적이 쉬워진다.
      • 추적이 쉬워 테스트를 하기에 용이하다.
  • 가변성 (Mobx)

    • 여러개의 store을 가질 수 있다.
    • 값을 추적하며 값이 업데이트 되는 것을 자동으로 감지한다.
      • 이 점 때문에 편리하지만 추적이 힘들어 테스트가 힘들다.
    • observer 들의 목록을 객체에 등록해 이 들을 추적하는 방식이다.

내가 선택한 것

내가 선택한 것은 Redux이다.

  • Mobx의 경우 여러개의 store를 가진다는 점
    • 큰 프로젝트의 경험은 없지만 규모가 커지면 store가 여러개 라는 것이 큰 독이 될 수 있음
  • mobx는 액션의 발행 없이 업데이트 할 수 있다는 점
    • 편리한 기능이라 생각하지만 추적이 힘들다는 점

이 외에 여러 기업에서도 redux를 채택하는 것을 보고 어렵더라도 당장 눈 앞의 편의성을 위해 공부를 포기하지 말자라는 생각으로 Redux를 선택했다.


Redux의 흐름

액션 생성 -> 어디선가 액션 호출(dispatch) -> reducer에서 데이터 처리 -> store


Redux Saga

  • saga를 쓰기위해선 동기와 비동기의 개념부터 이해해야한다.

  • react는 기본적으로 동기적으로 작동한다.

    • 그 말은 즉슨 rest API 구조의 웹페이지에서 통신의 응답을 하염없이 기다리기만 한다는 말도안되는 페이지가 만들어진다.
  • 이를 조금 도와주는 도구이자 비동기 통신을 도와주는 도구이다.

  • 액션이 일어나면(dispatch) 이를 가로채 사이에 무엇을 집어넣는(행동을 취하는) 것을 가능하게 해주는 라이브러리이다.

컴포넌트 : dispatch야 이거 실행(action)시켜줘
dispatch : 그래 reducer한테 전달할게!
saga : 잠깐만, 너 하기전에 이거 하고, reducer한테 갔다와서 이거도하고가

이런 느낌으로 이해했다. (흐름을 외우니 이해도가 낮아도 사용하기에 불편함이 없었다.)

profile
피아노 -> 개발자

0개의 댓글