React에서 Props와 State는 부모 컴포넌트와 자식 컴포넌트 또는 한 컴포넌트 안에서 데이터를 다루기 위해 사용된다. 이 Props와 State를 사용하게 되면 부모 컴포넌트에서 자식 컴포넌트.
즉, 위에서 아래, 한쪽으로만 데이터를 줄 수 있다.
만약 다른 컴포넌트에서 한 쪽으로만 가는 데이터를 사용하고 싶은 경우 또는 다른 컴포넌트에서 사용하고 있는 데이터를 현재의 데이터 흐름에 넣고 싶은 경우가 발생하면 어떻게 해야할까?

Context api

React에서는 Flux라는 개념을 도입했고, 그에 걸맞은 context API를 제공했다.

context는 부모 컴포넌트로부터 자식 컴포넌트로 전달되는 데이터의 흐름과 상관없이
전역적인 데이터를 다룰 때 사용한다.
전역 데이터를 Context에 저장한 후, 데이터가 필요한 컴포넌트에서 해당 데이터를 불러와 사용가능하다.

React에서 Context를 사용하기 위해서는 Context API를 사용해야 하며,
Context의 Provider와 Consumer를 사용해야 한다.

Context에 저장된 데이터를 사용하기 위해서는 공통 부모 컴포넌트에 Context의 Provider를 사용하여 데이터를 제공해야 하며,
데이터를 사용하려는 컴포넌트에서 Context의 Consumer를 사용하여 실제로 데이터를 사용한다.

출처

redux

리액트에서 가장 많이 사용되는 상태 관리 라이브러리중 하나이다.
리덕스를 사용하면 컴포넌트의 상태 업데이트 관련 로직을 다른 파일로 분리시켜서 효율적으로 관리할 수 있다.

redux의 세 가지 원칙
1. Single source of truth
하나의 애플리케이션 안에는 하나의 스토어만 사용하자는 원칙이다.
이렇게 하면 애플리케이션의 디버깅이 쉬워지고 서버와의 직렬화가 될 수 있고 쉽게 클라이언트에서 데이터를 받아들여올 수 있게 된다.
2. State is read-only
상태를 변화시키는 방법은 오직 액션을 일으키는 것이다. 이것은 상태를 변화시키는 의도를 정확하게 표현할 수 있고, 상태 변경에 대한 추적이 용이해지게 된다.
3. Changes are made with pure functions
변화를 일으키는 리듀서 함수는 순수한 함수여야 한다.
출처

mobx

MobX는 전역 상태 라이브러리다. 모든 상태변화롤 일어나는 부분으로 자동으로 추적해주는 역할을 한다.
MobX는 functional reactive programming을 투명하게 적용함으로써 상태 관리를 쉽고 확장성 있게 만들어주는 검증된 라이브러리입니다. (TFRP, Transparent Functional Reactive Programming)

MobX는 다음과 같은 특징을 가지고 있다.

• React에 종속적인 라이브러리가 아님
• 아키텍처나 상태 컨테이너가 아닌 라이브러리
• redux와 다르게 store에 제한이 없음
• 또한 redux에서 해줘야했던 action 선언, connect, mapStateToProps, mapDispatchToProps등 번거로운 작업들은 데코레이터로 간단하게 대체
• observable을 기본적으로 사용하고 있음
• Mobx는 절대적으로 필요한 경우에만 state 변경
• Typescript를 기반으로 만들어짐

Redux 와 MobX의 차이점
Redux는
리엑트스러움 - 불변성 유지가 중요
flux 아키텍처를 따름
flux : 먼저 보낸 택배가 먼저 배송지에 도착해야 한다는 규제
단일 스토어, 함수형 프로그래밍, 미들웨어
dispatch 관리를 위해 redux-thunk, redux-saga 등의 미들웨어가 필수
함수형 프로그래밍에 익숙하지 않으면 힘들 수 있음
action, reducer, dispatch…

MobX는
객체지향적
단일스토어를 강제하지 않음
불변성을 신경쓰지 않아도 됨
데코레이터 사용
Redux보다 사용이 쉬움
몇가지 규칙 으로 최적화
컴포넌트 단위를 작게 만들기
리스트를 렌더링 할 땐 리스트 내용 외의 값이 props 로 들어가는것을 방지하기

출처

swr

"SWR"이라는 이름은 HTTP RFC 5861에 의해 알려진 HTTP 캐시 무효 전략인 stale-while-revalidate에서 유래되었다.
SWR은 먼저 캐시(스태일)로부터 데이터를 반환한 후, fetch 요청(재검증)을 하고, 최종적으로 최신화된 데이터를 가져오는 전략이다.

특징

• 빠르고, 가볍고, 재사용 가능한 데이터 가져오기
• 내장된 캐시 및 요청 중복 제거
• 실시간 경험
• 전송 및 프로토콜에 구애받지 않음
• SSR / ISR / SSG support
• TypeScript 준비
• React Native