Uma segunda olhada no React do Facebook

PorAlex Tatiyants em

Quando eu ouvi falar pela primeira vez da biblioteca React do Facebook, fiquei impressionado. Primeiro, porque ela veio do Facebook. Segundo, além das reivindicações de renderização muito rápidas, eu não vi grande coisa. E, finalmente, parecia que os proponentes do React saíram do seu caminho para bater nos atuais líderes, ou seja, o Angular e o Ember.

Bem, eu era (e ainda sou) um grande fã do Angular. Eu fiz o investimento de tempo necessário (e significativo) para aprendê-lo e agora consigo fazer praticamente tudo o que preciso com ele. Portanto, ouvir constantemente sobre como um framework novo em folha do Facebook era muito melhor do que o meu amado Angular não fez nada para que eu gostasse dele.

E assim, como é meu costume, eu assumi que o React fosse um tipo de framework fogo de palha. Tipo: hoje está aqui, amanhã não está mais. E decidi simplesmente ignorá-lo. Esse foi um plano muito bom, exceto por uma falha: React recusou-se a ir embora. Pelo contrário, parecia que um dia alguém estava ouvindo suas preces.

Uma vez que ignorar React não estava me levando a lugar algum, resolvi ceder e dar uma olhada. Olha o que eu encontrei.

tldr; React é uma biblioteca bem surpreendente para o desenvolvimento rápido de interfaces de usuário baseadas em componentes. Dito isso, não é um framework completo e provavelmente vai exigir bibliotecas adicionais para construir grandes aplicativos.

O que é React?

React é uma biblioteca JavaScript projetada em volta de interfaces de usuário baseadas em componentes e fluxo de dados unidirecional. É simples, internamente consistente e teoricamente segura. Ah, e é muito, muito rápida.

UI orientada a componentes

O React tem tudo a ver com componentes. Seus criadores acreditam firmemente em componentes como o caminho certo para fazer a interface de usuário e construíram um framework à sua maneira para forçar o desenvolvedor nessa direção.

Eu não poderia concordar mais com essa abordagem. Os componentes são uma boa maneira de estruturar aplicativos de interface de usuário por duas razões. Primeiro, é muito mais fácil de raciocinar sobre (e criar e depurar) um aplicativo quando você pode restringir o seu modelo mental de um componente específico dentro dele.

Segundo, uma mentalidade centrada em componente te força a procurar e extrair padrões comuns usados em seu aplicativo em partes reutilizáveis. Em vez de pensar “Para implementar um filtro de tabela, vou adicionar algumas tags ao meu template”, você pensa “Para implementar um filtro de tabela, vou adicionar um novo componente ao meu aplicativo e soltar esse componente no meu template”.

A propósito, a menos que a orientação do componente estiver na frente e no centro de seu framework, você não vai pensar dessa forma. Na verdade, a menos que seu framework não só incentive, mas torne mais fácil criar componentes, você não vai. Por exemplo, o Angular definitivamente tem o conceito de componentes sob a forma de diretrizes. Isso é ótimo, exceto que a criação de diretrizes não é uma coisa trivial.

Para criar diretrizes, você precisa ter um profundo entendimento de como o tempo de execução do Angular é gerenciado (compilar vs linkar), como funciona o escopo da herança (isolados vs pai vs filho) e, possivelmente, o que é inclusão. E assim, muitos devs de Angular simplesmente ignoram diretrizes e, em vez disso, usam templates (eu certamente estava nessa categoria até muito pouco tempo atrás).

Imutabilidade

O React também é sobre imutabilidade. O fluxo de dados entre os componentes é unidirecional e imutável por padrão. Existe uma cerimônia especial em torno do estado de mutação.

Mais uma vez, essa é uma ideia maravilhosa! Fazer mutações de estado tão explícitas e intencionais força o desenvolvedor a realmente pensar sobre o fluxo de dados dentro do aplicativo. Estimula a eliminação desnecessária de estado (como a criação de variáveis separadas para acompanhar a contagem de lista) e faz dos erros devido a inconsistências entre as diferentes partes do estado do aplicativo uma coisa menos provável.

Tá, então você pode construir aplicativos com ele?

É importante lembrar que o React (ao contrário do Angular ou do Ember), não é um framework completo. Trata-se da interface de usuário (ou, como o próprio site diz “React é o V no MVC”). Ele fornece tudo que você precisa para criar e renderizar componentes, mas estão faltando algumas coisas:

  • Sistema de módulos
  • Roteamento
  • Modelo de gestão
  • Acesso ao servidor

Existem muitas opções para cada uma dessas coisas disponível na página Ferramentas Complementares do React.

Outra coisa para se levar em consideração é o teste. O Facebook tem seu próprio test runner chamado Jest, o que torna mais fácil para testar os componentes do React. Eu não tentei ainda, mas parece ser semelhante ao Karma do Angular (que por sinal é um excelente test runner).

Integração com Angular

Observando a lista de itens ausentes, não dá para deixar de notar que o Angular tem suporte para tudo isso. Considerando isso, não tem como deixar de se perguntar se Angular e React podem ser combinados.

Acontece que é pelo menos possível combinar React e Angular. Tudo se resume a chamar o método do React renderComponent() a partir do método $watch() da diretriz Angular.

Eu ainda não me convenci se essa é uma boa ideia. Afinal, você ainda precisa passar pelo incômodo de criar diretrizes e agora você também tem que descobrir o que pertence a essa diretriz e o que pertence ao componente do React.

React ou o Angular

Então, os devs do Angular deveriam mudar para o React? Essa é uma pergunta difícil para eu responder, porque, ao mesmo tempo que entendo onde o React supera, eu não sei o quais são os problemas. Eu não sei como é escrever grandes aplicativos em React, como são as questões de depuração estranhas nele.

Eu acho que os devs mais qualificados do Angular podem conviver muito bem com ele. Você consegue muita coisa com Angular, desde que saiba o que está fazendo. A menos que você tenha algum problema louco de desempenho que requer uma reescrita, pode não haver uma razão o suficiente para mudar.

Por outro lado, os novos devs de Angular poderiam muito bem tirar proveito olhando com mais atenção para o React. Ele faz um trabalho melhor do que Angular em forçá-lo a fazer a coisa certa (se é organizar o seu aplicativo em termos de componentes ou forçá-lo a gerenciar melhor o estado).

Considerações finais

React é uma biblioteca excelente para criação de interface de usuário. Resolve alguns problemas muito complexos de uma maneira inteligente e elegante, além de estimular firmemente os bons hábitos.

Também é verdade que o React não oferece tudo o que você precisa para construir aplicativos. Você precisa fazer escolhas sobre um conjunto de tecnologias de suporte para que possa realmente continuar com ele. Alguns podem até gostar realmente dessa abordagem, enquanto outros preferem um framework único e abrangente.

Eu acho que a adoção do React pode ser auxiliada por um framework global construído em torno dele (como Marionette). O Facebook parece estar se movendo nessa direção com Flux, mas nada de concreto se materializou ainda.

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em http://tatiyants.com/a-second-look-at-facebooks-react/

Deixe um comentário! 1

1 comentário

Comentários

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

  1. Excelente artigo, comecei e estudar AngularJS a pouco tempo e realmente os paradigmas estão mudando. Javascript deixou de ser uma linguagem alto nível para simpels validações e interações e tornou-se algo surpreendente. Apenas fico com receio em utilizar algumas tecnologias desenvolvidas por grandes como Google e Facebook que têm uma certa tendência de “abandonar” suas criações de surpresa.

leia mais
Este projeto é mantido e patrocinado pelas empresas: