상태 관리 가이드

GitLab에서는 클라이언트 상태 관리를 위해 두 가지 솔루션인 Apollo와 Pinia를 지원합니다.

이 두 가지 중 하나를 기본 상태 관리자로 선택하는 것은 간단하지 않습니다.

이 페이지는 이러한 선택을 하는 데 도움이 되는 일반적인 안내를 제공합니다.

GitLab 코드베이스에서 Vuex를 볼 수도 있습니다. Vuex는 GitLab에서 더 이상 지원되지 않습니다 그리고 새로운 Vuex 저장소는 생성되지 않아야 합니다.

앱에 Vuex 저장소가 있는 경우 마이그레이션을 고려하세요.

상태와 데이터의 차이

데이터는 사용자가 상호작용하는 정보입니다.

일반적으로 외부 요청(그래프QL 또는 REST)이나 페이지 자체에서 가져옵니다.

상태는 사용자 또는 시스템 상호작용에 대한 정보를 저장합니다.

예를 들어, 모든 플래그는 상태로 간주됩니다: isLoading, isFormVisible, 등.

상태 관리는 상태와 데이터 모두 작업하는 데 사용될 수 있습니다.

상태 관리가 필요한가요?

애플리케이션에서 우선 표준 Vue 데이터 흐름을 사용하는 것이 좋습니다:

컴포넌트는 로컬 상태를 정의하고 이를 props를 통해 하위 컴포넌트에 전달하며 이벤트를 통해 변경합니다.

그러나 상태가 이 상태를 정의한 컴포넌트의 직접적인 자손이 아닌 여러 컴포넌트 사이에서 공유되는 복잡한 경우에는 이것이 충분하지 않을 수 있습니다.

그 상태를 애플리케이션의 루트로 올리는 것을 고려할 수 있지만, 이는 결국 루트 컴포넌트를 부풀게 만들고 한 번에 너무 많은 작업을 하게 만듭니다.

이 복잡성을 처리하기 위해 상태 관리 솔루션을 사용할 수 있습니다.

아래 섹션들은 이 선택을 도와줄 것입니다.

여전히 불확실하다면, Pinia보다 Apollo를 사용하는 것을 선호하세요.

Apollo

Apollo, 우리의 GraphQL API에 대한 주요 인터페이스는 클라이언트 측 상태 관리자로도 사용될 수 있습니다.

GraphQL 및 Apollo에 대해 자세히 알아보세요.

장점

GraphQL 요청에서 데이터를 작업하는 데 적합하며, 기본적으로 데이터 정규화를 제공합니다.
GraphQL이 없을 때 REST API에서 데이터를 캐시할 수 있습니다.
쿼리는 GraphQL 스키마에 대해 정적으로 검증됩니다.

단점

클라이언트 상태 관리에는 Pinia보다 더 복잡하고 수동적입니다.
Apollo DevTools: 우리의 페이지 대부분에서 제대로 작동하지 않으며, Apollo Client 오류를 추적하기 어렵습니다.

Apollo를 선택하세요

GraphQL API에 의존하는 경우
다음과 같은 특정 Apollo 기능이 필요한 경우:

Pinia

경고:

파일럿 단계: Pinia를 신중하게 채택하세요.

GitLab에서 새로운 기술이며, 아직 모든 필요한 예방 조치와 모범 사례를 갖추지 못했을 수 있습니다.

Pinia를 사용하는 것을 고려하고 있다면, 평가를 위해 #frontend 내부 Slack 채널에 메시지를 남겨주세요.

Pinia는 Vue의 권장 클라이언트 측 상태 관리 도구입니다.

GitLab에서 Pinia에 대해 더 알아보세요.

강점

간단하지만 강력함
경량으로 약 1.5kb(에 의해 Pinia 사이트에서 인용됨)
내부적으로 Vue 반응성이 있으며, Vuex와 유사한 API
디버깅이 용이함

약점

기본적으로 고급 요청 처리를 할 수 없음(데이터 정규화, 풀링, 캐싱 등)
안내 없이 Vuex와 같은 함정에 빠질 수 있음(과도한 스토어)

다음과 같은 경우 Pinia를 선택하세요

Vue 애플리케이션 상태의 상당 부분이 클라이언트 측 상태인 경우
Vuex에서 마이그레이션하는 것이 높은 우선순위인 경우
귀하의 애플리케이션이 주로 GraphQL API에 의존하지 않으며, 가까운 미래에 GraphQL API로의 마이그레이션 계획이 없는 경우

Pinia와 Apollo 결합하기

앱에서 단독 상태 관리자로 Apollo 또는 Pinia 중 하나를 선택하는 것을 권장합니다.

두 개를 결합하는 것은 권장되지 않습니다. 그 이유는:

Pinia와 Apollo 모두 전역 스토어이므로 책임을 공유하고 두 개의 진실의 출처가 존재하게 됨.
정신 모델의 차이: Apollo는 구성 기반이며, Pinia는 그렇지 않음. 이러한 정신 모델 간 전환은 번거롭고 오류가 발생하기 쉬움.
두 접근 방식의 단점을 동시에 경험함.

그러나 두 솔루션의 특정 이점을 얻기 위해 이 두 가지를 결합하는 것이 괜찮은 경우도 있습니다:

클라이언트 측 상태의 상당 부분이 Pinia에서 관리되는 것이 가장 좋을 경우.
도메인별 문제가 GraphQL 요청을 위한 Apollo를 요구하는 경우.

Apollo와 Pinia를 사용해야 하는 경우 다음 규칙을 따르세요:

Pinia 스토어에서 Apollo Client를 사용하지 마세요. Apollo Client는 Vue 컴포넌트 내에서만 사용해야 하며, composable 내에서만 소비되어야 함.
Apollo와 Pinia 간의 데이터 동기화를 하지 마세요.
요청에 대한 진실의 출처는 하나만 있어야 합니다.

Pinia가 있는 기존 앱에 Apollo 추가하기

다음 두 가지 조건이 모두 충족되는 경우 기존 Pinia 상태와 함께 컴포넌트에서 Apollo 데이터 관리를 할 수 있습니다:

GraphQL에서 오는 데이터로 작업할 필요가 있을 때
높은 마이그레이션 노력이 있어 Pinia에서 Apollo로 마이그레이션할 수 없을 때

클라이언트 상태(즉, GraphQL 또는 REST 데이터와 혼동하지 않음)를 Apollo와 Pinia로 동시에 관리하려고 하지 마세요.

이 경우 Pinia에서 Apollo로 마이그레이션하는 것을 고려하세요.

Pinia 스토어 내에서 Apollo를 사용하지 마세요.

Apollo가 있는 기존 앱에 Pinia 추가하기

먼저 클라이언트 측 상태 관리에 Apollo 사용을 강력히 고려하세요. 그러나 아래 모든 조건이 해당될 경우, Apollo는 클라이언트 측 상태 관리를 위한 최상의 도구가 아닐 수 있습니다:

클라이언트 측 상태의 규모가 Apollo의 복잡성으로 인해 구현 비용이 매우 높은 경우.
클라이언트 측 상태가 Apollo에서 관리하는 GraphQL API 데이터와 잘 분리될 수 있는 경우.

Apollo와 함께 사용하는 Vuex

Vuex는 GitLab에서 사용 중단되었습니다. 위의 지침을 따라 Apollo 또는 Pinia 중 하나를 기본 상태 관리자로 선택하세요.

해당 마이그레이션 가이드를 따르세요: Apollo 또는 Pinia.

기존 Vuex 스토어 위에 새로운 Pinia 스토어를 추가하지 마세요. 먼저 마이그레이션하세요.