상태 관리 저장소를 구조화합니다 (ngrx/redux). 데이터를 대표하거나,보기의 대표자로 중첩되어 있습니까?

Question

저는 응용 프로그램 상태를 유지하기 위해 ngrx store를 사용하고 있습니다. normalizr은 API 호출에서 내 데이터를 변환하고 Immutable입니다. 지금까지는 실제로 잘 작동했지만 좀 더 복잡한 데이터 관계를 유지하고 있으며 저장소를 구조화하는 방법에 대해 궁금해하고있었습니다.

사물을 단순화하기 위해 두 세트의 개체가 있습니다. 세션 및 송장.

한 명의 사용자가 로그온하여 자신의 세션 목록을 볼 수 있습니다. 가게의 상태는 객체 ISessions에서 개최된다

export interface ISessions extends Map<String, any> { 
    result: List<Number>; 
    entities: { 
    sessions: Map<Number, ISessions>, 
    clients: Map<Number, IClient>, 
    tutors: Map<Number, IProfile> 
    }, 
    adding: boolean; 
    loading: boolean; 
    loadingFailed: boolean; 
    error: string; 
} 

(단체는 표준화 된 출력을 포함 - 클라이언트와 교사가 세션에 포함 된 중첩 종류)

이 정말 잘 작동합니다. 감속기가 로딩을 설정하여 뷰에 로딩 바를 표시 할 수 있습니다. 데이터가 채워지면 맵핑 된 데이터의 ID를 참조하는 현명한 평면 맨어에서 사용할 수 있습니다.

export interface IInvoices extends Map<String, any> { 
    result: List<Number>; 
    entities: { 
    invoices: Map<Number, IInvoice>, 
    clients: Map<Number, IClient>, 
    tutors: Map<Number, IProfile> 
    }, 
    adding: boolean; 
    loading: boolean; 
} 

그래서 내 가게는 다음과 같습니다 : 그러나

export interface IAppState { 
    sessions: ISessions; 
    invoices: IInvoices; 
} 

, 지금은 더 복잡한 오셨습니다

그들은 송장을로드 할 수 있습니다,이는 IInvoices 개체 주위에 매우 유사하게 작동합니다 관계. 세션이 송장에 지정됩니다. 다음과 같은 몇 가지 방법이 있습니다.

1. 각 청구서에는 자체적으로 ISessions 개체가있을 수 있습니다. 이것은 데이터 구조가 평평하다는 생각에 어긋나는 것 같습니다. 또한 AppState.sessions 및 AppState.invoices에 저장된 반복 세션이있을 가능성이 큽니다. 그러나 IInvoice가 뷰의 상태에보다 직접적으로 매핑되므로 관리가 더 쉬울 것입니다 (세션로드 등은 캡슐화 된 ISessions 오브젝트의 청구서에 저장됩니다).

나는 ISessions 및 송장에 별도로 가게에서 ID를 청구 할 ISessions의지도를 저장할 수

2. :

예 :

export interface IAppState { 
    sessions: ISessions; 
    invoices: IInvoices; 
    invoicesSessions: Map<number, ISessions>; 
} 

<안녕, 시작 = "3">

송장을 기존 ISessions 객체에로드 할 수있었습니다. 이것은 모든 세션 데이터가 같은 위치에 있고 반복이 없음을 의미합니다. 한 가지 문제는보기에 매핑하는 데 어려움이 있습니다. 각 인보이스는 세션 목록을 가져와 필요한 항목으로 필터링해야합니다. 나는 ISessions 객체에서 Invoice 세션의 로딩을 추적해야 할 것이다.

클라이언트와 교사의 두 가지 목록 (ISession과 IInvices에 각각 하나씩)을 저장해야하는지 여부에 대한 질문이 있습니다. 이 가게를 나눠 먹는 것은 나쁜 생각입니까? 이것은 내 감속기가 모두 하위 섹션이 아닌 IAppState 개체 전체에서 작동해야한다는 것을 의미합니다.

기본적으로 : 데이터를 가져올 때 큰 ID 인덱스 목록을 컴파일해야하며 뷰에 필요한 '쿼리'가 거의 필요합니다. 기본적으로 데이터베이스와 같은 저장소를 사용하거나 보유해야합니다. 뷰를 직접 반영하는 개체의 심층적 인 컬렉션 - 데이터가 여러 번 필요한 위치에서 반복되는 것을 의미합니까?

Answer 1

예, Redux 저장소를 구조화 할 때 권장되는 방법은 뷰가 아닌 데이터 관점에서 상태 셰이프를 작성하는 것입니다. 관계형 데이터에 대한 권장 사항은 모두 정상화 된 상태로 유지하는 것입니다. 선택기 기능을 사용하여 해당 상태에 대한 쿼리로 작동합니다. 더 많은 정보를 들어

은 다음을 참조하십시오

• FAQ: Organizing relational data?
• Structuring Reducers - Normalizing State Shape
• React/Redux Links: Selectors and Normalization
또한

내 "Practical Redux" tutorial series는 관계형 데이터를 관리하기 위해 돌아 오는-ORM 라이브러리를 사용하는 방법을 보여줍니다 당신의 Redux 상태 : Practical Redux-ORM Basics 및 Practical Redux, Part 2: Redux-ORM Concepts and Techniques.