Preact, React & Flux (Anotações)

Submitted by kaleu on Wed, 04/29/2020 - 11:28

Este artigo apresenta links e anotações pessoais de estudos relacionados ao ecossistema React.

Flux

Atuo há algumas semanas com Vuex (implementação de estado semelhante ao Flux, para o Vue) em um projeto. Tenho ouvido bastante sobre React e Flux. Estas anotações focam em compreender a gestão de estado em aplicações front end modernas.

No vídeo inicial da página do Vuex, na seção “What is Vuex?” o autor explica o funcionamento do Vuex que está baseado:

  • Ser uma única fonte de dados de todas as Views
  • Ter um sistema de actions que disparam mudanças nesta fonte dados;
  • Ter um sistema de reatividade, que permite às Views mudarem quando os dados mudam (sem se importar sobre quem ou quando a action foi executada).

No site original do Facebook / Flux, há um vídeo de uma engenheira de software do Facebook explicando como eles chegaram no conceito do Flux:

O vídeo é curto e ela explica o problema no chat do Facebook que originou a busca por uma nova forma de trabalhar com dados e views.

Basicamente, o problemas chave era a via de mão dupla, onde ao alterar os modelos, eles tinham que alterar as views e ao alterar uma view, os modelos tinham que ser atualizados. O potencial de gerar loops e problemas de performance em geral é grande. É um modelo um tanto óbvio e fácil de programar no início, mas que gera muita dificuldade depois, fortemenete imperativo.

Uma das principais linhas de solução foi converter o fluxo para um fluxo de mão única.

Uma metáfora (o trânsito)

Podemos pensar como uma rua muito movimentada que tem duas direções. Os carros entram em diversas vielas paralelas, isso vai atrasando o fluxo dos demais carros.

Vem a equipe de trânsito da cidade e transforma aquela via em uma via de mão única e transofrma uma via paralela em via de mão única no sentido oposto.

Inicialmente, há grande irritação, pois o caminho para se chegar aonde se deseja já não é tão “direto”, se faz necessário executar um caminho um tanto mais burocrático, mas que por outro lado, garante um ótimo fluxo nas vias.

A mudança no fluxo

Metáforas tem limites, e aqui é apenas para ilustrar esta mudança aqui apresentada na palestra, onde saimos de um fluxo de “vai e vem” (observem as setas em laranja)

Imagem 1 do vídeo sobre Flux, a via de mão dupla

E ocorre a mudança para um fluxo de uma única direção, onde as “Views” disparam actions para mudar os dados, o que na metáfora do trânsito, equivale a dar a volta lá na frente para chegar uma rua atrás.

Imagem 2 vídeo sobre Flux - via de mão única

A minha conclusão geral com esta primeira parte é o velho princípio de separação de camadas, mas combinado com um entendimento de fluxo, de “direção” que o sistema percorre. A separação de camadas já existia na web com as estratégias MVC, mas esta visão de fluxo do sistema em via única, eu ainda não tinha visto.

A Reatividade

Mas esse é apenas um dos temas, porque este modelo, sem a “reatividade” das Views aos dados, seria inviável. Como saber se os dados mudaram?

Em uma arquitetura front end mais primitiva, os próprios “modelos” ou “controllers” ou “handlers” teriam métodos que logo após alterar os dados, chama as instâncias das views e altera os dados da mesma com chamada de métodos. Semelhante a esse slide:

Imagem 3 vídeo sobre Flux - reatividade para eliminar imperatividade

Outro modelo, representado pelo Backbone.js por exemplo, trabalhava com eventos específicos nos dados que podíamos observar para identificar se um modelo ou coleção foi alterada. Assim, as Views observavam determinados modelos para executar alguma operação:

Imagem exemplo do backbone

Esse modelo com eventos sobre modelos de dados e coleções já era bom, mas exigia uma programação imperativa diretamente no DOM para mudar algo. Agora, quando uma mesma visualização dependia de um conjunto mais variado de dados, geralmente a orquestração destas soluções ficava complexa.

Imagem 5 Flux e React - Sobre imperativo vs Reativo

A maneira da reatividade eliminou do desenvolvedor a necessidade de decidir quando alterar a view, basta criar o componente e, declarativamente, e mudar os dados, que o React (Precat, etc) se encarrega de fazer as alterações no DOM. Então, o ideal é sempre "re-renderizar tudo", mas isso é muito poderoso em termos de performance:

imagem 6 React - Ideal é sempre renderizar tudo novamente

É neste pontoq eu a palestrante do vídeo dá lugar a outro (e que eu ainda não assisti).

Até hoje não compreendo bem como que por baixo dos panos, o custo de performance não tornou essa solução inviável. Mas é um assunto que não aprofundei ainda, mas que certamente, está bem encaminhado pela ampla adoção no mercado e por profissionais de altíssimo nível. Não irei aprofundar em como o problema da performance foi abordado. Foi considerá-lo resolvido.

Hooks

Estou entrarndo no estudo de React e Precat já focado na abordagem lançada em 2019 no uso de Hooks, então, vamos lá:

O contato com os criadores de uma ideia é sempre um bom começo, neste vídeo, Sophie, Dan e Ryan mostram o problema que havia com a abordagem anterior, a solução encontrada com Hooks e por fim, um exemplo mais complexo do mundo real:

O próprio Dan Abramov traz uma versão escrita sobre Hooks e seus motivos neste excelente artigo:
https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889

A abordagem de hooks é muito diferente, tem no plano de fundo uma mudança de uma abordagem mais próxima da Orientação a Objetos para uma abordagem mais próxima da Progrmação Funcional. O artigo abaixo dialóga um pouco sobre os pŕos e contras da nova abordagem:
https://medium.com/@nazrhan.mohcine/react-hooks-why-what-and-pros-vs-cons-6d3fe18b8a0a

Minha conclusão: Acostmei-me a pensar front end em termos de "Componente". Mas para as interfaces de hoje em dia, esse conceito não é toda a verdade. Hooks me soam como uma forma de programar "comportamentos" que afetam estado, e consequentemente, como o estado afeta o componente. Há para mim trẽs coisas claras: Estado, Comportamento e Componente. Parece o melhor que já alcançamos até hoje.

Preact

Em alguns projetos, optamos por usar Preact, que implementa a mesma API conceitual do React, mas de forma compacta, mais focada no "core" e que consegue conversar com uma parte do ecossistema React. Uma das grandes vantagens é que é muito mais simples e leve para integrar com projetos já existentes. E já implementa hooks também:

https://preactjs.com/guide/v10/hooks/

Mais em breve...