Pessoal, em uma arquitetura Flux temos Stores, e elas tem o objetivo de centralizar a modificação do state da aplicação. Porém uma dúvida que me vem à mente é a seguinte: qual realmente é o escopo de uma "aplicação" que deve ser tratado pela Store. Tipo em um sistema onde tenho 4 abas (rotas/menus), em que cada um deles dá acesso a uma parte totalmente independente da outra no sistema, e que o estado delas é diferente, deveríamos ter 4 Stores correto? Uma para cada "aplicação". Pergunto isso porque direto vejo tutoriais em que o povo abomina ter mais de uma Store, porém nesse caso é o mais correto a se fazer. Estou certo?
2
respostas
respostas
Escopo da store em arquitetura Flux
Acho que a idéia é realmente ter uma única Store, para não ter que replicar os states e valores. Mesmo tendo abas e rotas diferentes o conceito de ter uma única Store que centralize faz mais sentido isso porque cada aba só terá métodos para acessar os States que fazem sentido para ele.
A idéia do Flux é que você terá States que podem ser utilizados em qualquer aba e os dados sejam replicados automaticamente sem a necessidade de replicar os States, por isso uma única Store.
O pattern em si não fala sobre ter uma store ou mais, depende da implementação.. A lib flux.js em si, sugere a utilização de várias stores, mas assim como Márcio , eu acho que atrapalha mais que ajuda.
Uma store tem todos os dados necessários da aplicação e cada parte só usa o que quiser. Se vc usa uma lib que favorece imutabilidade, como um redux da vida, ainda nem precisa se preocupar se vai alterar dados que outra ponta dá aplicação tá usando.