📍 context API란?

Context API 란 부모 컴포넌트가 어떠한 정보(데이터)를 만들고, 자신의 자식 컴포넌트들은 모두 해당 데이터를 사용할 수 있도록 만들어 props를 사용하지 않고 필요한 데이터를 넘겨주며 쉽게 값을 공유할 수 있게 해주는 리액트에 내장된 기능이다.

다시 말해, React의 context는 컴포넌트들이 데이터(state)를 더 쉽게 공유할 수 있도록 해준다.

🤔 context를 왜 사용하는데?

✅ 너무 많은 prop drilling을 하지 않기 위해!

React 에서의 데이터 전달은 일반적으로 부모 컴포넌트 -> 자식 컴포넌트의 방향으로 props를 이용한 단방향 데이터 전달 흐름이 일어난다.

이때 state를 사용하고자 하는 자식을 목표 자식 이라고 표현했을 때

1. 부모 ➡️ 자식 ➡️ 자식 ➡️ 자식 ➡️ 목표 자식
2. 부모 ➡️ 목표 자식 ➡️ 목표 자식 ➡️ 목표 자식 ➡️ 목표 자식

이러한 경우들에서는 너무 많은 prop drilling이 발생할 수 있으므로 context API를 사용하게 된다.

❓ prop drilling이란 ?

props를 통해 데이터를 전달하는 과정에서 중간 컴포넌트는 그 데이터가 필요하지 않음에도 자식 컴포넌트에 전달하기 위해 props를 전달해야하는 과정을 말한다.

( prop이 드릴처럼 컴포넌트를 뚫고 가는 것처럼 보인다고 하여서 prop drilling이라고 한다네요! )

🧐 prop drilling이 문제가 되는 상황

상태 끌어올리기를 할 때 컴포넌트들의 공통 조상이 너무 위에 있는 경우 불필요하게 많은 prop drilling을 일으킬 수 있다.

💡 상태 끌어올리기(lifting state up)란?

동일한 데이터에 대한 변경사항을 서로 다른 컴포넌트에 반영해야 할 필요가 있는 경우, 해당 state를 서로 다른 컴포넌트들의 가장 가까운 부모(공통 조상)에 정의하여두고 props를 통해 해당 state를 두 개의 컴포넌트로 전달하는 방법

이렇게 너무 많은 prop drilling을 막아주기 위해 React의 Context API를 사용하게 된다. 필요없는 단계를 거쳐 데이터를 전달하지 않고 해당 데이터를 필요로 하는 component에 직접적으로 데이터를 전달할 수 있게 된다.

---

📍 Context API를 사용해보자!

✅ useContext의 가장 중요한 세가지 키워드

1. createContext :context 만들기

2. Context.provider : context를 업데이트하고, 자식들한테 뿌려주기

3. useContext : context값이 필요한 컴포넌트에서 context 사용하기

1️⃣ createContext

말 그대로 컴포넌트들이 provide하고 사용할 수 있도록 context 만들기

// someContext.js
import { createContext } from 'react';

const SomeContext = createContext(defaultValue);

export default someContext;

🧐 인자로 받는 defaultValue란?

createContext는 default값을 인자로 받는다. 이때 default값은 어느 타입이 들어가도 상관 없다. (객체도 가능,함수도 가능)
default값은 context를 사용하려는 컴포넌트에게 매칭되는 provider를 찾지 못했을 경우 (해당 컴포넌트를 감싸는 provider가 없는 경우)에 context의 값으로 사용된다.
default값을 설정해두지 않고 provider로 감싸지 않은 컴포넌트에서 context값에 접근하게 된다면 context는 undefined의 값을 반환한다.

📝 간단한 코드 예시

1. context.js에서 createContext
   (1번 경우와 2번 경우를 독립적으로 생각해보자 !)

// context.js
import { createContext } from 'react';

// 1. default 값 정의해두지 않음
const SomeContext = createContext();
// 2. default 값 정의해둠
const SomeContext = createContext('default value');

export default someContext;

2. context값을 사용하려는 FirstComponent를 provider로 감싸지 않음

// App.js
import FirstComponent from "./FirstComponent";

export default function App() {
  return (
    // provider로 감싸지 않음
    <FirstComponent />
  );
}

3. FirstComponent에서 useContext를 통해 context값에 접근

// FirstComponent.js
import { useContext } from "react";
import SomeContext from "./context";

function FirstComponent() {
  const value = useContext(SomeContext);
  return <div>First Component says: "{value}"</div>;
  // 1. First Component says: (빈 값으로 나옴)
  // 2. First Component says: default value
}

💡 하지만 꼭 createContext를 할 때 default값을 설정해야 하는 것은 아니다. default값을 빈 값으로 설정하고 provider에서 직접 설정하는 경우도 있다.

2️⃣ useContext

"이 컴포넌트에서 createContext로 정의되어 있는 context를 읽고 사용하고싶대 ~ 라고 말해주는 과정" 으로 context값을 사용하려는 컴포넌트에서 useContext hook을 사용하여 전달받는 과정이다.

useContext는 createContext에서 만든 context값을 읽고 변화를 감지하여 리렌더링한다.

📝 간단한 코드 예시

// FirstComponent.js

// 1. useContext import하기
import { useContext } from "react";
// 2. 만들어둔 context import하기
import SomeContext from "./context";

function FirstComponent() {
  // 3. useContext 사용해서 context값 읽기, 변화감지
  const value = useContext(SomeContext); 
  return <div>First Component says: "{value}"</div>;
}

export default FirstComponent;

👀 이때 주의할 점은 useContext도 hook의 일종이므로 당연히! hook의 규칙을 따라야 한다

🫣 여기서 hook의 규칙 잠깐 짚고 넘어가자면~

1. 리액트 hook은 리액트 함수 내부에서만 호출되어야 한다.
즉 리액트 컴포넌트 함수 또는 custom Hook에서만 호출되어야 한다.

2. 최상위 수준에서 사용되어야 한다.
중첩함수의 내부라던가 if문 내부라던가 .. 함수의 내부에 사용하면 에러가 발생한다. 가장 최상위단에서 사용해야 한다!

3️⃣ Context.Provider

provider는 1. 어디에서 2. 어떻게 이 context값을 사용하고 싶은데? 를 정해서 알려주는 과정이라고 생각하면 된다.

1. 어디에서

내가 context를 사용하고자 하는 컴포넌트들의 상단을 provider로 묶어주어서 알려준다.

1-1. 이때 특정 컴포넌트만을 묶어줄 수도 있고
1-2. {children}을 provider로 감싸서 하위의 모든 컴포넌트에서 context를 사용하도록 할 수 있다.

2. 어떻게

provider의 value를 업데이트 해서 context 값을 변경해준다.
여기서 value 속성은 provider에서 정해져 있는 props의 이름이다.

📝 간단한 코드 예시

// 1-1) FirstComponent 내부에서의 context값은 'seojin'으로 줘!
// App.js
import FirstComponent from "./firstcomponent";
import SomeContext from "./context";

export default function App() {
  return (
    // context값을 'seojin'으로 업데이트 해줘!
    <SomeContext.Provider value={'seojin'}>
      <FirstComponent />
    </SomeContext.Provider>
  );
}

// 1-2) section 안에 있는 어떠한 컴포넌트든 context를 요청하면, 이 contextValue값을 줘 !
// section.js
import SomeContext from "./context";

export default function Section({ contextValue, children }) {
  return (
    <section className="section">
      <LevelContext.Provider value={contextValue}>
        {children}
      </LevelContext.Provider>
    </section>
  );
}

❓ 여러개의 provider로 감싸져 있으면 어느 value값을 사용하지?

context를 요청한 컴포넌트는 자신과 가장 가까운 provider를 찾아가서 해당 provider가 제공하는 value값을 사용한다!

🧐 provider를 사용하지 않는 경우

1️⃣에서 defaultValue를 말했던 것과 같이 provider로 감싸지지 않은 컴포넌트에서 useContext를 통해 context값에 접근하면 createContext에서 정의한 defaultValue로 접근 된다. 만약 default값이 없다면 undefined로 접근된다.

💡 에러는 따로 발생하지 않으므로 에러를 잡고싶다면 따로 에러처리가 필요하다 ,,

😎 정리

1. context 만들기
2. context를 사용하고자 하는 컴포넌트를 provider로 감싸기, 사용할 context값 value 속성 이용해서 업데이트하기
3. context 값을 사용하고자 하는 컴포넌트에서 useContext를 통해 context값에 접근
4. provider에서 value 속성을 통해 업데이트한 context를 보고 실제 컴포넌트에서 렌더링~

---

📍 context API 톺아보기

🤔 다수의 context들은 독립적인가요?

YES ⭕️

createContext()로 지정된 서로 다른 context들은 서로 절대 영향을 끼치지 않는다. 때문에 하나의 컴포넌트에서 여러 개의 서로 다른 context를 use하고 provide하는 것이 가능하다.

🚨 문제점! - 리렌더링 이슈

🤔 provider로 감싸진 하위 컴포넌트들은 상위 컴포넌트가 변경된 경우 모두 리렌더링 될까?

YES ⭕️

Context가 전송하는 value 데이터는 객체 형태이다. 따라서 객체에서 하나의 데이터만 변경되어도 Provider로 감싼 모든 자식 컴포넌트에서 리렌더링이 일어난다.

Provider로부터 하위 consumer로의 전파는 shouldComponentUpdate 메서드가 적용되지 않는다!

💡 shouldComponentUpdate란

최적화를 위한 라이프 사이클로 이전 state, props와 현재 state,props를 비교해 달라지지 않았다면 리렌더링을 하지 않게 하는 최적화 기법

1. 예를들어 FirstName 컴포넌트에서는 NameContext.firstName 값만을 사용하고 FamilyName 컴포넌트에서는 NameContext.familyName 값만을 사용하지만, FirstName 컴포넌트에서 값을 수정시 FamilyName 컴포넌트에서 리렌더링이 발생한다.

2. useContext를 사용하지 않는 컴포넌트 또한 provider로 감싸져 있으면 provider에 의해 context값이 변경될 경우 모두 리렌더링 된다.
   여기서 상태가 변경된다는 것은 참조값일 경우 실제로(우리가 보기에) 값이 변하지 않았어도 메모리 주소가 바뀌기 때문에 계속 새로운 값으로 인지하여 리렌더링이 발생하게 된다.

3. 원시값일 경우에도 Provider 하위에서 context를 구독하는 모든 컴포넌트는 Provider의 value prop가 바뀔 때마다 다시 렌더링 된다.

결국 쓸데없는 리렌더링이 동작하게 될 수 있다

🤔 react context 최적화 방법은?

1. Context를 쪼개서 여러 개 사용

NameContext.firstName 와 NameContext.familyName 를 따로 정의하는 context 2개로 분리하여 사용하기
혹은 NameStateContext, NameDispatchContext와 같이 상태값만 관리하는 context와 상태 변화 함수를 관리하는 context로 분리하기

2. 관련 없는 컴포넌트를 React.memo()로 감싸서 자식 컴포넌트의 불필요한 리렌더링 방지

3. Context 데이터를 가지고 있는 컴포넌트에 useMemo hook을 이용하여 데이터 캐싱을 통한 불필요한 리렌더링 방지

하지만 이러한 방법들은 코드의 가독성이 떨어지고 유지보수가 힘들다는 단점이 있다.
뭐든 tradeo-ff가 발생한다.. 😭

👀 context API를 남용하지 말자!

몇 단계의 props 전달을 거쳐야 한다고 해서 무조건 context 써야지~ 는 좋지 않은 생각이다.
context API를 남용할 경우 위와 같은 리렌더링으로 인한 성능 저하가 발생하고, 컴포넌트 재사용하기 어려워진다는 문제점이 발생한다.

때문에 context API를 쓰기 전에 고려할 단계로는

1. 일단 props 전달로 시작하기

props가 가장 기본인 데이터 전달 방법이다. 가장 직관적으로 어떤 데이터를 사용하고 전달하는지 파악할 수 있기 때문에 우선은 props로 접근하자!

2. component composition 활용하기!

중첩된 layer를 줄이려는 노력으로 {children} 을 적극 사용해보자!
말 그대로 props를 사용하지는 않고 전달만 하는 용도의 컴포넌트(prop drilling)가 발생한다면 Component 자체를 props처럼 넘겨주는 것을 말한다.

<Layout posts={posts} />
//대신에

<Layout>{children}</Layout> 
// 로 해서 실제 렌더링 될 때는 

<Layout><Posts posts={posts} /></Layout>
// 이렇게 될 수 있도록!

🤯 그럼 context는 언제 쓰는게 좋은데?

1. 전체 레이아웃의 테마 적용할 때 (ex.다크모드)

app의 가장 상단에 provider를 두고, light/dark context를 직접 지정하여 테마 변경할 수 있도록할 때

2. 현재 로그인한 유저 정보

여러 컴포넌트에서 현재 유저가 누군지에 대한 정보 필요할 때 context로 정의해서 사용

3. redux를 대체하기 위한 상태관리

useReducer와 useContext를 같이 사용하여 redux를 대체하는 경우!

등등이 있다!

📍 useReducer와 useContext의 시너지

이 부분은 ! 실습시간에 코드를 통해 다루어 볼 예정입니다 🫶🏻

🤔 redux와 context API의 차이점은?

1. context API는 react에 내장되어 있지만 Redux는 그렇지 않다.
2. context API는 상태 관리 도구가 아닌 반면 Redux는 상태 관리를 해준다!

💡 잠깐! 그래서 상태 관리 조건이 뭔데?

1. 초기값 저장 가능
2. 현재 값 읽을 수 있다.
3. 값 업데이트가 가능하다

🤯 context API의 상태 관리

전역적으로 상태를 공유해주는 기능만을 수행하고 상태관리 자체는 직접 해야한다. useState와 useReducer를 같이 사용하여 provider의 value에 직접 state 혹은 action, dispatch fn 와 관련된 값을 넣어서 상태 관리를 수행하게 된다!

🤯 Redux의 상태 관리

1. 초기값 저장 : store에 초기값 지정
2. 현재값 읽기 : useSelector을 통해서 state 읽기 가능
3. 값 업데이트 가능 : reducer에 action 객체를 전달(dispatch)해서 state 업데이트 가능

😇 그럼 언제 Redux를 쓰고 언제 Context api를 써야하지?

• 단순 prop-drilling 을 피하는 것이 목적이라면 Context 를 사용하기
• 적당히 복잡한 컴포넌트가 있거나 외부 라이브러리를 사용하고 싶지 않다면 Context + useReducer 를 사용하기
• 특정 구성 요소만 re-render 시키거나, 사이드이펙트를 줄이기 위해 더 강력한 기능이 필요하다면 Redux + React-Redux 를 사용하기

참고 ) Context API vs Redux 😇