context
Context를 사용하면 부모 컴포넌트가 props를 통해 명시적으로 전달하지 않고도 깊이 여부와 무관하게 그 아래 트리의 모든 컴포넌트에서 일부 정보를 사용할 수 있다.
provider
- Context의 값을 제공하는 컴포넌트
- 즉, 우리가 공유하고자하는 데이터를 value라는 속성을 통해 제공
- 가장 최상위 컴포넌트에서 provider를 설정하고, 그 값은 모든곳에서 사용가능
<MyContext.Provider value={}>
consumer
- Context 값을 소비하는 컴포넌트
- Provider에 의해 제공된 값에 접근 가능
<MyContext.Consumer>
{value => }
</MyContext.Consumer>
context 장점
전역 상태 관리
- Context API를 사용하면, 애플리케이션 전체에서 공유되어야 하는 데이터를 쉽게 관리하고 접근할 수 있다.
Props Drilling 해결
- Context를 사용하면 상위 컴포넌트에서 하위 컴포넌트로 데이터를 직접 전달할 수 있다.
이를 통해 "props drilling" 문제를 해결하고 코드의 가독성과 유지보수성을 높일 수 있다.
간단하고 간편
- 상태 관리 라이브러리를 사용하는 것에 비해 API가 간단하고 배우기 쉽다.
별도의 라이브러리를 설치할 필요 없이 React에 내장된 기능을 사용할 수 있다.
context 단점
최적화 부재
- Context API는 Provider의 값의 변경에 따라 실제로 업데이트가 필요한 컴포넌트만 렌더링된다.
- 즉, 불필요한 렌더링을 발생시킬 수 있고 성능에 부정적인 영향을 미칠 수 있다.
복잡한 상태 로직
- 상태가 복잡하고 상태 간의 상호작용이 많은 경우, Context API만으로는 상태 관리가 어려울 수 있다.
상태 간 의존성 관리
- 여러 상태 간에 복잡한 의존성이 있는 경우, 이를 관리하기가 어렵다.
context가 있음에도 왜 redux, recoil 등장?
- 위의 context 와 관련된 단점을 해결하고자 생겼다.
즉, 리액트의 context 는 provider와 consumer가 있는데, Context는 단일 값만 저장할 수 있으며, 자체 consumer를 가지는 여러 값의 집합을 담을 수는 없다! 라는 단점을 해결하고자 상태관리 라이브러리가 생겨났다.
이 프로젝트에서 context가 적합한 이유
캘린더 라이브러리 특성상, 하나의 캘린더 라는 컴포넌트가 존재하고, 캘린더 컴포넌트내의 사용자 입력으로 받은 props들이 모두 전역으로 사용되기에 다른 라이브러리를 설치하지않아도 된다는 면에서 빌드시 용량도 줄일 수 있고, context 로
전체 props를 context에 관리하여 가독성과 유지보수성을 높임
단순한 상태 관리
Props Drilling 방지
- Calendar, MonthView, BookingDatesView 등 여러 컴포넌트가 공유하는 상태가 있음.
- Context API를 사용하면 이런 상태를 쉽게 공유할 수 있으며, 각 컴포넌트에게 꼭 필요한 상태만 전달하면 되므로 props drilling을 방지할 수 있다.
프로젝트의 규모와 필요성
- 캘린더 컴포넌트 하나의 컴포넌트를 전역에서 관리하면 되기에, Context API가 적합했다.
모듈 간 결합도 줄이기
- Context API를 이용하면, 특정 부분의 상태 변경이 다른 부분에 미치는 영향을 최소화할 수 있다.
- 예를들어 각 컴포넌트나 모듈이 독립적으로 상태를 관리할 수 있게 하여, 한 컴포넌트의 변경이 다른 컴포넌트에 영향을 미치는 것을 최소화 한다
- 예를 들어, 캘린더의 현재 월 변경은 해당 월만 업데이트하면 되고, 다른 월에는 영향을 미치지 않는다.
- 이를 통해 각 컴포넌트의 재사용성을 높일 수 있습니다.
컴포넌트 간의 데이터 전달 간소화
- 여러 컴포넌트 간에 데이터를 전달할 때, 상위 컴포넌트에서 하위 컴포넌트로 직접 데이터를 전달할 수 있다.
- 이를 통해 코드의 가독성과 유지보수성을 향상시킬 수 있다.
결론
즉, context를 사용함으로써, 리액트 내장된 전역상태관리를 할 수 있었고, 캘린더 라이브러리 특성 상 하나의 컴포넌트를 전역에서 관리하기에 consumer와 provider가 사용자 입력으로 받은 Props를 관리 하기에 적절하였다고 판단하였다.