React: uma pesquisa sobre quando usar…
Saca aquele momento em que você está prestes a começar um projeto e precisa escolher quais tecnologias utilizar?
Pois é, sempre aquela dúvida…
Essa semana decidi começar um projeto com um amigo para colocar em prática várias coisas que venho estudando e também por diversão (mais detalhes sobre o projeto em posts futuros, acho que você vai gostar).
Algumas coisas já estão definidas, como a utilização de uma arquitetura Serverless e tals, mas outras nem tanto…e uma delas é: qual biblioteca utilizar no frontend?
Uma coisa que tenho notado nos últimos tempos é que mais e mais empresas estão migrando as interfaces dos seus sistemas para o React. Criado pelo Facebook, ele vem ganhando cada vez mais espaço, tanto que conheço pessoas que foram contratadas por empresas nacionais e internacionais para trabalhar focadas nessas migrações.
E dai vem a pergunta:
React é mesmo a solução certa para todo mundo?
Para responder essa pergunta, decidi fazer uma pesquisa sobre o assunto.
A primeira fonte que achei foi um post do Zack Argyle, Engenheiro de Software Sênior do Pinterest. Ele toca no ponto sobre a empolgação excessiva que essas novas tecnologias criam, levando todo mundo a achar que elas TEM que ser usadas em todo projeto. O famoso hype.
Mas no final das contas, quais são os pontos que tem atraído tanta gente para o React? Para entender mais sobre isso, encontrei outros artigos que listavam alguns deles:
Componentização
Interfaces escritas em React são baseadas em componentes. Você pode imaginar esses componentes como peças de Lego que você vai juntando para formar a sua interface. E, assim como no Lego, com React você consegue reaproveitar esses componentes (peças) em diferentes partes da aplicação.
A imagem acima representa uma interface baseada nos componentes A, B e C, sendo que o A é reutilizado várias vezes. Isso ajuda muito a reduzir a quantidade de código escrito, principalmente no caso de aplicações grandes.
Mas como funcionam esses componentes? Eles poderiam ser comparados com funções que recebem parâmetros de entrada e retornam um trecho de HTML que vai ser exibido na sua página, de acordo com os parâmetros passados.
Ou seja, no final das contas, a junção desses vários trechos HTML retornados pelos componentes é que vai formar a página que vai ser exibida para os usuários da aplicação… Interessante, né?
Fluxo de Dados Unidirecional
Para entender essa questão do fluxo de dados, imagine o seguinte: vamos supor que você estivesse desenvolvendo um Jogo da Velha online…lembra aquele que a gente brincava quando era criança?
Entre várias outras coisas, você precisaria de duas informações para poder controlar o jogo:
- Quais quadrados já foram marcados?
- Qual jogador marcou cada quadrado? X ou O?
Você poderia escolher algumas formas de recuperar essas informações, como por exemplo, fazer com que o tabuleiro “pergunte” para cada quadrado se ele já foi marcado ou fazer com que cada quadrado “avise” o tabuleiro que ele foi marcado pelo jogador X ou O.
Existem bibliotecas de frontend, como o Angular, que implementam um fluxo de dados bidirecional, ou seja, você poderia tanto perguntar para o quadrado se ele foi marcado como fazer com que ele avise que foi marcado.
Os desenvolvedores do React defendem que esse modelo de fluxo de dados tende a tornar o seu código mais complicado, difícil de debugar e difícil de refatorar, pois um elemento na página pode sofrer influência de vários lugares diferentes. No nosso exemplo, imagine vários quadrados enviando dados para o tabuleiro e o tabuleiro tentando alterar alguma informação nos quadrados ao mesmo tempo…
Para resolver esse problema, o React implementa um fluxo de dados unidirecional. Todos os dados que definem como um elemento da página deve ser apresentado são passados pelo pai desse elemento, fazendo assim com que você tenha certeza de onde os dados vão vir.
No nosso caso, imagine que agora toda a informação sobre os quadrados ficaria armazenada no tabuleiro e ele vai dizer como cada quadrado tem que ser apresentado, se ele já foi marcado, por quem ele foi marcado, etc…
Essa abordagem também facilita o controle de múltiplos elementos da página, como por exemplo, ignorar cliques nos quadrados depois que alguém tiver vencido o jogo. Com essa abordagem, você pode escrever esse controle apenas no tabuleiro e ele vai ser aplicado para todos os quadrados.
DOM Virtual
A sigla DOM vem de Document Object Model. Basicamente, o DOM funciona como uma representação em árvore da estrutura da sua página feita pelo browser. Imagine que você tenha uma página HTML com vários elementos, cada elemento se tornará um nó da árvore, possibilitando que você navegue, acesse, altere e remova elementos da página utilizando JavaScript e a API do DOM.
Então toda vez que você quiser alterar um elemento na sua página, você precisa alterar o DOM do browser. Agora imagine nas páginas que nós temos hoje em dia, com dezenas de elementos sendo atualizados o tempo todo, como anúncios, imagens, vídeos, etc.
Essas infinitas atualizações causam vários problemas, principalmente em relação à performance da sua página, sem contar a complexidade de coordenar tudo isso para que as coisas aconteçam como você espera.
Certo, mas o que seria então o DOM Virtual?
O DOM Virtual é uma abstração do DOM do browser. Você pode imaginar ele como uma cópia, mas que possui algumas vantanges:
- Não depende de implementações específicas dos browsers;
- É mais leve;
- É mais eficiente na comparação de alterações de elementos da página.
Esse último ponto é um dos grandes benefícios que o React traz para a sua aplicação em relação à performance.
Imagine o seguinte, uma página com centenas de elementos sendo atualizados constantemente, com o DOM Virtual, o que o React faz é comparar eficientemente se o que está sendo apresentado na página é o esperado para cada elemento, caso não seja, ele processa todas as alterações necessárias e atualiza apenas o que for necessário no DOM do browser.
No exemplo acima, imagine que uma alteração foi feita no nó com a cor vermelha. Utilizando o DOM Virtual, o React calcula quais são os impactos dessa mudança e detecta que o filho desse nó também deve ser alterado (nó amarelo). Só depois de definir no DOM Virtual como esses dois nós devem ser apresentados, ele vai e atualiza o DOM do browser, fazendo com os elementos sejam alterados para o usuário.
Por conta da eficiência do DOM Virtual em fazer esses cálculos de alterações, a performance de aplicações com React pode melhorar consideravelmente quando comparada a aplicações que alteram o DOM do browser diretamente.
Legal, agora que a gente já tem uma visão de algumas das vantagens do React, para quais tipos de aplicação essas características são realmente relevantes?
Segundo Zack Argyle, essas características são interessantes para aplicações muito dinâmicas, que passam por atualizações constantes de elementos na página e onde o reaproveitamento de componentes pode trazer ganhos expressivos. Um exemplo desse tipo de aplicação é o próprio Facebook, onde existem diversos componentes na página sendo atualizados a todo momento.
Certo, a gente entendeu um pouco mais sobre as vantagens e características do React. Mas isso quer dizer então que ele realmente serve para tudo? Ou seja…
Existem casos em que NÃO seria recomendado usar React?
Pelas minhas pesquisas, a questão que ajuda a responder essa pergunta é: vale a pena o esforço?
Apesar de (ou talvez justamente por) ser uma biblioteca muito poderosa, utilizar o React no seu projeto pode trazer uma complexidade maior do que o que você de fato precisa. Toda essa questão de reatividade e componentização faz com que você tenha que entender bem como a biblioteca funciona e respeitar as suas regras para conseguir atingir coisas que poderiam ser bem mais fáceis de serem feitas com outras opções que existem no mercado.
Zack Argyle cita exemplos de quando você não precisaria utilizar React:
- Quando sua aplicação é pouco dinâmica: se a sua aplicação não exige constantes atualizações de elementos na página, você não estará tirando vantagem de um dos pontos fortes da biblioteca, o DOM Virtual. Logo, pode não valer a pena utilizar React;
- Quando sua aplicação precisa apenas de templates básicos: se um sistema de templates simples já atenderia o seu projeto, talvez algo como Handlebars já seja mais do que o suficiente.
- Quando seu site é estático: se você não tem componentes dinâmicos no seu site, você pode usar algo como o Jade que é bem bacana e funciona legal para sites estáticos.
Enfim, depois de tudo isso, a minha conclusão é que utilizar ou não React depende basicamente do tipo de projeto que você está construindo.
Aparentemente, ele pode sim ser utilizado na maioria dos casos, mas vale sempre uma análise de custo-benefício: os pontos fortes da biblioteca vão trazer benefícios para o seu projeto ou você vai utilizar ela apenas porque sim?
Pensando no meu projeto, eu vejo que utilizar o React pode sim trazer ganhos interessantes, principalmente por conta da dinamicidade dos elementos nas páginas.
Mas e você, concorda com esses pontos que encontrei? Quais são suas principais dúvidas sobre React? Deixe nos comentários.
Um grande abraço!
Fontes:
