InfoGrab DocsInfoGrab Docs

상태 관리 가이드

요약

GitLab은 클라이언트 상태 관리를 위해 Apollo와 Pinia 두 가지 솔루션을 지원합니다. GitLab 코드베이스에서 Vuex를 볼 수도 있습니다. **데이터(Data)**는 사용자가 상호작용하는 정보입니다. **상태(State)**는 사용자 또는 시스템 상호작용에 관한 정보를 저장합니다.

GitLab은 클라이언트 상태 관리를 위해 Apollo와 Pinia 두 가지 솔루션을 지원합니다. 이 중 하나를 기본 상태 관리자로 선택하는 것은 간단하지 않습니다. 이 페이지는 선택 방법에 대한 일반적인 가이드를 제공합니다.

GitLab 코드베이스에서 Vuex를 볼 수도 있습니다. Vuex는 GitLab에서 더 이상 사용되지 않으며 새로운 Vuex 스토어는 생성하지 않아야 합니다. 앱에 Vuex 스토어가 있다면 마이그레이션을 고려하세요.

상태(state)와 데이터(data)의 차이#

**데이터(Data)**는 사용자가 상호작용하는 정보입니다. 일반적으로 외부 요청(GraphQL 또는 REST)이나 페이지 자체에서 가져옵니다.

**상태(State)**는 사용자 또는 시스템 상호작용에 관한 정보를 저장합니다. 예를 들어 모든 플래그는 상태로 간주됩니다: isLoading, isFormVisible 등.

상태 관리는 상태와 데이터 모두를 다루는 데 사용할 수 있습니다.

상태 관리가 필요한가요?#

애플리케이션에서 먼저 표준 Vue 데이터 흐름을 사용하는 것이 좋습니다: 컴포넌트가 로컬 상태를 정의하고 props를 통해 전달하며, 이벤트를 통해 변경합니다.

그러나 이 방식은 상태를 정의한 컴포넌트의 직접 하위 컴포넌트가 아닌 여러 컴포넌트 간에 상태를 공유하는 복잡한 경우에는 충분하지 않을 수 있습니다. 해당 상태를 애플리케이션의 루트로 끌어올리는 것을 고려할 수 있지만, 루트 컴포넌트가 너무 많은 일을 한꺼번에 처리하기 시작하면 결국 비대해집니다.

이러한 복잡성을 해결하기 위해 상태 관리 솔루션을 사용할 수 있습니다. 아래 섹션이 선택에 도움이 될 것입니다. 아직 확실하지 않다면 Pinia보다 Apollo를 먼저 사용하세요.

Apollo#

Apollo는 GraphQL API에 대한 기본 인터페이스이며, 클라이언트 측 상태 관리자로도 사용할 수 있습니다. GraphQL과 Apollo에 대해 자세히 알아보세요.

강점#

  • GraphQL 요청에서 가져온 데이터를 다루는 데 탁월하며, 기본적으로 데이터 정규화를 제공합니다.

  • GraphQL을 사용할 수 없을 때 REST API의 데이터를 캐시할 수 있습니다.

  • 쿼리가 GraphQL 스키마에 대해 정적으로 검증됩니다.

약점#

Apollo를 선택하는 경우#

  • GraphQL API를 사용하는 경우

  • 다음과 같은 특정 Apollo 기능이 필요한 경우:

매개변수화된 캐시, 캐시 무효화

Pinia#

Pinia는 Vue가 권장하는 클라이언트 측 상태 관리 도구입니다. GitLab에서의 Pinia에 대해 자세히 알아보세요.

강점#

  • 단순하지만 강력합니다

  • Pinia 사이트 기준으로 ≈1.5kb의 경량 크기

  • 내부적으로 Vue 반응성을 사용하며, API는 Vuex와 유사

  • 디버깅이 쉽습니다

약점#

  • 기본적으로 고급 요청 처리(데이터 정규화, 폴링, 캐싱 등)를 수행할 수 없습니다

  • 가이드 없이 사용하면 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 스토어를 추가하지 말고, 먼저 마이그레이션하세요.

상태 관리 가이드

GitLab v19.1
원문 보기
요약

GitLab은 클라이언트 상태 관리를 위해 Apollo와 Pinia 두 가지 솔루션을 지원합니다. GitLab 코드베이스에서 Vuex를 볼 수도 있습니다. **데이터(Data)**는 사용자가 상호작용하는 정보입니다. **상태(State)**는 사용자 또는 시스템 상호작용에 관한 정보를 저장합니다.

GitLab은 클라이언트 상태 관리를 위해 Apollo와 Pinia 두 가지 솔루션을 지원합니다. 이 중 하나를 기본 상태 관리자로 선택하는 것은 간단하지 않습니다. 이 페이지는 선택 방법에 대한 일반적인 가이드를 제공합니다.

GitLab 코드베이스에서 Vuex를 볼 수도 있습니다. Vuex는 GitLab에서 더 이상 사용되지 않으며 새로운 Vuex 스토어는 생성하지 않아야 합니다. 앱에 Vuex 스토어가 있다면 마이그레이션을 고려하세요.

상태(state)와 데이터(data)의 차이#

**데이터(Data)**는 사용자가 상호작용하는 정보입니다. 일반적으로 외부 요청(GraphQL 또는 REST)이나 페이지 자체에서 가져옵니다.

**상태(State)**는 사용자 또는 시스템 상호작용에 관한 정보를 저장합니다. 예를 들어 모든 플래그는 상태로 간주됩니다: isLoading, isFormVisible 등.

상태 관리는 상태와 데이터 모두를 다루는 데 사용할 수 있습니다.

상태 관리가 필요한가요?#

애플리케이션에서 먼저 표준 Vue 데이터 흐름을 사용하는 것이 좋습니다: 컴포넌트가 로컬 상태를 정의하고 props를 통해 전달하며, 이벤트를 통해 변경합니다.

그러나 이 방식은 상태를 정의한 컴포넌트의 직접 하위 컴포넌트가 아닌 여러 컴포넌트 간에 상태를 공유하는 복잡한 경우에는 충분하지 않을 수 있습니다. 해당 상태를 애플리케이션의 루트로 끌어올리는 것을 고려할 수 있지만, 루트 컴포넌트가 너무 많은 일을 한꺼번에 처리하기 시작하면 결국 비대해집니다.

이러한 복잡성을 해결하기 위해 상태 관리 솔루션을 사용할 수 있습니다. 아래 섹션이 선택에 도움이 될 것입니다. 아직 확실하지 않다면 Pinia보다 Apollo를 먼저 사용하세요.

Apollo#

Apollo는 GraphQL API에 대한 기본 인터페이스이며, 클라이언트 측 상태 관리자로도 사용할 수 있습니다. GraphQL과 Apollo에 대해 자세히 알아보세요.

강점#

  • GraphQL 요청에서 가져온 데이터를 다루는 데 탁월하며, 기본적으로 데이터 정규화를 제공합니다.

  • GraphQL을 사용할 수 없을 때 REST API의 데이터를 캐시할 수 있습니다.

  • 쿼리가 GraphQL 스키마에 대해 정적으로 검증됩니다.

약점#

Apollo를 선택하는 경우#

  • GraphQL API를 사용하는 경우

  • 다음과 같은 특정 Apollo 기능이 필요한 경우:

매개변수화된 캐시, 캐시 무효화

Pinia#

Pinia는 Vue가 권장하는 클라이언트 측 상태 관리 도구입니다. GitLab에서의 Pinia에 대해 자세히 알아보세요.

강점#

  • 단순하지만 강력합니다

  • Pinia 사이트 기준으로 ≈1.5kb의 경량 크기

  • 내부적으로 Vue 반응성을 사용하며, API는 Vuex와 유사

  • 디버깅이 쉽습니다

약점#

  • 기본적으로 고급 요청 처리(데이터 정규화, 폴링, 캐싱 등)를 수행할 수 없습니다

  • 가이드 없이 사용하면 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 스토어를 추가하지 말고, 먼저 마이그레이션하세요.