Fornecerei um argumento a favor de ações "burras".
Ao colocar a responsabilidade de coletar dados de exibição em suas Ações, você as associa aos requisitos de dados de suas visualizações.
Por outro lado, as Ações genéricas, que descrevem declarativamente a intenção do usuário, ou alguma transição de estado em seu aplicativo, permitem que qualquer Loja que responda a essa Ação transforme a intenção em um estado personalizado especificamente para as visualizações nele subscritas.
Isso se presta a lojas mais numerosas, porém menores e mais especializadas. Eu argumento por esse estilo porque
- isso oferece mais flexibilidade na maneira como as visualizações consomem Dados da loja
- As lojas "inteligentes", especializadas nas visualizações que as consomem, serão menores e menos acopladas a aplicativos complexos do que as ações "inteligentes", das quais potencialmente muitas visualizações dependem
O objetivo de uma loja é fornecer dados para visualizações. O nome "Ação" sugere para mim que seu objetivo é descrever uma alteração no meu Aplicativo.
Suponha que você precise adicionar um widget a uma exibição existente do Painel, que mostra alguns novos dados agregados sofisticados que sua equipe de back-end acabou de lançar.
Com as ações "inteligentes", pode ser necessário alterar a ação do "painel de atualização" para consumir a nova API. No entanto, "Atualizando o painel" em um sentido abstrato não mudou. Os requisitos de dados de suas visualizações são o que mudou.
Com Ações "burras", você pode adicionar uma nova Loja para o novo widget consumir e configurá-la para que, quando receber o tipo de ação "painel de atualização", envie uma solicitação para os novos dados e a exponha a o novo widget quando estiver pronto. Faz sentido para mim que, quando a camada de visualização precisar de mais ou de dados diferentes, as coisas que eu altero serão as fontes desses dados: Lojas.