Dva: モデルの設計

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

@にこぐ
この例には「単一ページ」+「単一データ」しか含まれていないため、この例は私の質問には答えないと思います。
したがって、モデルを「ページ」ごとに分割すること、またはモデルを「データ」ごとに分割することと理解することができます。
PS: 「ページ」部門 ここで言及されているモデルは、各ページのモデルの作成を指し、「データ」部門のモデルは、各独立したデータユニットまたはビジネスロジックのモデルの作成を指します。

この例の理解:
1.「ページ」区分 モデル---新しいページがある場合、そのページにはコメントリストとそれに対応するユーザーリストが表示されます。次に、この新しいページに使用する usersAndMessages というモデルを作成する必要があります。
2. モデルの「データ」分割 --- このページにコメントの一覧を表示したい場合は、コメントという別のモデルを作成する必要があります。

私の理解では、「ページ」は「モデル」に対応するはずです。
しかし、「ページ」間で再利用する必要がある一部のパーツでこの問題に対処する方法
結局、再利用されたアクションとリデューサーをモデルから分離する必要がありますか?
しかし、これは従来の redux の書き方に戻っていないでしょうか。

私の理解では、「ページ」は「モデル」に対応するはずです。

モデルとページは必ずしも対応する必要はなく、別々に設計することができ、ページ上で必要なすべてのデータをconnectで取得できます。

@sorrycc
つまり、「データのラチチュード」と「ページのラチチュード」を完全に分離して、異なるモデルを作成し、対応する「ページのラチチュード」モデルと必要な「データ ディメンション」のモデルをページに接続することができます。

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

@zerozaki0752はい。

@sorryccありがとうございます！ ! !

もう 1 つの質問は、アクションの発見デモにおけるいくつかの問題についてです。
1. モデル内のエフェクトとレデューサーで定義されたメソッド。一部はモデルによって内部的に使用され、一部はビューによって呼び出されます (明確な区別はありません)
2. デモでは、アクションを呼び出すビューは、このようにディスパッチ "namespace/functionName" と呼ばれます
3. 2 番目のパラメータ mapDispatchToProps は、接続時に渡されません。

私の期待する効果は、モデル内のビューによって呼び出される必要があるものをカプセル化することであり、 mapDispatchToProps がビューにインポートされ、毎回ディスパッチすることなく、ビューの props.namespace_functionName を介してアクションを直接トリガーできます。

これは合理的かどうか疑問に思いますか？実現可能ですか？

これは個人的な習慣です。私は、dispatch(action) メソッドを好みます。

アクションをバインドするために mapDispatchToProps パラメーターが接続に渡されませんが、ディスパッチを使用して任意のモデルのアクションに転送できますか?

connectコンポーネントには、 dispatch props があります。