Angular 6-서비스 주입 대신 @ ngrx / store를 사용하는 이유

나는 최근 @ ngrx / store로 Angular 6을 배우고 있는데 튜토리얼 중 하나는 상태 관리를 위해 @ ngrx / store를 사용하는 것이지만, @ ngrx / store를 사용하는 이점을 이해하지 못합니다.

예를 들어 간단한 로그인 및 가입 작업의 경우 이전에는 서비스 (AuthService라고하겠습니다) 를 사용하여 백엔드 API를 호출하고 AuthService에 "userInfo"또는 "token"을 저장하고 사용자를 "HOME"으로 리디렉션하는 데 사용할 수 있습니다. DI를 사용하여 userInfo를 가져와야하는 모든 구성 요소에 AuthService를 삽입 할 수 있습니다. 이는 단순히 하나의 파일 AuthService가 모든 것을 처리합니다 .

이제 @ ngrx / store를 사용하는 경우 위의 작업 또는 이벤트를 처리하기 위해 4 개 또는 5 개의 파일을 작성해야하는 Action / State / Reducer / Effects / Selector 를 정의 해야합니다. 그런 다음 여전히 백엔드 API를 호출해야합니다. 훨씬 더 복잡하고 중복되는 서비스를 사용 하는 중 ...

다른 시나리오에서는 일부 페이지에서 @ ngrx / store를 사용하여 그리드 데이터와 같은 개체 또는 개체 목록을 저장하는 것을 볼 수 있습니다. , 어떤 종류의 메모리 내 저장소 사용을위한 것입니까?

다시 질문으로 돌아가서 Angular 프로젝트에서 서비스 등록 저장소 대신 @ ngrx / store를 사용하는 이유는 무엇입니까? " STATE MANAGEMENT "사용을 위한 것임을 알고 있지만 "STATE MANAGEMENT"가 정확히 무엇입니까? 트랜잭션 로그와 같은 것이며 언제 필요합니까? 프런트 엔드에서 관리하는 이유는 무엇입니까? @ ngrx / store 영역에서 제안이나 경험을 자유롭게 공유하십시오!

Ngrx 스토어에 대한 두 게시물을 읽어야한다고 생각합니다.

• Angular 서비스 계층 : Redux, RxJs 및 Ngrx Store-언제 저장소를 사용해야하며 왜?
• Ngrx Store-아키텍처 가이드

첫 번째 항목이 Ngrx Store가 해결 한 주요 문제를 설명하는 경우 React How-To에서 "원래 Flux, Redux, Ngrx Store 또는 일반적으로 모든 저장소 솔루션에 동일하게 적용되는 것 같습니다."

Flux가 필요할 때 알게 될 것입니다. 필요한지 확실하지 않으면 필요하지 않습니다.

나에게 Ngrx store는 여러 문제를 해결합니다. 예를 들어 관찰 가능 항목을 처리해야하고 일부 관찰 가능 데이터에 대한 책임이 서로 다른 구성 요소간에 공유되는 경우입니다. 이 경우 저장 작업과 리듀서는 데이터 수정이 항상 "올바른 방식"으로 수행되도록합니다.

또한 http 요청 캐싱을위한 안정적인 솔루션을 제공합니다. 요청과 응답을 저장할 수 있으므로 요청에 저장된 응답이 아직 없는지 확인할 수 있습니다.

두 번째 게시물은 Facebook의 읽지 않은 메시지 카운터 문제와 함께 이러한 솔루션이 React 세계에 나타나는 이유에 대한 것입니다.

서비스에 가려지지 않는 데이터를 저장하는 솔루션에 대해. 상수 데이터를 다룰 때 잘 작동합니다. 그러나 여러 구성 요소가이 데이터를 업데이트해야하는 경우 다음과 같이 해결할 수있는 변경 감지 문제 및 부적절한 업데이트 문제가 발생할 수 있습니다.

• private Subject public Observable 및 next 기능이있는 옵저버 패턴
• Ngrx 스토어

세 번째 옵션도 있습니다. 데이터를 서비스에 포함하고 html로 직접 서비스를 사용합니다 *ngFor="let item of userService.users". 따라서 userService.users추가 또는 업데이트 작업이 자동으로 html로 렌더링 된 후 서비스에서 업데이트 할 때 관찰 가능 항목이나 이벤트 또는 저장소가 필요하지 않습니다.

앱의 데이터가 여러 구성 요소에서 사용되는 경우 데이터를 공유하기위한 일종의 서비스가 필요합니다. 이를 수행하는 방법에는 여러 가지가 있습니다.

적당히 복잡한 앱은 결국 서비스에서 데이터 처리가 수행되는 프런트 엔드 백 엔드 구조처럼 보이게되며 관찰 가능 항목을 통해 데이터를 구성 요소에 노출합니다.

언젠가는 데이터 서비스에 일종의 API를 작성해야하고, 데이터를 들어오고 나가는 방법, 쿼리 등이 필요합니다. 데이터의 불변성과 같은 많은 규칙과 데이터를 수정하기 위해 잘 정의 된 단일 경로가 있습니다. 서버 백엔드와 다르지 않지만 API 호출보다 훨씬 빠르고 응답 성이 뛰어납니다.

귀하의 API는 이미 존재하는 많은 상태 관리 라이브러리 중 하나처럼 보입니다. 어려운 문제를 해결하기 위해 존재합니다. 앱이 간단한 경우에는 필요하지 않을 수 있습니다.