Dva: Desenho de Modelos

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

@nikogu
Acho que este exemplo não responde à minha pergunta porque ele envolve apenas "página única" + "dados únicos"
Portanto, pode ser entendido como uma divisão de Modelos por "páginas", ou pode ser entendido como uma divisão de Modelos por "dados".
PS: Os Modelos de divisão de "página" mencionados aqui se referem à criação de um modelo para cada página, e os Modelos de divisão de "dados" se referem à criação de um modelo para cada unidade de dados independente ou lógica de negócios.

Compreensão deste exemplo:
1. Modelos de divisão "Página" --- Se houver uma nova página, a página exibe a lista de comentários e sua lista de usuários correspondente. Em seguida, você deve criar um modelo chamado usersAndMessages para usar nesta nova página.
2. Modelos de divisão de "dados" --- Se você precisa exibir uma lista de comentários nesta página, você precisa criar outro modelo chamado comentários.

Meu entendimento deveria ser que uma "página" corresponde a um "modelo".
Mas como lidar com esse problema com algumas peças que precisam ser reaproveitadas entre as "páginas"?
No final, devemos separar as ações reutilizadas e redutores dos modelos?
Mas isso não retorna à forma tradicional de reduxar redux?

Meu entendimento deveria ser que uma "página" corresponde a um "modelo".

O modelo e a página não precisam corresponder um ao outro, podem ser desenhados separadamente e todos os dados necessários na página podem ser obtidos por meio do Connect.

@sorrycc
Em outras palavras, posso separar completamente a "latitude de dados" e a "latitude de página", criar modelos diferentes, conectar o modelo de "latitude de página" correspondente e o modelo de "dimensão de dados" necessário na página, certo?

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

@ zerozaki0752 Sim.

@sorrycc Obrigado! ! !

Outra questão é sobre alguns problemas na demonstração de ação de descoberta
1. Os métodos definidos nos efeitos e redutores do modelo, alguns são usados ​​internamente pelo modelo e alguns são chamados pela vista (não há distinção clara)
2. Na demonstração, a visão para chamar a ação é chamada de despacho "namespace / functionName" assim
3. O segundo parâmetro mapDispatchToProps não é passado durante a conexão

Meu efeito esperado é encapsular o que precisa ser chamado pela visualização no modelo e, em seguida, mapDispatchToProps é importado para a visualização e a ação pode ser acionada diretamente por meio de props.namespace_functionName na visualização sem ter que despachar cada vez.

Será que isso é razoável? Isso é viável?

Este é um hábito pessoal, prefiro o método de despacho (ação).

O parâmetro mapDispatchToProps não é passado em connect para vincular a ação, mas você pode usar o dispatch para transferir para a ação em qualquer modelo?

O componente que é connect terá adereços de dispatch .