Mas, talvez seja mais f\u00e1cil come\u00e7ar falando o que Flux n\u00e3o \u00e9 e com o que ele n\u00e3o deve ser comparado para facilitar o entendimento!<\/p>\n\n\n\n
Flux n\u00e3o \u00e9<\/strong> um framework ou biblioteca. <\/p>\n\n\n\n Comparemos ele com a arquitetura MVC<\/strong>.<\/p>\n\n\n\n No lugar de dividir a aplica\u00e7\u00e3o entre Model, View e Controller, com Flux h\u00e1 a sugest\u00e3o de dividir em Stores, Dispatcher, Views, Action\/Action Creators<\/strong>.<\/p>\n\n\n\n Uma vis\u00e3o simples <\/strong>da constru\u00e7\u00e3o desse fluxo seria algo como:<\/p>\n\n\n\n Talvez j\u00e1 tenha visto algumas imagens como essa quando estava tentando entender MVC.<\/p>\n\n\n\n E geralmente vinham com uma explica\u00e7\u00e3o de cada item, exatamente como farei agora:<\/p>\n\n\n\n Quando um evento ocorre, por exemplo:<\/p>\n\n\n\n Adicionar um novo item a uma lista.<\/p>\n\n\n\n H\u00e1 uma fun\u00e7\u00e3o de callback<\/strong>, que criar\u00e1 uma action <\/strong>com os dados necess\u00e1rios e envia como um objeto para o dispatcher<\/strong>.<\/p>\n\n\n\n O dispatcher, que tem registrado qual store receber\u00e1 tal action, envia os dados para a mesma.<\/p>\n\n\n\n E assim, como a store \u00e9 onde toda a l\u00f3gica do neg\u00f3cio est\u00e1, ir\u00e1 atualizar a view retornando os novos valores<\/strong>.\u00a0<\/p>\n\n\n\n Funciona bem<\/strong> para o estilo de programa\u00e7\u00e3o do React.<\/p>\n\n\n\n J\u00e1 que as stores enviam updates sem a necessidade de detalhar como ser\u00e1 a transi\u00e7\u00e3o entre states e views.<\/p>\n\n\n\n Isso prova o padr\u00e3o do Flux que segue um fluxo de dados unidirecional<\/strong>.\u00a0<\/p>\n\n\n\n A action, dispatcher, store e view s\u00e3o independentes <\/strong>com entradas e sa\u00eddas espec\u00edficas.<\/p>\n\n\n\n Os dados passam pelo dispatcher, que gerencia\u00a0 e age como um registro de todos os callbacks que as stores respondem.\u00a0<\/p>\n\n\n\n As stores emitem a mudan\u00e7a que ser\u00e1 pega pelas views.<\/p>\n\n\n\n Cada store registra um callback com o dispatcher.<\/p>\n\n\n\n Sempre que algum dado entra, o dispatcher \u00e9 o respons\u00e1vel para visualizar a action que est\u00e1 registrada e enviar para a store que fez o registro.<\/p>\n\n\n\n Por sua vez, retorna o resultado que, atualizando os dados, faz com que os componentes que tenham liga\u00e7\u00e3o com a store, sejam novamente renderizados com as novas informa\u00e7\u00f5e<\/strong>s! <\/p>\n\n\n\n Para muitos, o primeiro contato com uma arquitetura extremamente conhecida e poderosa \u00e9 a do MVC<\/strong>.<\/p>\n\n\n\n Que consiste basicamente de Model, que cuidar\u00e1 dos dados da aplica\u00e7\u00e3o View. <\/p>\n\n\n\n Representa a interface do usu\u00e1rio.<\/p>\n\n\n\n Por fim, o controller, que usa das entradas do usu\u00e1rio para manipular o model e atualiza a view com o novo conte\u00fado<\/strong>.<\/p>\n\n\n\n \u00c9 um Fluxo simples, mas que rendeu uma grande dor de cabe\u00e7a ao Facebook.\u00a0<\/p>\n\n\n\n Por terem uma base de dados gigantesca, fazia com que cada pequena mudan\u00e7a, houvesse um efeito cascata de fun\u00e7\u00f5es.<\/p>\n\n\n\n O problema foi apontado como sendo comunica\u00e7\u00e3o bidirecional do MVC<\/strong>.<\/p>\n\n\n\n J\u00e1 que o fluxo sempre segue a mesma linha, usu\u00e1rio usa o controller que manipula o model, assim atualizando a view que chega aos olhos do usu\u00e1rio.<\/p>\n\n\n\n Quantas vezes no pr\u00f3prio trabalho encontramos telas que tem que tomar o maior cuidado poss\u00edvel<\/strong>? <\/p>\n\n\n\n Por ser t\u00e3o poderosa <\/strong>que, na menor mudan\u00e7a, chamaria tantas fun\u00e7\u00f5es em sequ\u00eancia que ficaria dif\u00edcil at\u00e9 mesmo debugar o c\u00f3digo e realmente entender o que est\u00e1 sendo feito.<\/p>\n\n\n\n Para resolver o problema da comunica\u00e7\u00e3o bidirecional, o mesmo foi trocado por um fluxo unidirecional<\/strong>.<\/p>\n\n\n\n Onde, para uma compara\u00e7\u00e3o mais direta:<\/p>\n\n\n\n Certo!<\/p>\n\n\n\n Destrinchamos bastante da teoria, mas ela sem pr\u00e1tica <\/strong>n\u00e3o fixa bem, ent\u00e3o vamos ao fluxo de informa\u00e7\u00f5es no c\u00f3digo<\/strong>, parte por parte.<\/p>\n\n\n\n Usaremos partes do c\u00f3digo de uma TodoList (lista de afazeres) que est\u00e1 no reposit\u00f3rio do Facebook! <\/p>\n\n\n\n Come\u00e7amos carregando a lista:<\/p>\n\n\n\n![\"estados-flux\"](\"https:\/\/geekblogti.wpengine.com\/wp-content\/uploads\/2019\/12\/estados-flux.png\")
Destrinchando a teoria<\/h2>\n\n\n\n
![\"passos-flux\"](\"https:\/\/geekblogti.wpengine.com\/wp-content\/uploads\/2019\/12\/passos-flux.png\")
Fluxo <\/h3>\n\n\n\n
Compara\u00e7\u00e3o com o MVC e o Facebook<\/h2>\n\n\n\n
MVC<\/strong><\/td> Flux<\/strong><\/td><\/tr> Fluxo de dados bidirecional<\/em><\/td> Fluxo de dados unidirecional<\/em><\/td><\/tr> Liga\u00e7\u00e3o de dados \u00e9 a chave<\/em><\/td> Events e actions s\u00e3o as partes principais<\/em><\/td><\/tr> Os controllers cuidam da l\u00f3gica do neg\u00f3cio<\/em><\/td> A store faz todos os c\u00e1lculos<\/em><\/td><\/tr> S\u00edncrono<\/td> Pode ser implementado de forma completamente ass\u00edncrona!<\/td><\/tr> Uma arquitetura conhecida usada por diversas empresas e muitos projetos<\/td> Ajuda a resolver problemas complexos que o MVC n\u00e3o corrigia facilmente<\/td><\/tr><\/tbody><\/table>\n\n\n\n Exemplo em c\u00f3digo – TodoList<\/h2>\n\n\n\n