Historicamente, tem havido muitos padrões MVC, cada um fazendo as coisas de maneira um pouco diferente. Em geral, a maioria dos padrões MVC considera três funções:

• Modelo : gerencia o comportamento e os dados do domínio do aplicativo
• View : representa a exibição do modelo na interface do usuário
• Controlador : recebe a entrada do usuário, manipula o modelo e faz com que a visualização seja atualizada

• Separando a apresentação do modelo:
  permite a implementação de diferentes UIs e melhor testabilidade
• Separando o controlador da exibição:
  Mais útil com interfaces da web e não comumente usado na maioria dos frameworks GUI

MVC é um padrão lendário que tem sido usado para vários projetos desde 1976 (foi introduzido no Smalltalk-76). Ele resistiu ao teste do tempo e a maioria dos maiores projetos ainda o usa hoje. Por que tentar substituí-lo?

O MVC não escalou bem para a enorme base de código do Facebook. O principal problema para eles era a comunicação bidirecional, onde uma alteração pode retornar e ter efeitos em cascata na base de código (tornando as coisas muito complicadas de depurar e entender).

Como o Flux resolve isso? Forçando um fluxo unidirecional de dados entre os componentes de um sistema.

Em geral o fluxo dentro do padrão MVC não é bem definido. Muitas das implementações maiores fazem isso de maneira muito diferente (por exemplo, Cocoa MVC vs. Ruby on Rails MVC).

O Flux, por outro lado, trata de controlar o fluxo dentro do aplicativo - e torná-lo o mais simples possível de entender.

O núcleo do padrão Flux

O Flux tem quatro papéis: ações, armazenamentos, despachante e visualizações. Suas responsabilidades podem ser definidas da seguinte forma:

• Ações são objetos simples com uma propriedade de tipo e alguns dados. Por exemplo, uma ação pode ser {“type”: “IncreaseCount”, “local_data”: {“delta”: 1}}
• As lojas contêm o estado e a lógica do aplicativo. A melhor abstração é pensar nas lojas como gerenciando um determinado domínio do aplicativo. Eles não são iguais aos modelos no MVC, pois os modelos geralmente tentam modelar objetos únicos, enquanto as lojas no Flux podem armazenar qualquer coisa
• O Despachante atua como um hub central. O dispatcher processa ações (por exemplo, interações do usuário) e invoca callbacks que as lojas registraram com ele. O despachante não é o mesmo que os controladores no padrão MVC — geralmente o despachante não tem muita lógica dentro dele e você pode reutilizar o mesmo despachante em projetos
• Visualizações são visualizações de controladores, também muito comuns na maioria dos padrões GUI MVC. Eles ouvem as mudanças nas lojas e se renderizam apropriadamente. As visualizações também podem adicionar novas ações ao expedidor, por exemplo, nas interações do usuário. As views geralmente são codificadas em React , mas não é necessário usar React com Flux

O mais importante a ser observado é que toda alteração ocorre por meio de uma ação do despachante, ilustrada assim:

Então, como o Flux é diferente do MVC?

• O Flow do aplicativo é essencial para o Flux e existem regras muito rígidas que são aplicadas pelo Despachante. No MVC, o fluxo não é aplicado e a maioria dos padrões MVC o implementa de maneira diferente
• Fluxo unidirecional: toda alteração passa pelo despachante. Uma loja não pode alterar outras lojas diretamente. O mesmo se aplica a exibições e outras ações. As alterações devem passar pelo despachante por meio de ações. No MVC é muito comum ter fluxo bidirecional
• As lojas não precisam modelar nada e podem armazenar qualquer estado relacionado ao aplicativo. Nos modelos MVC, tente modelar algo, geralmente objetos únicos

Na próxima seção, mostrarei um contra-exemplo simples usando um padrão MVC do Cocoa e outro usando o Flux. Ambos são implementados em CoffeeScript.

Esses exemplos devem facilitar o entendimento de como o código funciona e como é a estrutura geral.

MVC do cacau

Deve ser bem direto. Muitos outros MVCs de GUI seguem uma convenção semelhante à do Cocoa.

O fluxo ilustrado do exemplo Cocoa se parece com isto:

Fluxo e Reação

Este código abaixo não foi testado, mas deve dar uma ideia clara de como as diferentes funções funcionam dentro do sistema Flux.

Ilustrado, o fluxo do Flux se parece com isso:

O Flux é melhor que o MVC?

Ainda estamos muito no início do processo para determinar isso. Dito isso, é incrível termos um novo padrão que desafia o MVC e a velha maneira de fazer as coisas. O fato de esse padrão vir do Facebook é um ótimo sinal, pois eles têm pessoas inteligentes trabalhando nisso e sua base de código é enorme e espalhada por muitos produtos diferentes.

Na Doist , estamos usando Flux e React para um projeto maior e a base de código até agora parece muito limpa e é um prazer trabalhar com ela.

Em geral, estou mais impressionado com o Flux do que com o React. O motivo é que o Flux é muito simples de entender e quase não há código para isso - é apenas uma maneira de estruturar melhor seu aplicativo. Enquanto isso, o React tem uma enorme base de código e uma enorme complexidade de tempo de execução da qual não sou um grande fã.