Fluxo Unidirecional

O conceito de fluxo unidirecional é uma abordagem alternativa ao consagrado padrão MVC que, conceitualmente, define um fluxo bidirecional (do modelo para a view e da view para o modelo).

O conceito de fluxo unidirecional de dados para atualização de interfaces com o usuário foi popularizado pela Arquitetura Flux, criada pelo Facebook.

A ideia central é que a view sempre é 100% gerada a partir do modelo que representa o estado atual da aplicação. Somente uma alteração no modelo pode desencadear a produção da nova versão da view.

Naturalmente que a ideia acima não deve ser entendida ao pé da letra pois se assim fosse seria uma abordagem completamente ineficiente. Na maior parte do tempo as alterações na página HTML são pontuais e não faria sentido gerar uma página totalmente nova.

Descrição Operacional

O entendimento operacional de como funciona a técnica de fluxo unidirecional ajuda a compreender porque esta abordagem é bastante eficiente.

A view de uma aplicação para web se materizaliza, em última análise, em uma página HTML que é representada internamente nos navegadores por uma árvore, a chamada árvore DOM. Qualquer alteração em um nodo desta árvore faz com que o navegador atualize o que é exibido ao usuário.

O mecanismo de atualização via fluxo unidirecional significa que a atualização da árvore sempre é feita em um único sentido, da raiz em direção às folhas. Assim, só é necessário atualizar as subárvores que tiverem algum alteração no seu nodo raiz. Frameworks como React e Angular utilizam o conceito de árvore DOM virtual para poderem detectar de forma muito eficiente se há diferença entre duas árvores virtuais. Nunca uma alteração de uma subárvore propagará mudanças para cima, em direção à raiz da árvore. É por isso que a recomendação é armazenar o estado da aplicação na raiz da árvore.

Descrição Prática

Em termos práticos, para o desenvolvedor da aplicação, o conceito de fluxo unidirecional funciona com base no seguinte algoritmo:

1. O usuário realiza uma ação (clica em um botão, preenche um campo de formulário, clica em um link, etc).

2. Esta ação (que contém os dados envolvidos) desencadeia uma mudança no estado da aplicação (alteração de valores de variáveis), gerando um novo estado, derivado do estado anterior.

3. O novo estado desencadeia o processo de gerar uma nova versão da view que utiliza este novo estado como base.

4. A nova versão da view então é exibida ao usuário.

Como a view sempre é gerada a partir do estado atual da aplicação é impossível que ela contenha inconsistências (dados desatualizados).

Redux

Redux é uma biblioteca para gerenciar o estado de uma aplicação JavaScript. Criada por Dan Abramov, ela se tornou extremamente popular e transcendeu para "estilo redux de gerenciamento de estado".

O principal objetido da biblioteca/estilo Redux é separar todo código responsável por "administrar" o estado de uma aplicação do resto, responsável pela visualização do estado.

Conceitos

A biblioteca Redux está baseada em 3 conceitos fundamentais.

Actions

Actions são objetos JavaScript que representam o desejo manifestado pelo usuário ao interagir com a "view" da aplicação.

Mais especificamente, uma action é um objeto que possui pelo menos o atributo type cujo valor define unicamente o tipo da ação.

O importante, do ponto de vista metodológico, é que o desenvolvedor precisa definir explicitamente o conjunto de ações possíveis. Não importa como o usuário faz para manifestar seu desejo.

Reducer

Reducer é uma função JavaScript pura que a partir do estado atual e de uma ação produzem o novo estado da aplicação.

A função do tipo reducer tem, esquematicamente a seguinte assinatura:

(estadoAtual, acao) => novoEstado

A função reducer implementa as regras de negócio associada à aplicação. Quando a aplicação é mais complexa, o que geralmente é o caso, é possível definir várias funções do tipo reducer e depois combiná-las em uma única função.

Como as funções reducer devem ser puras, elas não podem alterar o conteúdo do objeto que representa o estado atual da aplicação. Essa disciplina pode ser facilitada com bibliotecas como a Immutable(http://facebook.github.io/immutable-js/).

Store

Todo os dados que representam o estado da aplicação são representados em um único objeto. No jargão Redux este objeto é chamado de store.

O store possui as seguintes funcionalidades:

• armazenar o estado da aplicação
• permitir o acesso ao estado via método getState()
• permitir a atualização do estado via método dispatch(action)
• registrar uma função listener que será executada sempre que houver alteração no estado da aplicação via método subscribe(listener). Esta função retorna uma função que permite remover a função listener.
• remover a função listener.

Redux e React

A "filosofia/biblioteca" Redux combina perfeitamente com a biblioteca React.

Relembrando, a biblioteca React serve para programar a view de uma aplicação. Cada componente React representa uma parte desta view.

Um componente React típico possui dois atributos:

• state : representa o estado do componente
• props : representa propriedades imutáveis do componente

Um componente React que não possua estado pode ser compreendido e implementado em JavaScript como uma função pura cujo objetivo é renderizar um fragmento de código HTML a partir dos dados armazenados em props.

Uma aplicação React sempre contém um componente React que representa toda a view. Logo, este componente/função pode ser registrado como listener de um store. Assim, sempre que houver mudança no store (atualização do estado da aplicação), a função/componente será invocada para gerar a nova view.

A comunicação entre o componente React e o store é trivial, basta que o store seja uma das propriedades (atributo props) do componente.

MVI

A sigla MVI é o acrônimo para um padrão de projeto chamado Model-View-Intent (Modelo-Visão-Intenção). Ele surgiu como alternativa ao consagrado padrão MVC e sintetiza a abordagem de fluxo unidirecional para atualização de dados.

A rigor o padrão deveria ser conhecido como IMV pois é esta a sequência que caraceriza o fluxo unidirecional:

1. O usuário manifesta sua Intenção.

2. A intenção é processada gerando um novo Modelo.

3. O novo modelo é usado para produzir a nova Visão.

Assim, por "razões de marketing" (ressaltar sua relação com o padrão MVC) o padrão é chamado de MVI e não IMV.