• 상태와 데이터의 차이
• 상태 관리가 필요한가요?
• Apollo
  • 강점
  • 약점
  • Apollo는 다음 경우 선택
• Pinia
  • 강점
  • 약점
  • Pinia를 선택해야 하는 경우
• Pinia와 Apollo를 결합
  • 기존 앱에 Apollo 추가하기
  • 기존 앱에 Pinia 추가하기
  • Vuex를 Apollo와 함께 사용하기

상태 관리 안내

GitLab에서는 클라이언트 상태 관리를 위해 Apollo와 Pinia 두 가지 솔루션을 지원합니다. 어떤 것을 주요 상태 관리자로 선택할지 결정하는 것은 간단한 일이 아닙니다. 이 페이지에서는 이 선택을 하는 데 도움이 되는 일반적인 지침을 제공해야 합니다.

GitLab 코드베이스에서는 Vuex도 사용할 수 있습니다. GitLab에서는 Vuex가 더 이상 사용되지 않습니다 and 새로운 Vuex 스토어를 생성하면 안 됩니다. 만약 앱에 Vuex 스토어가 있다면, 마이그레이션을 고려해보세요.

상태와 데이터의 차이

데이터는 사용자가 상호 작용하는 정보입니다. 보통 외부 요청(Growl 또는 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 기능이 필요할 때, 예를 들어:
  • 파라미터화된 캐시, 캐시 무효화
  • 폴링
  • Stale While Revalidate
  • 실시간 업데이트
  • 기타

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를 결합

우리는 앱에서 Pinia 또는 Apollo 중 하나만 상태 관리자로 선택하는 것을 권장합니다. 그들을 결합하는 것은 추천되지 않습니다. 왜냐하면:

• Pinia와 Apollo 모두 전역 스토어이기 때문에 책임을 공유하고 두 개의 데이터 또는 상태의 진실된 원천이 발생합니다.
• 정신 모델의 차이: Apollo은 구성 기반이며, Pinia는 그렇지 않습니다. 이러한 정신 모델 간의 전환은 지루하고 오류가 발생하기 쉽습니다.
• 두 접근 방식의 단점 경험

그러나 Pinia에서도 Apollo에서도 특정 이점을 얻기 위해 두 가지를 결합해야 하는 경우가 있을 수 있습니다:

• Pinia에서 관리하는 클라이언트 측 상태의 중요 비율이 있다면 결합하는 것이 가장 좋을 수 있습니다.
• 도메인별 관심이 컴포넌트 내의 일관된 GraphQL 요청을 위해 Apollo를 필요로 하는 경우.

Apollo와 Pinia를 둘 다 사용해야 하는 경우, 다음 규칙을 따르십시오:

• Pinia 스토어 내에서 Apollo Client를 사용하지 마세요. Apollo Client는 Vue 컴포넌트나 composable 내에서만 사용해야 합니다.
• Apollo와 Pinia 간에 데이터를 동기화하지 마세요.
• 요청에 대해 하나의 진실된 원천을 갖도록 해야 합니다.

기존 앱에 Apollo 추가하기

기존의 Pinia 상태와 함께 컴포넌트 내에서 Apollo 데이터 관리를 할 수 있습니다:

• GraphQL에서 오는 데이터를 처리해야 하는 경우
• Pinia에서 Apollo로 마이그레이션하는 것이 높은 마이그레이션 작업이기 때문에 Apollo로 마이그레이션할 수 없는 경우

Apollo 및 Pinia에서 클라이언트 상태(겹치지 않아야 함)를 동시에 관리하지 마세요. 이에 대한 필요성이 있다면 Pinia에서 Apollo로 마이그레이션을 고려하세요.

기존 앱에 Pinia 추가하기

먼저 Apollo를 클라이언트 측 상태 관리에 사용하는 것이 좋습니다. 그러나 다음 조건이 모두 참이라면, Apollo는 이 클라이언트 측 상태를 관리하는 데 가장 적합한 도구가 아닐 수 있습니다:

• 클라이언트 측 상태의 풋프린트가 클 정도로 구현 비용이 높은 경우 Apollo의 복잡성 때문에
• 클라이언트 측 상태를 Apollo에서 관리되는 GraphQL API 데이터에서 깔끔하게 분리할 수 있는 경우

Vuex를 Apollo와 함께 사용하기

GitLab에서는 Vuex를 사용하지 않습니다. 위 안내를 사용하여 주요 상태 관리자로 Apollo 또는 Pinia 중 하나를 선택하십시오. 해당 이주 가이드를 따르세요: Apollo 또는 Pinia. 기존의 Vuex 스토어 위에 새로운 Pinia 스토어를 추가하지 마세요. 먼저 이주를 진행하세요.