Dans le chapitre sur la Conception de la Forme État, la documentation suggère de garder votre état d'un objet identifié par ID:
Garder chaque entité dans un objet stocké avec un ID comme clé, et d'utiliser les Id de référence à partir d'autres entités, ou des listes.
Ils vont à l'état
Pensez à l'application de l'état d'une base de données.
Je suis en train de travailler sur l'état de forme pour une liste de filtres, dont certaines seront ouvertes (elles sont affichées dans une fenêtre popup) ou des options choisies. Quand j'ai lu "Penser à l'application de l'état d'une base de données, j'ai pensé à les penser comme une réponse JSON comme il serait retourné à partir d'une API (lui-même soutenu par une base de données).
Donc, je pensais à elle comme
[{
id: '1',
name: 'View',
open: false,
options: ['10', '11', '12', '13'],
selectedOption: ['10'],
parent: null,
},
{
id: '10',
name: 'Time & Fees',
open: false,
options: ['20', '21', '22', '23', '24'],
selectedOption: null,
parent: '1',
}]
Cependant, les docs proposer un format plus comme
{
1: {
name: 'View',
open: false,
options: ['10', '11', '12', '13'],
selectedOption: ['10'],
parent: null,
},
10: {
name: 'Time & Fees',
open: false,
options: ['20', '21', '22', '23', '24'],
selectedOption: null,
parent: '1',
}
}
En théorie, il ne devrait pas d'importance aussi longtemps que les données sont sérialisables (sous la rubrique "État").
Je suis donc allé avec le tableau des objets de l'approche joyeusement, jusqu'à ce que j'ai écrit mon réducteur.
Avec l'objet-clé-en-id de l'approche (et l'utilisation libérale de la propagation de la syntaxe), l' OPEN_FILTER
de la partie du réducteur devient
switch (action.type) {
case OPEN_FILTER: {
return { ...state, { ...state[action.id], open: true } }
}
Alors que le tableau d'objets, c'est le plus détaillé (et l'aide de la fonction tributaires)
switch (action.type) {
case OPEN_FILTER: {
// relies on getFilterById helper function
const filter = getFilterById(state, action.id);
const index = state.indexOf(filter);
return state
.slice(0, index)
.concat([{ ...filter, open: true }])
.concat(state.slice(index + 1));
}
...
Donc mes questions sont de trois ordres:
1) c'Est la simplicité de l'réducteur de la motivation pour aller avec l'objet-clé-by-id approche? Existe-il d'autres avantages à cet état de forme?
et
2) Il me semble que l'objet de la carrosserie-by-id approche rend plus difficile à traiter avec la norme JSON in/out pour une API. (C'est pourquoi je suis allé avec le tableau d'objets en premier lieu.) Donc, si vous allez avec cette approche, ne vous utilisez simplement une fonction pour le transformer-et-vient entre le format JSON et de l'état de forme de format? Qui semble maladroit. (Mais si vous avez l'avocat qui approche, c'est une partie de votre raisonnement, que c'est moins maladroit que le tableau d'objets réducteur ci-dessus?)
et
3) je sais que Dan Abramov conçu redux à la théorie de l'état de la structure des données agnostique (comme l'a suggéré "Par convention, le haut niveau de l'état est un objet ou une autre touche de la valeur de la collection comme une Carte, mais techniquement, il peut être n'importe quel type," c'est moi qui souligne). Mais compte tenu de ce qui précède, c'est juste de l' "recommandée" pour garder un objet identifié par ID, ou il y en a d'autres imprévus des points de douleur, je vais courir à l'aide d'un tableau d'objets qui font que je doit tout abandonner et essayer de s'en tenir à un objet identifié par ID?