Context API
context-API는 여러개를 만들 수 있으며, 모든 컴포넌트의 상태를 관리할 수도 있지만 특정 컴포넌트들만 묶어서 관리할 수도 있습니다.
Context 는 React 에서 제공하는 createContext 를 사용해서 생성할 수 있습니다.
Context 데이터를 사용할 변수에 createContext 함수의 인자값으로
관리할 State 들을 객체 형태로 담아줍니다.
State 를 설정했으니 State 값을 변경할 수 있는 set 함수도 함께 설정할 수 있겠죠?
여기까지 Context State 값의 타입을 설정했는데, 아직 State 값이 만들어진 것은 아닙니다.
useState 를 이용해 설정한 State 값들을 만들어줍니다.
방금 생성한 State 값들이 바로 위에서 설정했었던
Context 의 State 객체에 담겨져 하위 컴포넌트로 출력되는 State 가 됩니다.
반드시, Context 에 설정된 키 이름과 State 로 생성한 키 이름을
동일하게 설정해주세요!
자, 이제 그럼 생성한 State 들을
하위 컴포넌트로 뿌려주기 위한 작업을 추가해줍니다.
app.tsx 가 페이지를 그려내는 부분,
즉 return 하는 부분에서 전체 페이지들을 Context 를 감싸줍니다.
이때, Context 의 State 값을 제공한다는 의미로 Provider 기능을 사용할 수 있고,
value 값으로 전체 페이지로 전달할 State 값들을 넣어줍니다.
이제부터, value 객체에 들어 있는 모든 State 값들은
모든 컴포넌트에서 가져올 수 있는 전역 State 값을 가지게 됩니다.
🤔 사용법
- 여기까지의 글 출처 - 코드캠프
이런식으로 키값도 가질 수 있나보네요.
이렇게 프로바이더로 감싼 모든 하위 요소들은 이 value값을 언제든지 꺼내서 쓸 수 있게 됩니다.
하위요소에서 데이터를 GET하는 방법은?
- 컨텍스트를 가져온다.
- 컨텍스트 , 컨슈머를 사용한다.
- value를 사용!
컨슈머 방식을 사용 하면
<PersonContext.Consumer> //consumer =>Context 안의 값을 사용할 때는 Consumer 컴포넌트를 사용한다.
return(
{(persons) => (
<ul>
{persons.map ((person) => (
<li>{person.name}</li>
))}
</ul>
)}
</PersonContext.Consumer>
)위처럼 새로운 파일에서 Context를 가져와서 counsumer 라는 컴포넌트를 꺼낼거다 라는 선언을 해주면 app.js에서 value값으로 내렸던 persons를 꺼내서 사용할 수 있게 된다.
map을 사용해서 데이터를 풀어야했고 그 안에 name 값을 가져온것입니다.
🚨 import 잊지말기
Class 방식에서는 아래처럼 사용할 수 있다.
하지만 여기에서 단점은 static contextType은 여러개를 지정할 수 없습니다.
위 사진 상황에서 다른 context 데이터도 가져오고 싶다면 다른 방법을 사용해야 합니다.
가장 많이 사용하는 방식인데요. 맨 위에서도 보셨을겁니다!
하지만 context API는 하위요소들에게 모든 영향을 주기 때문에 한 페이지에서 데이터를 받아와 랜더링이 된다고 하면 context를 선언한 모든 페이지에서 리랜더링이 일어나기 때문에 이를 방지해주기 위해 나온것이 useRecoil 입니다.
Redux
Redux는 React앱의 상태를 중앙 집중식으로 저장하고 관리하는데 사용되는 상태관리 라이브러리 입니다.
위 사진처럼 왼쪽 빨간색 -> 오른쪽 빨간색에게 데이터를 전달해 주어야할때
초록색이 지나가는 컴포넌트들은 다 전달만 하는 컴포넌트로 사용되고 있다는것입니다.
이를 보완하기 위해서 context API를 사용하면 더 편하게 작업할 수 있다고 알고 있죠!
하지만 context를 사용할 경우에 context가 가지고 있는 전역 데이터를 잘 활용하는 부분이 중요합니다.
그래서 context에게 주어지는 전역 데이터를 어떻게 효과적으로 관리할건지에 대한 라이브러리가 Redux입니다!
그래서 리덕스를 사용하게 되면 위처럼 컴포넌트들 사이를 다니는게 아니라
redux를 들려서 전달을 해주기 때문에 효과적입니다.
그래서 이 redux를 어떻게 잘 설계하느냐가 굉장히 중요한 핵심이 됩니다.
저 파란공이 store라고 불리는데
보라색 공이 데이터를 변경하면 나머지 공들에게도 데이터를 리랜더링이 자동으로 됩니다.
하지만 설계가 중요한만큼 많은 사용구조와 복잡한 구조를 가집니다.
mobx
- 요약
데코레이터를 적극 활용한다.
cra 에 데코레이터를 사용하는 법...
스토어 객체에 붙이는 데코레이터가 있고, => @observable
컴포넌트에서 사용하는 데코레이터가 있다. => @observer
TypeScript 가 Base 인 라이브러리이다
Redux 와 마찬가지로, 스토어에 필요한 부분과 리액트에 필요한 부분이 있다.
npm i mobx -D
npm i mobx-react -D
리덕스와 다르게 단일 스토어를 강제하진 않는다
리덕스와 bobx의 비교 그래프입니다.
9배 정도 차이가 나는데도 mobx를 사용하는 회사가 꽤 많다고 하네요.
리덕스는 단일화 저장소, mobx는 원하는 섹션별 저장소를 가질 수 있다는것도 차이점이네요.
리덕스에 비해 mobx는 배우기에 쉽고 구조가 간단하다고 합니다.
그러면 MobX는 어떻길래 구조가 간단하다는 것일까? MobX는 기본적으로 Reactive Programming으로부터 영감을 받았고 Reactive Programming은 데이터의 흐름과 전파에 초점을 맞춘 프로그래밍 패러다임입니다.
Reactive Programming의 대표적인 구조는, 어떤 값이 변경이 되면 이 값이 변경되었는지 쳐다보고(Subscribing) 있는 Observer한테 알림을 줘서 리랜더링하도록 알려주는 흐름입니다.
- Mobx의 observer API가 클래스형 컴포넌트를 리턴하기 때문에, Hooks는 함수형 컴포넌트에서만 사용할 수 있다는 내용의 오류 발생
- mobx-react v6 또는 mobx-react-lite를 사용하면 위 오류 없이 Hooks를 사용할 수 있다.
- 보일러 플레이트 코드 등 작성할 것이 많은 Redux에 비해 가볍다.
- Mobx store를 전역 객체로 활용하여 각 컴포넌트에서 import해서 사용할 수 있지만, 전역 데이터를 필요로하지 않는 컴포넌트에서도 접근을 하게 되기 때문에 unit testing에 부적합하다. 따라서 context API를 활용하여 각 컴포넌트에서 데이터에 접근하는 방식을 Mobx 공식 문서에서 권장하고 있다.
swr
SWR은 무엇인가?
SWR은 Nextjs 로 유명한 vercel 에서 만든 원격데이터 fetch 를 위한 커스텀 훅 npm 모듈입니다. SWR은 원격서버의 상태를 가져와서 리액트 컴포넌트에 꽂아주는 기능을 제공합니다.
❓ 데이터의 캐싱
useSWR 은 한번 fetch 한 원격상태의 데이터를 내부적으로 캐시합니다. 즉 클라이언트에 잠시 저장을 해둔다는 말입니다.
다른 컴포넌트에서 동일한 상태를 사용하고자 할 경우, 이전에 캐시했던 상태를 그대로 리턴해줍니다!
즉 원격에 있는 데이터가 마치 클라이언트에 존재하는 것처럼 사용할 수 있다는 말이지요.
swr 편리기능
