Comment choisir le Redux état de forme pour une application à la liste/les vues de détail et la pagination?

Imaginer que j'ai un certain nombre d'entrées(par exemple, les utilisateurs) dans ma base de données. J'ai également deux itinéraires, l'un pour la liste, d'autres pour les détails(où vous pouvez éditer l'entrée). Maintenant, je suis aux prises avec la façon d'aborder la structure de données.

Je pense à deux approches et plutôt une combinaison des deux.

Partagés ensemble de données

Je navigue à /list, tous mes utilisateurs sont téléchargés à partir de l'api stockée dans redux magasin, sous la clé users, j'ai aussi ajouter une sorte de users_offset et users_limit pour que le rendu de la liste
Je puis accédez à /detail/<id>, et de stocker currently_selected_user avec <id> comme le val... ce qui signifie que je vais être en mesure d'obtenir mes données de l'utilisateur avec quelque chose comme ça users.find(res => res.id === currently_selected_user)
la mise à jour sera agréable et facile ainsi, depuis que je suis en train de travailler avec un seul ensemble de données et de détail montrant du doigt
l'ajout d'un nouvel utilisateur facile, encore une fois juste à travailler avec la même liste d'utilisateurs

Maintenant, le problème que j'ai avec cette approche est que, lorsque la liste des utilisateurs devient énorme(dire des millions), il pourrait prendre un certain temps à télécharger. Et aussi, quand je accéder directement à /detail/<id>, je ne dispose pas encore de tous mes utilisateurs ont téléchargé, de sorte à obtenir des données pour juste celui dont j'ai besoin, je vais devoir d'abord télécharger l'ensemble de la chose. Des Millions d'utilisateurs pour éditer un.

Séparées de l'ensemble de données

Je navigue à /list, et au lieu de télécharger tous mes utilisateurs de l'api, je ne l'ai télécharger un couple d'entre eux, selon ce que mon users_per_page et users_current_page serait réglé, et je serais probablement stocker les données que users_currently_visible
Je puis accédez à /detail/<id>, magasin currently_selected_user avec <id> comme le val...et au lieu de chercher à travers users_currently_visible j'ai simplement télécharger les données de l'utilisateur à partir de l'api..
sur la mise à jour, je ne vais pas mettre à jour users_currently_visible en quelque sorte
et ne je sur ajouter

Ce que je vois que possible problème ici est que je vais avoir, lors de la visite /list, télécharger les données de l'api de nouveau, car il pourrait ne pas être en phase avec ce qui est dans la base de données, j'ai aussi peut-être inutilement le téléchargement de données utilisateurs dans le détail, parce qu'ils pourraient être d'ailleurs déjà à l'intérieur de mon users_currently_visible

une sorte de frankenstein-y manigances

Je détaille, je fais la même chose que dans Séparées de l'ensemble de données mais au lieu de directement télécharger les données de l'utilisateur à partir de l'api, j'ai d'abord vérifier:
- dois-je tout users_currently_visible
- si oui, est-il un utilisateur avec mon id d'entre eux?
  si les deux sont vrais, je puis l'utiliser comme mes données d'utilisateur, sinon, je fais l'appel d'api
même phénomène se produit sur la mise à jour, je vérifie si mon utilisateur existe entre users_currently_visible si oui, je l'ai aussi mise à jour de cette liste, sinon je ne fais rien

Ce serait probablement travailler, mais n'a pas vraiment l'impression que c'est la bonne façon. Je voudrais aussi probablement encore besoin de télécharger la nouvelle liste de users_currently_visible lors de la visite /list, parce que j'ai peut-être ajouté un nouveau..

Est-il un favori des fans façon de le faire?... Je suis sûr que chacun redux utilisateur doit avoir rencontré les mêmes choses.

Merci!

Dans notre application, nous sommes actuellement à l'aide de la "séparé de l'ensemble de données" approche. Il fait plus d'appels à votre API, mais il fonctionne. Mais de toute façon, il se sent comme la meilleure solution à l'aide d'un seul ensemble de données. Je ne suis pas sûr de cela aussi.
Je pense que ça vient de la façon dont nombre d'entrées que vous avez dans la base de données, ce jsonplaceholder.typicode.com/photos est de 5000 articles et c'est déjà de 900 ko..
Oui, vous avez raison. Mais sur le plan conceptuel, il semble que la bonne approche est d'utiliser le même ensemble de données. De toute façon, nous nous penchons sur ces deux entrées dans l'état d'application suivants: une brève liste contenant uniquement les données nécessaires pour afficher la liste détaillée de l'objet contenant tous les accessoires lors de l'ajout, l'édition, etc. Il est techniquement mieux, mais je voudrais avoir le tout en un ensemble de données sans avoir des problèmes de performances 🙂

InformationsquelleAutor fxck | 2015-11-26

75

Veuillez consulter le “monde réel” exemple de Redux repo.

Il montre la solution à ce problème.

Votre état de forme devrait ressembler à ceci:
```
{
  entities: {
    users: {
      1: { id: 1, name: 'Dan' },
      42: { id: 42, name: 'Mary' }
    }
  },
  visibleUsers: {
    ids: [1, 42],
    isFetching: false,
    offset: 0
  }
}
```
Remarque je suis stocker entities (ID -> Objet de cartes) et visibleUsers (description de actuellement visible des utilisateurs avec la pagination de l'état et IDs) séparément.

Cela semble similaire à la votre “Partagés ensemble de données” approche. Cependant, je ne pense pas que les inconvénients vous de la liste sont de vrais problèmes inhérents à cette approche. Prenons un oeil à eux.

Maintenant, le problème que j'ai avec cette approche est que lorsque la liste des utilisateurs devient énorme(dire des millions), il pourrait prendre un certain temps pour télécharger

Vous n'avez pas besoin de les télécharger! La fusion de tous les documents téléchargés, les entités entities ne signifie pas que vous devriez interroger tous d'entre eux. Le entities doit contenir toutes les entités qui ont été téléchargés jusqu'à présent—pas toutes les entités dans le monde. Au lieu de cela, vous ne télécharger ceux que vous êtes en train de montrer, selon les informations de pagination.

quand j'ai naviguer directement vers /detail/, je ne dispose pas encore de tous mes utilisateurs ont téléchargé, de sorte à obtenir des données pour seulement l'un, je vais avoir à les télécharger tous. Des Millions d'utilisateurs pour éditer un.

Pas, vous feriez demande de l'un d'entre eux. La réponse de l'action du feu, et réducteur responsable de entities de fusionner cette entité unique dans l'état actuel. Tout simplement parce que state.entities.users peut contenir plus d'un utilisateur ne signifie pas que vous avez besoin de les télécharger. Pensez à entities comme d'un cache qui n'est pas ont à être rempli.

Enfin, je vais vous diriger à nouveau à la le “monde réel” exemple de Redux repo. Il montre exactement comment écrire un réducteur pour la pagination de l'information et de l'entité de cache, et comment normaliser le JSON dans votre API réponses avec normalizr de sorte qu'il est facile pour les réducteurs à extraire des informations à partir du serveur actions de manière uniforme.
- Cet exemple est grande, mais les entités d'accumuler des heures supplémentaires en l'état. Comment pouvez-vous supprimer les entités que vous n'avez pas besoin ?
- Vous ne pouvez pas. Si votre application est destinée à être utilisée pour les jours sans fermer l'onglet, cette approche ne fonctionnera pas pour vous, et vous pourriez être mieux servis par quelque chose comme Relais. Ou vous pouvez mettre en place votre propre sorte de "garbage collection" en haut de cette approche. Ou juste actualiser la page de temps en temps :-).
- Mise à jour du lien pour le "monde réel" exemple: github.com/reactjs/redux/tree/master/examples/real-world
- Alors permettez-moi de demander, si je veux garder une trace de userVideos lorsqu'elle est fondée sur le "monde réel" exemple je voudrais créer la pagination à l'écoute de mes trois liste des vidéos des actions: LIST_VIDEOS_REQUEST, LIST_VIDEOS_SUCCESS et LIST_VIDEOS_ERROR. Cela fonctionne très bien jusqu'à ce que j'ai une autre action que je veux mettre à jour l'état par exemple. CREATE_VIDEO_SUCCESS
- Comment est-ce censé fonctionner si votre "maître" entité a un autre (plus petit, moins détaillée) modèle de votre "détails" de l'entité? Dans ce cas, vous auriez pas d'autre choix que d'utiliser une autre tranche de l'état de "maître" et "détails".
- Été de penser à la même chose... Actuellement mon application récupère la mise en cache de l'utilisateur à partir de entities.user[id] et l'utilise pour avec optimisme remplir la page des détails alors qu'il fait une requête en arrière-plan pour récupérer tous les détails. Donc entities.user contient un sac mélangé. Certains utilisateurs ont seulement quelques champs, les autres utilisateurs ont tous les domaines (une fois que les détails ont été extraits pour). L'avantage de ceci est que vous très rapidement voir certains détails rempli dans la page de détails pour tout utilisateur qui a déjà récupéré. La page de détails toujours fait une demande de récupération de sorte entité devient up-to-date avec la DB.
- C'est exactement le problème, je suis confronté à droite maintenant, concernant l'architecture de mon application. Nous avons un point de terminaison qui retourne des agrégés champs pour l'affichage de la liste (par exemple, les catégories de la liste avec le nombre de produits), mais la catégorie individuelle modèle ont l'habitude de ce champ. Je pense de maintenir à un autre magasin pour l'affichage de la liste des pistes de la pagination/recherche etc et de magasins différents pour les différents modèles.
InformationsquelleAutor Dan Abramov

Vous devez vous connecter pour publier un commentaire.