목록 / 세부 정보보기 및 페이지 매김이있는 앱의 Redux 상태 모양을 선택하는 방법은 무엇입니까?

목록 / 세부 정보보기 및 페이지 매김이있는 앱의 Redux 상태 모양을 선택하는 방법은 무엇입니까?

---

내 데이터베이스에 여러 항목 (예 : 사용자)이 있다고 상상해보십시오. 나는 또한 두 개의 경로를 가지고 있는데, 하나는 목록이고 다른 하나는 세부 사항 (항목을 편집 할 수있는 곳)입니다. 이제 저는 데이터 구조에 접근하는 방법을 고민하고 있습니다.

저는 두 가지 접근 방식과 둘의 조합을 생각하고 있습니다.

공유 데이터 세트

• 나는로 이동 /list내 모든 사용자가 REDUX 저장소에 저장된 키에 따라 API에서 다운로드, users나 또한 어떤 종류를 추가 users_offset하고 users_limit목록의 일부만을 렌더링
• 그런 다음로 이동 하여 값으로 /detail/<id>저장 합니다. 즉 , 다음 currently_selected_user과 <id>같이 사용자 데이터를 가져올 수 있습니다.users.find(res => res.id === currently_selected_user)
• 하나의 데이터 세트와 그것을 가리키는 세부 사항으로 작업하고 있기 때문에 업데이트도 훌륭하고 쉽습니다.
• 새로운 사용자를 추가하는 것도 쉽습니다. 동일한 사용자 목록으로 작업하기 만하면됩니다.

이제이 접근 방식의 문제점은 사용자 목록이 엄청나게 많으면 (예 : 수백만) 다운로드하는 데 시간이 걸릴 수 있다는 것입니다. 또한로 직접 이동할 때 /detail/<id>아직 모든 사용자가 다운로드되지 않았으므로 필요한 데이터 만 가져 오려면 먼저 전체를 다운로드해야합니다. 수백만 명의 사용자가 하나만 편집합니다.

분리 된 데이터 세트

• 으로 이동하여 /listapi에서 모든 사용자를 다운로드하는 대신 내 users_per_page및 users_current_page설정 에 따라 몇 명만 다운로드 하고 데이터를 다음과 같이 저장합니다.users_currently_visible
• 그런 다음으로 이동하여 값 /detail/<id>으로 저장 currently_selected_user하고 <id>검색하는 대신 users_currently_visibleapi에서 사용자 데이터를 다운로드합니다.
• 업데이트시, 나는 users_currently_visible어떤 식 으로든 업데이트하지 않을 것입니다
• 나는 추가하지 않을 것이다

여기서 가능한 문제는을 방문 할 때 /listapi에서 데이터를 다시 다운로드해야한다는 것입니다. 왜냐하면 데이터베이스에있는 것과 동기화되지 않았을 수 있기 때문입니다. 또한 불필요하게 사용자 데이터를 자세히 다운로드 할 수도 있습니다. 그들은 우연히 이미 내users_currently_visible

일종의 프랑켄슈타인과 같은 헛소리

• 자세히 설명하겠습니다. Separated data set 에서와 동일하게 수행 하지만 api에서 사용자 데이터를 직접 다운로드하는 대신 먼저 확인합니다.
  • 나는 어떤 것이 있습니까 users_currently_visible
  • 그렇다면 그들 사이에 내 ID가있는 사용자가 있습니까? 둘 다 사실이면 내 사용자 데이터로 사용하고 그렇지 않으면 API 호출을합니다.
• users_currently_visible업데이트 할 때도 똑같은 일이 발생합니다. 사용자가 존재하는지 확인하고 그 사이에 존재하는지 확인 합니다. 그렇지 않은 경우에는 목록을 업데이트합니다.

이것은 아마도 효과가있을 것이지만 그것이 적절한 방법이라고 생각하지 않습니다. 새 목록을 추가했을 수 users_currently_visible있으므로을 (를) 방문 할 때의 새 목록을 다운로드해야 할 /list수도 있습니다.

팬이 좋아하는 방법이 있나요? ... 모든 redux 사용자가 같은 일을 겪었을 것입니다.

감사!

---

Redux 저장소에서 "실제"예제 를 참조하십시오 .
정확히이 문제에 대한 해결책을 보여줍니다.

상태 모양은 다음과 같아야합니다.

{
  entities: {
    users: {
      1: { id: 1, name: 'Dan' },
      42: { id: 42, name: 'Mary' }
    }
  },
  visibleUsers: {
    ids: [1, 42],
    isFetching: false,
    offset: 0
  }
}

참고 entities(ID-> 개체 맵) 및 visibleUsers(페이지 매김 상태 및 ID가있는 현재 보이는 사용자 설명)을 별도로 저장하고 있습니다.

이것은 "공유 데이터 세트"접근 방식과 유사합니다. 그러나 나는 당신이 나열한 단점이이 접근법에 내재 된 실제 문제라고 생각하지 않습니다. 그들을 살펴 보자.

이제이 접근 방식의 문제는 사용자 목록이 엄청나게 커지면 (예 : 수백만) 다운로드하는 데 시간이 걸릴 수 있다는 것입니다.

모두 다운로드 할 필요는 없습니다! 다운로드 한 모든 항목을에 병합 entities한다고해서 모든 항목을 쿼리해야하는 것은 아닙니다. 는 entities다운로드 한 모든 엔티티가 포함되어야 지금까지 세상의 모든 개체 -not을. 대신 페이지 매김 정보에 따라 현재 표시중인 항목 만 다운로드합니다.

/ detail /로 직접 이동하면 아직 모든 사용자가 다운로드되지 않았으므로 해당 사용자에 대한 데이터 만 얻으려면 모두 다운로드해야합니다. 수백만 명의 사용자가 하나만 편집합니다.

아니요, 그중 하나만 요청하시면됩니다. 대응 조치가 실행되고 책임 감속기 가이 단일 엔티티 를 기존 상태에 entities병합 합니다 . 그냥 때문에 state.entities.users의미하지 않는다 명 이상의 사용자를 포함 당신이 그들 모두를 다운로드해야 할 수도 있습니다. 채울 필요entities 가없는 캐시로 생각하십시오 .

---

Finally, I will direct you again to the “real world” example from Redux repo. It shows exactly how to write a reducer for pagination information and entity cache, and how to normalize JSON in your API responses with normalizr so that it’s easy for reducers to extract information from server actions in a uniform way.

참고URL : https://stackoverflow.com/questions/33940015/how-to-choose-the-redux-state-shape-for-an-app-with-list-detail-views-and-pagina