Uma breve introdução ao Flux

O Flux é uma arquitetura de Software que o Facebook utiliza para construir o front-end de suas aplicações. Flux é mais um conjunto de padrões do que um framework e você pode iniciar o uso de Flux imediatamente em seus projetos, sem ter que escrever ou reescrever muito código.

A criação do Flux ocorreu pois precisava-se de um padrão que resolvesse alguns problemas muito comuns do desenvolvimento front-end, tais como:

  • Padronização do fluxo da arquitetura para reduzir o tempo que leva aos desenvolvedores para entenderem o código de seus colegas.
  • Reduzir a replicação de código e regras de negócio.
  • Facilitar a manutenção do sistema.
  • Tornar mais simples de implementar novas funcionalidades que impactam diversas partes do sistema.
  • Automatizar a atualização do estado de um dado que é lido em diversos lugares.

O Flux possui 4 elementos:

  1. Action: São coleções de métodos que são chamadas pelas nossas Views, que enviam ações para o Dispatcher contendo payloads, que serão entregues aos Stores.
  2. Dispatcher: É o componente que gerencia basicamente todo o processo da nossa aplicação. O ponto central são os métodos Register e Dispatch, que são triggers de eventos entre a ação que disparou o evento e as stores registradas. Ele simplesmente recebe a Action e propaga para as stores que irá identificá-la e disparar um evento caso registrado.
  3. Stores: São os locais onde ficam armazenados a lógica e estado da aplicação, que tem call-backs registrados para o Dispatcher.
  4. (Controller) Views: Responsáveis por permitir que o usuário interaja com a aplicação e por mostrar a ele o estado atual dela.

O Dispatcher é único para toda a aplicação, dessa forma só existe um único elemento responsável por receber as Actions realizadas nas Views e dispará-las para as Stores da aplicação. Toda mudança no estado da aplicação somente pode ser realizada através de uma Action.

A principal característica do Flux é o fluxo unidirecional de dados. Sem alterações em cascata, a cada Action um novo estado é gerado. Dessa forma, o estado da aplicação é previsível, sendo mais simples de testar. Com a lógica de negócio concentrada em um local (nas Stores), fica mais fácil encontrar e corrigir bugs.

O que é MVC e MVVM?

O que é MVC?

O MVC é um padrão arquitetural de para o desenvolvimento que existe desde os anos 70 e foca em dividir a aplicação em 3 camadas: Model, View e Controller.

  • O Model representa a camada contendo as regras de negócio e acesso a dados. No JavaScript, está normalmente á a camada que faz a chamada aos WebServices.
  • A View representa o componente de interface do usuário, como por exemplo as páginas HTML.
  • O Controller atua como intermediário entre o Model e a View. Ele recebe requisições da View, faz o processamento para buscar os dados no Model e por último, processa e retorna o resultado recebido para a View.

Vantagens:

  • Alto nível de coesão: o MVC permite o agrupamento lógico de ações relacionadas, tornando fácil de saber quem é e onde está o código de partes do sistema.
  • Baixo acoplamento: A própria natureza da estrutura MVC é tal que existe um baixo acoplamento entre Models, Views e Controllers.
  • Facilidade de modificação: Devido à separação de responsabilidades, o desenvolvimento ou modificação futura é mais fácil, ou seja, a escalabilidade do produto aumenta.

Desvantagens:

  • Navegabilidade de código: A navegação da estrutura pode ser complexa porque introduz novas camadas de abstração e requer que os usuários se adaptem aos critérios de decomposição do MVC.
  • Várias representações: decompor um recurso em três camadas causa dispersão. Portanto, exigindo que os desenvolvedores mantenham a consistência de várias representações ao mesmo tempo.

O que é MVVM?

MVVM é a sigla para Model View ViewModel. Ele foi inicialmente desenvolvido pela Microsoft com o intuito de ser utilizado no com o WPF e Silverlight, mas atualmente vem sendo utilizado por diversos desenvolvedores JavaScript. Muitos frameworks como o Angular, Knockoutjs e Aurelia suportam a utilização do MVVM.

Nesta arquitetura, o Model tem função similar ao do MVC, representando o domínio de dados da aplicação. Já a View e a ViewModel possuem conceitos um pouco diferentes.

  • View é a camada com o qual o usuário interage e neste padrão, ela considerada ativa. Isto significa que elas possuem Data Bindings (vinculação de dados) com o ViewModel para que ambos estejam em sincronia.
  • O ViewModel atua como um conversor de dados, transformando os dados do Model para informações que possam ser utilizadas pela View e passando os comandos da View para o Model. Ele também ajuda a manter o estado da View e atualiza o Model de acordo com as ações do Usuário. A View e o ViewModel estão conectados através do Data Binding, que permite a propagação automática destas mudanças. Existem 2 formas de Data Binding:
    • Two Way: Quando uma alteração na View ou na ViewModel automaticamente atualiza um ao outro.
    • One Way: Quando apenas alterações na View atualizam a ViewModel ou apenas o inverso.

Podemos citar como vantagens na utilização do MVVM:

  1. O desenvolvedor pode optar por reaproveitar um ViewModel em várias Views.
  2. O código para atualizar a View é pequeno, uma vez que as alterações podem ser propagadas automaticamente.
  3. O MVVM facilita o desenvolvimento paralelo da aplicação por vários desenvolvedores.

Já como desvantagens:

  1. É uma estrutura com uma complexidade maior e para aplicações pequenas poderá adicionar camadas e regras desnecessárias.
  2. Aplicações que possuem vários pontos de alteração de um mesmo Model, podem acabar exibindo dados desatualizados.