Na verdade, estou estudando o padrão de fluxo e há algo que não consigo entender a respeito do armazena .
O que são exatamente?
Eu li muitos artigos e parece que diz respeito ao domínio.
Isso significa que esta é a parte “abstrata” relacionada às chamadas de API ou back-end?
Não é muito claro para mim.
Editar: poderia ser a mesma coisa que a fábrica angular? Buscando dados remotos, fazendo uma tarefa de negócios ou armazenando alguns estados do aplicativo (usuário atual conectado, por exemplo)?
Comentários
- Um link para o que exatamente você ' falar sobre seria útil. Você quer dizer este " padrão de fluxo "? fluxxor.com/what-is-flux.html
- facebook.github. io / flux / docs / overview.html # content
- Flux nada mais é do que o padrão publicar / assinar com uma restrição de que todos os dados passam primeiro pelo despachante. Isso garante que os dados não retrocedam (e causem confusão). Coisas como " Store ", " Ação " etc são apenas outra maneira de dizer os componentes do sistema e os dados que são transmitidos.
Resposta
Ok, deixe-me explicar passo a passo
1 O que é Flux?
- Um padrão
- Distribuidor centralizado
- Fluxos de dados unidirecionais
- Item da lista
Eles também o chamam de Fluxo por um motivo.
Implementações de fluxo
- Fluxo do Facebook
- Alt
- Refluxo
- Flummox
- NuclearJS
- Fluxível
Um bate-papo com Flux
Reação : Ei, ação, alguém clicou em “Salvar Cour se ”botão.
Ação : Obrigado React! Registrei um criador de ação com o despachante, portanto, o despachante deve se encarregar de notificar todas as lojas que se importam.
Despachante : Deixe-me ver quem se importa com o fato de um curso ser salvo. Ah! Parece que a Loja registrou um retorno de chamada comigo, então vou informá-la.
Loja : Olá despachante! Obrigado pela atualização! Vou atualizar meus dados com a carga útil que você enviou. Em seguida, emitirei um evento para os componentes do React que se importam.
React : Ooo! Novos dados brilhantes da loja! Vou atualizar a IU para refletir isso!
API do Flux
register (callback de função) – “Ei, despachante, me execute quando as ações acontecerem. -Store ”
cancelar o registro (string id) -“ Ei despachante, pare de se preocupar com esta ação. -Store ”
waitFor (ids de matriz) -“ Atualize esta loja primeiro. –Store ”
despacho (carga útil do objeto) -“ Ei despachante, conte às lojas sobre esta ação . -Ação ”
isDispatching () -“ Estou ocupado despachando callbacks agora. ”
então a questão que surge em nossa mente é
Então o Flux é um modelo Publicar-Assinar?
Não exatamente.
Difere de duas maneiras:
1. Cada carga útil é enviada para todos os retornos de chamada registrados.
2.Callbacks podem esperar por outros callbacks
Resumo
Fluxo é um padrão para fluxos de dados unidirecionais. Ações encapsulam eventos O Dispatcher é um hub central que mantém retornos de chamada. Os armazenamentos mantêm o estado do aplicativo Muitas implementações
Comentários
- Meu primeiro problema esse estado permite que o aplicativo tenha dados diferentes das entidades API remotas: – /
- o que você quer dizer com estado permite? onde quer que seja chamado, emitir change será chamado de React View e novamente chamado de método de mudança de estado
- Admitindo que eu construo um aplicativo com fluxo. Estou lidando com uma API e, em seguida, salvo os dados dentro de minhas lojas. E se um usuário modificar os dados remotos? Terei uma diferença entre cliente e servidor
- agora, onde posso encontrar o porquê. Se tudo que o despachante e a loja vão fazer é encaminhar para a visualização, então por que a ação ' não pode atualizar a visualização diretamente.por que existem intermediários
- @MuhammadUmer: o Dispatcher é aquele para o aplicativo e o armazenamento é baseado no componente do aplicativo, para remover a redundância, os intermediários foram introduzidos
Resposta
Procurando um exemplo simples ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ), “Os armazenamentos gerenciam o estado do aplicativo para um domínio específico dentro do aplicativo.” Ou seja, eles contêm dados sobre o estado de um aspecto do aplicativo e todo o código para alterá-lo. Sempre que há uma nova atualização do Dispatcher, todas as Lojas a veem, eles decidem como atualizar seus dados em resposta e, em seguida, notificam as Visualizações de que os dados foram alterados. Nos exemplos, as Lojas contêm coisas como “lista de tópicos não vistos” (onde o Despachante os notifica que uma nova mensagem chegou ou que uma antiga foi lida, e as Visualizações exibem os tópicos de mensagens para o usuário) e “tempo de reprodução atual e state. ”
Mais tecnicamente: eles são a camada intermediária do framework que registra callbacks com o Dispatcher para receber atualizações, então notifica as Views quando o estado dos dados muda. (As visualizações podem então enviar ações de volta para o Dispatcher.) Há uma interface abstrata que eles implementam, onde cada Loja registra um retorno de chamada com o Dispatcher e transmite eventos para as Visualizações, mas cada Loja parece representar um domínio específico de uma forma concreta. (Existem contra-exemplos?)
Resposta
Armazenamentos são áreas do código que armazenam o estado do aplicativo e a lógica complexa. Um motivo para eles é que várias visualizações provavelmente usarão os mesmos dados, mas os exibirão de uma maneira diferente ou exibirão alguns, mas não todos os dados de um domínio específico. Por exemplo, um usuário efetua login e você recebe seu nome, sobrenome, e-mail, foto, cidade, número de endereço, número de telefone etc. Essas informações são exibidas em visualizações separadas. Em vez de duplicar dados entre visualizações, podemos usar um armazenamento chamado UserStore que armazena os dados para o usuário. Isso simplifica o sistema, dando “um lugar para fazer uma alteração” sempre que a lógica ou os dados armazenados devem ser alterados. Existem muitos outros motivos para usar uma Loja, mas acho que esse é o mais óbvio.