이사님께서 현재 프로젝트에 context와 redux를 함께 쓰게 될거라고 하셨다. 현재 css작업을 어느정도 마친상태이고 곧 form을 전송하는 등 작업에 들어갈텐데, 그전에 미리 알아보고자 정리해 보았다.
context는
React 와 React Admin의 React의 내장 기능인 React Context API를 의미한다. context를 사용하면 컴포넌트 계층 구조 내에서 수동으로 소품을 전달하고 또 전달 할 필요 없이 컴포넌트 간에 데이터를 공유할 수 있게 해주는 React의 내장 기능이다.
이전 프로젝트의 코드들은 Redux 또는 context를 쓰지 않은 부분도 있어서 api호출을 어디서 했으며 상태를 끌어올릴려면 어딜 통해 어디까지 올라가야하는지 찾기가 어려워 노트에 그림으로 그려서 수시로 들여다 보며 개발을 했었다.
context는 redux와 마찬가지로 수동으로 속성(prop)을 전달하고 또 전달하고 또 전달할 필요 없이 컴포넌트 트리를 통해 데이터를 전달하는 방법을 제공한다.
그러니까 컨텍스트를 사용하면 데이터를 전역으로 관리하고, 컴포넌트 트리의 어떤 계층에서든 데이터에 쉽게 접근할 수 있다. 중간 컴포넌트를 거치지 않고도 데이터를 공유할 수 있기 때문에 "컴포넌트 트리의 계층을 통해 전달하고 또 전달하고 또 전달할 필요하 없는것이다.
이건 예시로 그려본 prop전달 상태이다 ㅋㅋㅋ 상태를 전역에서 관리하지 않는경우, 컴포넌트 트리 구조에서 이런 상황이 여러개는 생길텐데,, 어디서 부터 흘러온건지 찾다가 시간이 다 가고 말것이다.
컴포넌트를 많이 나누지 않는다면 이렇게 까지 복잡하지 않겠지만 재사용성을 위해선 나누는게 좋다고 배웠고, 프로젝트를 하면서 느낀 부분이 있다. 그렇다면 react에 내장된 함수인 context api에는 어떤 것이 있을까?
React의 Context API 종류
먼저 종류를 훑어 본 후, 밑에서는 예시코드로 다시한번 언급하겠다.
User Authentication Context: 사용자 인증 정보를 저장하고 공유하는 데 사용
Theme Context: 애플리케이션의 테마와 관련된 정보를 저장하는 데 사용
Language Localization Context: 다국어 지원을 위해 사용자가 선택한 언어와 관련된 정보를 저장
Cart Context: 쇼핑 카트와 관련된 정보를 저장하는 데 사용
App Configuration Context: 애플리케이션의 설정과 관련된 정보를 저장
Notification Context: 사용자에게 알림과 관련된 정보를 저장
내가 느끼기에 묘하게 리덕스와 같은 기능을 하는것 같다. 정말 그렇다면 리덕스는 따로 안써도 되지 않을까?
그렇다.
React의 Context API를 사용하면 리덕스와 유사한 역할을 수행할 수 있다. Context API를 사용하면 전역 상태 관리, 데이터 공유, 컴포넌트 간 통신 등의 작업을 수행할 수 있다. 그러나 Context API와 리덕스 간에는 몇 가지 차이점이 있으며, 어떤 것을 선택할지는 프로젝트의 요구 사항과 규모에 따라 다를 수 있다.
리덕스와 Context API의 주요 차이점은
복잡성
리덕스는 상태 관리를 위한 도구인데, 큰 규모의 애플리케이션에서 사용하기 적합하다. 하지만 리덕스 자체가 상태 관리를 위한 별도의 패키지기 때문에 초기에 설정할때와 구성이 복잡할 수 있다. 반면에 Context API는 React 자체에 내장되어 있으며, 단순한 상태 관리 작업에는 더 적합할 수 있다.
성능
리덕스는 상태 업데이트 시에 불변성을 유지하고 액션 디스패치를 통해 업데이트를 처리하므로 성능을 최적화하기 쉽다. 반면에 Context API는 단순한 상태 공유에 대한 간단한 솔루션이기 떄문에 대규모 애플리케이션에서는 성능 문제가 발생할 수 있다. 그러나 React 18과 함께 도입된 Concurrent Mode와 Suspense를 사용하면 Context API의 성능을 최적화할 수 있다.
커뮤니티 및 에코시스템:
여기서 잠깐! 에코시스템이란?
"에코시스템"은 특정 기술을 사용하여 개발할 때 해당 기술을 지원하고 향상시키는 다양한 자원과 도구들을 의미한다. 예를 들어, 리덕스의 에코시스템은 리덕스 미들웨어, 리덕스 개발 도구, 관련 라이브러리 및 다양한 커뮤니티 활동으로 구성된다. 이런것은 리덕스를 사용하여 상태 관리를 더 효과적으로 수행하고 복잡한 애플리케이션을 구축하는 데 도움이 된다.
리덕스는 커뮤니티와 다양한 미들웨어 및 도구에 대한 아주 풍부한 에코시스템을 가지고 있다. 그렇기 때문에 여러 상황에 대처하기 위한 다양한 확장 기능과 라이브러리를 활용할 수 있다. 반면에 Context API는 더 단순한 상태 관리에 중점을 둔다는 측면에서 에코시스템에서는 제한적일 수 있다.
context vs redux
따라서 프로젝트의 규모와 복잡성, 개발자의 경험, 함께 프로젝트를 하는 구성원의 선호도 등에 따라 Context API 또는 리덕스를 선택할 수 있다. 더 간단한 작업에는 Context API가 충분하고, 큰 규모의 애플리케이션 또는 복잡한 상태 관리를 필요로 하는 경우에는 리덕스와 같은 라이브러리를 사용하는것을 고민해 보고 결정할 수 있다.
그러면 두개를 동시에 적절히 섞어서 사용할 수 있을까?
동시에 사용할 수 있다. 이러한 방식으로 두 가지 상태 관리 솔루션을 조합해서 프로젝트 특정 요구 사항에 더 적합한 솔루션을 선택할 수 가 있다. 그럼 섞어서 사용한다면 어떤 장점이 있을까? 굳이 섞어서 사용할 필요가 있을까?
context와 redux를 섞어 사용하면 좋은점
모듈화:
Context API와 리덕스를 조합하면 각각의 장점을 활용할 수 있다. 예를 들어, 간단한 로컬 상태 관리에는 Context API를 사용하고, 글로벌 상태 또는 복잡한 상태 관리에는 리덕스를 사용할 수 있다.
성능 최적화:
어떤 상태는 리덕스로 관리하고 어떤 상태는 Context API로 관리하여 성능을 최적화할 수 있다. 더 많은 최적화가 필요한 상태는 리덕스로 처리하고, 단순한 상태는 Context API로 처리할 수 있다.
팀 협업:
팀 구성원 각각이 리덕스와 Context API를 사용하는 데 익숙할 수 있으므로, 각자 선호하는 방식으로 상태 관리를 할 수 있다. 라고 하지만, 난 이 것은 큰 장점이라 생각하지 않는다. 각자 선호하는 방식으로 제각각 개발하는것보다 처음에 모두 규칙이 다 있는게 추후에 유지보수할때에도 인수인계 할때에도 좋을 것 같다.
마이그레이션:
이미 기존 프로젝트에서 리덕스를 사용하고 있다면, 기존 리덕스 상태를 유지하면서 새로운 기능을 Context API로 개발하고 나중에 전환하는 것이 가능하다.
여기서잠깐!
마이그레이션은 주로 새로운 시스템으로 전환하거나 업그레이드하는 경우에 발생하며, 기존 데이터와 기능을 손실없이 새로운 환경으로 이동하기 위해 사용한다.
이러한 조합을 사용하려면 다음과 같은 방식으로 구현할 수 있다:
Context API를 사용하여 일부 컴포넌트 또는 로컬 상태를 관리한다.
리덕스를 사용하여 글로벌 상태 또는 복잡한 상태를 관리한다.
필요한 경우, 리덕스와 Context API 간에 데이터를 공유하고 연동한다.
두 가지 상태 관리 솔루션을 동시에 사용할 때 주의해야 할 점은 복잡성을 효과적으로 관리하고 불필요한 중복을 피하는 것이다. 너무 많은 상태 관리 솔루션을 사용하면 코드를 이해하기 어려워질 수 있으므로 신중하게 선택하고 구현해야만 한다.
위의 내용대로라면 굳이 두개를 동시에 쓸 필요 또한 없다.
Redux와 Context API 중에서 하나를 선택하여 프로젝트를 개발하는 것이 코드 일관성을 유지하는 데 도움이 된다. 어느 한 가지 상태 관리 방법만 선택하면 복잡성을 줄일 수 있으며 개발자들이 프로젝트의 코드를 이해하기 가 쉬워진다.
context API 의 예시 코드를 통해 좀 더 알아보자.
1. User Authentication Context:
사용자의 인증 정보를 저장하고 관리하는 예시 코드다. 사용자가 로그인을 하면 사용자 정보를 컨텍스트에 저장하고 로그아웃하면 지운다.