Dva: Conception de modèles

https://github.com/dvajs/dva-docs/blob/master/v1/zh-cn/tutorial/03-%E8%AE%BE%E8%AE%A1Model.md

@nikogu
Je pense que cet exemple ne répond pas à ma question car cet exemple ne concerne que "page unique" + "données uniques"
Ainsi, cela peut être compris comme divisant les modèles par "pages", ou cela peut être compris comme divisant les modèles en fonction de "données".
PS : La division "page" Models mentionnée ici fait référence à la création d'un modèle pour chaque page, et la division "data" Models fait référence à la création d'un modèle pour chaque unité de données indépendante ou logique métier.

Compréhension de cet exemple :
1. Modèles de division "Page" --- S'il y a une nouvelle page, la page affiche la liste des commentaires et sa liste d'utilisateurs correspondante. Ensuite, vous devez créer un modèle appelé usersAndMessages à utiliser pour cette nouvelle page.
2. Modèles de division de "données" --- Si vous devez afficher une liste de commentaires sur cette page, vous devez créer un autre modèle appelé commentaires.

Ma compréhension devrait être qu'une "page" correspond à un "modèle".
Mais comment régler ce problème avec certaines parties qui doivent être réutilisées entre "pages" ?
Au final, faut-il séparer les actions et réducteurs réutilisés des modèles ?
Mais ce retour à la manière traditionnelle d'écrire n'est-il pas redux ?

Ma compréhension devrait être qu'une "page" correspond à un "modèle".

Le modèle et la page n'ont pas besoin de correspondre, ils peuvent être conçus séparément et toutes les données nécessaires sur la page peuvent être obtenues via connect.

@désolé
En d'autres termes, je peux complètement séparer la "latitude des données" et la "latitude de la page", créer des modèles différents, connecter le modèle "latitude de la page" correspondant et le modèle "dimension des données" requis dans la page, non? .

function mapStateToProps(state) {
  return {
    // 数据维度创建的model
    users: state.users,
    comments:state.comments,
    // 页面维度创建的model
    homePage:state.homePage,
  };
}

@zerozaki0752 Oui.

@désolé Merci ! ! !

Une autre question concerne certains problèmes dans la démonstration de découverte de l'action
1. Les méthodes définies dans les effets et les réducteurs dans le modèle, certaines sont utilisées en interne par le modèle, et certaines doivent être appelées par la vue (il n'y a pas de distinction claire)
2. Dans la démo, la vue pour appeler l'action s'appelle dispatch "namespace/functionName" comme ceci
3. Le deuxième paramètre mapDispatchToProps n'est pas transmis lors de la connexion

Mon effet attendu est d'encapsuler ce qui doit être appelé par la vue dans le modèle, puis mapDispatchToProps est importé dans la vue, et l'action peut être déclenchée directement via props.namespace_functionName dans la vue sans avoir à envoyer à chaque fois.

Je me demande si c'est raisonnable ? Est-ce faisable ?

C'est une habitude personnelle, je préfère la méthode dispatch.

Le paramètre mapDispatchToProps n'est pas transmis à la connexion pour lier l'action, mais pouvez-vous utiliser la répartition pour transférer vers l'action dans n'importe quel modèle ?

Le composant connect aura des props de dispatch .