Dva: Design von Modellen

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

@nikogu
Ich denke, dieses Beispiel beantwortet meine Frage nicht, da dieses Beispiel nur "einzelne Seite" + "einzelne Daten" beinhaltet.
Es kann also als Aufteilung von Modellen durch "Seiten" oder als Aufteilung von Modellen nach "Daten" verstanden werden.
PS: Der hier erwähnte Bereich "Seiten" bezieht sich auf die Erstellung eines Modells für jede Seite, und der Bereich "Daten" bezieht sich auf die Erstellung eines Modells für jede unabhängige Dateneinheit oder Geschäftslogik.

Verständnis dieses Beispiels:
1. "Seiten"-Unterteilungsmodelle --- Wenn eine neue Seite vorhanden ist, zeigt die Seite die Kommentarliste und die entsprechende Benutzerliste an. Dann sollten Sie ein Modell namens usersAndMessages erstellen, das für diese neue Seite verwendet wird.
2. "Daten"-Teilungsmodelle---Wenn Sie eine Liste von Kommentaren auf dieser Seite anzeigen möchten, müssen Sie ein weiteres Modell namens "Kommentare" erstellen.

Mein Verständnis sollte sein, dass eine "Seite" einem "Modell" entspricht.
Aber wie geht man mit diesem Problem bei einigen Teilen um, die zwischen "Seiten" wiederverwendet werden müssen?
Am Ende müssen wir die wiederverwendeten Aktionen und Reduzierer von den Modellen trennen?
Aber kehrt das nicht zur traditionellen Schreibweise von Redux zurück?

Mein Verständnis sollte sein, dass eine "Seite" einem "Modell" entspricht.

Das Modell und die Seite müssen nicht übereinstimmen, sie können separat gestaltet werden und alle auf der Seite benötigten Daten können über connect bezogen werden.

@sorrycc
Mit anderen Worten, ich kann "Datenbreite" und "Seitenbreite" komplett trennen, verschiedene Modelle erstellen, das entsprechende "Seitenbreite"-Modell und das erforderliche "Datendimensions"-Modell in der Seite verbinden, oder? .

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

@zerozaki0752 Ja.

@sorrycc Danke! ! !

Eine andere Frage betrifft einige Probleme in der Discovery-Demo von Action
1. Die in den Effekten und Reduzierern im Modell definierten Methoden, einige werden intern vom Modell verwendet und einige sind vom View aufzurufen (keine klare Unterscheidung)
2. In der Demo heißt die Ansicht zum Aufrufen der Aktion wie folgt "dispatch "namespace/functionName"
3. Der zweite Parameter mapDispatchToProps wird beim Verbinden nicht übergeben

Mein erwarteter Effekt besteht darin, das zu kapseln, was von der Ansicht im Modell aufgerufen werden muss, und dann wird mapDispatchToProps in die Ansicht importiert, und die Aktion kann direkt über props.namespace_functionName in der Ansicht ausgelöst werden, ohne jedes Mal abzusetzen.

Ich frage mich, ob das vernünftig ist? Ist es machbar?

Dies ist eine persönliche Gewohnheit, ich bevorzuge die Versandmethode (Aktion).

Der Parameter mapDispatchToProps wird nicht in Connect übergeben, um die Aktion zu binden, aber können Sie Dispatch verwenden, um die Aktion in einem beliebigen Modell zu übertragen?

Die Komponente connect hat Requisiten von dispatch .