Data Fetching 라이브러리

1. State Management(상태관리)

React_14_2

Context API (리액트 기본 문법)

props 전송없이 state 공유 가능
2가지 문제 때문에 많이 쓰이지 않음
- state 변경시 쓸데없는 컴포넌트까지 전부 재렌더링되어 성능 이슈
- 컴포넌트 재활용이 어려움
Context API보다는 redux같은 외부 라이브러리를 많이 사용

1.1 왜 상태 관리 도구가 필요한가?

React에서 State는 component 안에서 관리됨
자식 컴포넌트들 간의 다이렉트 데이터 전달은 불가능
자식 컴포넌트들 간의 데이터를 주고 받을 때는 상태를 관리하는 부모 컴포넌트를 통해서 주고 받음
그런데 자식이 많아진다면 상태 관리가 매우 복잡해짐
상태를 관리하는 상위 컴포넌트에서 계속 내려 받아야한다. → Props drilling 이슈
그래서 상태 관리의 복잡성을 해결해주는 라이브러리를 활용함

1.2 State Management 라이브러리 종류

props 없이 state를 공유할 수 있게 도와주는 라이브러리들

Context API Docs✅
Recoil✅
- Context 만을 사용하여 글로벌 상태 관리를 하는 것이 어느정도 제한이 있어서,
- Meta 개발팀에서 이를 개선하기 위해 만든 상태 관리 라이브러리
- 공식적으로는 23/01 기준 experimental 단계
Jotai✅
- Recoil과 비슷한 라이브러리
- Recoil이 공식적으로 experimental 단계라면, Jotai는 이미 stable한 라이브러리
Redux Toolkit - Redux✅
- 옛날부터 써왔던 라이브러리라 사용자가 가장 많음
- 2022 통계에 따르면 약 48%의 개발자들이 리액트 프로젝트에서 리덕스 사용
- 그래서 유지보수를 하고 있는 프로젝트에서 리덕스를 사용중이기 때문이 확률이 큼
- Redux 만든사람이 Redux의 문제점을 인식하고, Redux를 개선한 Redux Toolkit을 만듬
- 리덕스는 리액트에 종속되는 라이브러리가 아님
- 다른 UI 라이브러리/프레임워크와 함께 사용 가능
- cf. Velog - 리덕스(Redux)는 왜 쓰는 건데⁉
- cf. Velog - Redux 어떻게 써야 잘 썼다고 소문이 날까?
- cf. https://ko.redux.js.org/introduction/installation
- 리덕스의 문제점
  - 보일러 플레이트가 많음
    - 단순히 하나의 상태를 바꾸기 위해서 요청을 전달하는 action을 만들고,
    - 상태를 바꿔주는 reducer를 만들고, 필요에 따라 middleware까지 만져야 함
  - 특정 어플리케이션에서는 과한 기술일 수 있음
    - 상태가 별로 없으면 props 쓰는 게 편함
MobX
- 상태 관리 라이브러리
- React, Angular, Vue, Node.js 등 다양한 환경에서 사용 가능
- React에서 사용할 때는 MobX-react라는 라이브러리를 같이 사용
- Redux와 비교했을 때, 더 간단하게 사용 가능
Zustand - Official Website
- Zustand는 독일어로 상태라는 의미

1.3 전역 상태 관리 라이브러리는 언제 쓰나?

cf. Velopert - Velog 리액트에서 Context API 잘 쓰는 법
과거에는 리액트의 Context가 굉장히 불편해서 전역 상태 관리 라이브러리를 사용하는 것이 당연했음
이제는 사용하기 편해져서 단순히 전역적인 상태를 관리하기 위함이라면 더 이상 사용해야 할 이유X
단, 상태 관리 라이브러리는 상태 관리를 더욱 편하고, 효율적으로 할 수 있게 해주는 기능들을 제공해주는 도구임
e.g. Redux의 경우
- 액션과 리듀서라는 개념을 사용하여 상태 업데이트 로직을 컴포넌트 밖으로 분리
- 상태가 업데이트 될 때 실제로 의존하는 값이 바뀔 때만 컴포넌트가 리렌더링 되도록 최적화
e.g. MobX의 경우
- Redux와 마찬가지로 상태 업데이트 로직을 컴포넌트 밖으로 분리
- 함수형 리액티브 프로그래밍 방식을 도입하여 mutable한 상태가 리액트에 보여지게 해줌
- 상태 업데이트 로직을 더욱 편하게 작성할 수 있게 해주며 최적화
e.g. Recoil, Jotai, Zustand의 경우
- Context를 일일이 만드는 과정을 생략하고 Hook 기반으로 아주 편하게 전역 상태 관리

1.4 MVC 패턴과 Flux 패턴

1.4.1 MVC 패턴

react_19_1

MVC 패턴(Model-View-Controller)

데이터를 다루는 로직(Controller), 데이터(Model), 사용자 인터페이스(View)를 나누어 어플리케이션을 구현하는 하나의 개발 모델
Controller는 Model의 데이터를 조회하거나 업데이트하는 역할을 하며, Model의 변화는 View에 반영

1.4.2 MVC 패턴의 문제점

react_19_2

기존 MVC 패턴을 가진 대규모 애플리케이션에서 구조가 너무 복잡해지고 예측성이 떨어지는 문제점에 직면

MVC 구조는 앱이 커지면서 굉장히 복잡해졌다고 한다.
View가 다양한 상호작용을 위해 여러개의 Model을 동시에 업데이트하는 상황이 나타났기 때문

이 문제를 해결하기 위해서는 좀 더 예측 가능한 형태로 코드를 구조화하는 것이 필요했고,

Facebook은 React와 Flux를 이용해서 그것을 달성하고자 했다고 한다.

1.4.3 Flux 패턴

Flux 패턴 : 단방향 데이터 흐름을 가지는 패턴

react_19_3

Action
- 첫 흐름을 발생시키는 요소이며 Dispatcher에게 해당 액션 메시지를 보내줌
- **타입(type)**과 **데이터(payload)**를 가지고 있다

1{
2  "type": "EVENT_TYPE",
3  "data": {
4    "name": "Huurray"
5  }
6}

Dispatcher
- Flux의 모든 데이터 흐름을 관리하는 중앙허브
- Store들이 등록해놓은 Action Type에 대한 맞춤 Callback이 있다.
- 그래서 Action이 넘어오면 Store들이 타입에 맞는 Store의 Callback을 실행하도록 해준다.
Store
- 데이터와 데이터를 가공하는 로직을 가지고 있다.
- Action이 넘어오면 등록된 Callback을 활용해 타입에 맞는 로직을 실행하고 데이터를 업데이트해준다.
- Store는 변경된 데이터를 View에게 알려주고,
- 자신의 컴포넌트 트리에 속해 있는 자식 노드 모두를 다시 랜더링하게 한다.
View
- Flux에서의 View는 MVC의 뷰와는 달리 화면을 보여주는것 외에도 Controller의 성격또한 가지고 있다.
- 최상위 View는 Store에서 데이터를 가져와 이를 자식 View 로 내려보내주는 역할을 하고 있다.
- 각 요소들은 단방향 흐름에서 순서대로 역할이 수행되고,
- 또 다시 새로운 데이터 변경이 있으면 처음부터 이 흐름이 다시 시작된다.
- 이렇게 하면 데이터 처리에 예외가 없다.
- Facebook은 이 Flux 패턴을 고안하고 View의 역할로 React를 이용했다.

1.5 immutability(불변함)

mutate = 변화하다
mutable = 변화 가능한
mutability = 변화가능함
immutability = 변화가능하지 않음
- 데이터의 원본이 훼손되는 것을 막는 것을 의미

데이터의 CRUD(Create, Read, Update, Delete) 중에 중요한 건 Create, Read입니다. 생성이 없다면 읽을 수 없음, 모든 정보는 존재하고 있다면, 생성과 읽기로 이루어짐. 이를 원본(origin)이라고 함

그 다음으로 중요한 건 수정과 삭제입니다. IT에서 수정과 삭제는 흔한 일이지만, 수정과 삭제가 안되거나 힘든 시스템이 있습니다. e.g. 인쇄되어 배포된 종이책, 역사, 회계, 블록체인

이처럼 많은 정보들이 불변할 수 밖에 없습니다. 그렇지만 인터넷에서 가변(수정, 삭제)는 너무 쉽게 일어납니다. 무질서한 수정과 삭제로 원본이 훼손되는 것을 막는 방법을 살펴볼 것입니다. cf. 그렇다고 수정과 삭제가 꼭 나쁜 것만은 아닙니다.

01-React Router Redux/Toolkit