Escolar Documentos
Profissional Documentos
Cultura Documentos
Você ouve falar frequentemente sobre o React mas sabe pouco sobre ele?
Você já até estudou um pouco sobre a biblioteca desenvolvida pelo Facebook mas quer
consolidar os seus conhecimentos?
O porquê do React
Como começar uma aplicação com React
Pra quê serve o JSX
O que é Virtual DOM
Como funciona o lifecycle dos componentes React
A Era da Componentização
One-way data binding
Flux, Redux ou MobX
O que usar para criar testes unitários com React
Introdução
Para começar precisamos saber o que é o React. Para isso, nada melhor do que utilizar a
definição de quem o criou, o próprio Facebook, que o define assim:
Uma biblioteca JavaScript declarativa, eficiente e flexível para criar interfaces visuais
Essas duas informações juntas criam a primeira grande confusão para quem está
começando: se o React é apenas uma biblioteca e só serve para criar UI, como posso
criar aplicações completas com ele?
E para resolver essa questão precisamos entender que quando a comunidade se refere ao
React, o que na verdade ela está querendo dizer é o React e o seu ecossistema.
E esse ecossistema é formado por:
React
JSX
ES2015
Webpack
Flux/Redux
axios/fetch
Jest/Mocha
E com todos esses itens, que fazem parte do ecossistema do React, conseguimos afirmar
que é possível sim criar aplicações completas usando o React.
JSX
Explicando de forma rápida, o JSX é uma extensão de sintaxe do JavaScript (daí o
nome, JavaScript Syntax eXtension) que nos permite escrever HTML dentro do
JavaScript.
Nos primórdios, o JSX era um dos grandes motivos das críticas e piadas em relação ao
React. Em teoria estávamos voltamos no tempo ao misturar HTML com JavaScript.
Os críticos mais ferrenhos afirmavam que o JSX quebra um dos princípios básicos do
desenvolvimento de software, que é o Separation of Concerns.
Na minha opinião, essa visão é errada por dois motivos:
Independente das minhas opiniões pessoais, com o tempo a comunidade percebeu que o
JSX foi uma decisão acertada e que acabou se tornando um dos grandes alicerces do
sucesso do React.
Componentes
Como foi dito anteriormente, o React tem como função principal auxiliar na criação da
UI. Só deixei um detalhe importante de fora: o React usa componentes, e apenas
componentes, para que que seja possível aumentar o máximo do reuso na sua aplicação.
E se a necessidade for um botão parecido com esse, basta editarmos passando alguns
parâmetros (vamos falar mais sobre eles na próxima seção) e transformá-lo no que
precisamos.
Em resumo, os componentes em React nos deixam mais produtivos. Com eles temos um
reaproveitamento de código maior e uma menor probabilidade de novos bugs
serem introduzidos na aplicação.
Props
Em todos os tipos de paradigmas no desenvolvimento de software, passar parâmetros é
extremamente comum. Com os componentes do React isso não poderia ser diferente. A
diferença é que no React, usamos os props (abreviação para properties).
A ideia é simples.
Imaginando que precisamos mudar a mensagem ‘World’ para alguma outra que for
enviada dinamicamente, podemos reescrever esse componente usando as props dessa
forma:
E com isso feito, podemos chamar esse componente dentro de outros assim:
Além disso, podemos fazer uma validação das props que são passadas no componente
para evitar bugs desnecessários e facilitar no desenvolvimento da aplicação usando os
PropTypes:
HelloWithProps.propTypes = {
name: PropTypes.string.isRequired,
};
view raw prop-types.js hosted with ❤ by GitHub
Agora, informamos explicitamente ao React para apenas aceitar a prop quando ela for
uma string. Se qualquer outra coisa for passada para esse componente, a aplicação irá
falhar e receberemos uma mensagem de erro nos avisando o porquê.
Para ler mais sobre os PropTypes, entre na documentação completa na própria página
do React.
State
O estado (ou state) da sua aplicação, pode ser definido como: o lugar onde os dados
vem e se transformam ao longo do tempo.
O ideal é escrever o máximo possível de componentes dessa categoria. Eles são mais
fáceis de desenvolver, manter e testar.
Já os componentes do tipo Container, além da apresentação dos dados, tem que lidar
também com algum tipo de lógica, ou transformação de dados. Por isso necessitam de
estado (stateful).
Esses componentes não podem ser escritos como uma função, eles obrigatoriamente
devem ser uma classe:
render() {
return (
<h1>Hello {this.state.name}</h1>
);
}
}
view raw container.js hosted with ❤ by GitHub
Os dois exemplos mostrados acima tem exatamente o mesmo resultado final. A única
diferença é que o primeiro deles não usa o state do React, enquanto que o segundo usa.
Podemos ainda complicar um pouco mais o segundo exemplo, para demonstrar como é
possível alterar o estado do seu componente React:
change(event) {
this.setState({ name: event.target.value });
}
render() {
return (
<div>
<input value={this.state.name} onChange={(e) => this.change(e)} />
<p>Hello {this.state.name}!</p>
</div>
);
}
}
view raw container.js hosted with ❤ by GitHub
Em cada mudança que ocorrer no input (linha 16), um evento é disparado na função
change. A função change por sua vez altera o estado do componente, usando a função
setState, que é nativa do React.
Toda vez que o estado for alterado, o React automaticamente invoca de novo a função
render, que irá renderizar a UI com os novos dados inputados pelo usuário.
O *two-way data binding *funciona assim: se uma mudança acontece na view, ela é
refletida automaticamente no model, e vice-versa.
No começo, o two-way data binding parecia uma excelente ideia. Com o tempo, após
inúmeros projetos construídos usando essa tecnologia, ela se mostrou extremamente
nociva principalmente por dois motivos:
1. Performance
2. Manter aplicações grandes se mostrou extremamente difícil
A própria equipe do Angular resolveu limitar essa funcionalidade nas novas versões do*
framework*.
O React porém, percebeu essa falha desde o início e estimula apenas o uso do one-way
data binding.
Não existe um mecanismo no React que permita com que o HTML altere os dados do
componente. E nem vice-versa. Essa mudança é sempre feita de forma explícita pelo
desenvolvedor. Lembrando que explícito é muito melhor, em termos de
desenvolvimento, manutenção e testes, do que implícito.
Um exemplo simples de one-way data binding em ação no React pode ser visto no
componente abaixo:
increment() {
this.setState({ count: this.state.count + 1 });
}
render() {
return (
<div>
<h1>{this.state.count}</h1>
<button onClick={this.increment.bind(this)}>+</button>
</div>
);
}
}
view raw counter.js hosted with ❤ by GitHub
componentDidMount() {
this.timer = setInterval(this.tick, 1000);
}
componentWillUnmount() {
clearInterval(this.timer);
}
tick() {
this.setState({ elapsed: this.state.elapsed + 1 });
}
render() {
return <h1>{this.state.elapsed} seconds</h1>;
}
}
view raw timer.js hosted with ❤ by GitHub
Virtual DOM
A manipulação do DOM está no centro do desenvolvimento front-end moderno.
Fazemos isso basicamente todos os dias.
Só tem dois problemas com isso:
1. Essa manipulação direta do DOM é mais lenta do que a maioria das operações
feitas pelo JavaScript
2. A maioria dos frameworks JavaScript alteram muito mais o DOM do que
deveriam
create-react-app
Nos primeiros anos do React, uma das principais críticas era de que iniciar uma
aplicação era muito mais complicado do que deveria ser, o que acabava excluindo
diversos iniciantes.
Antes de sequer começar a primeira linha de código em React, os desenvolvedores
precisavam aprender no mínimo: Webpack e ES2015.
Hoje isso não é mais um problema, a equipe do Facebook vem trabalhando diariamente
no projeto create-react-app.
Agora, com apenas 4 simples comandos, sem ter que criar e editar nenhuma
configuração, temos um arcabouço completo para começar a desenvolver aplicações em
React:
CSS-in-JS
Todas as boas práticas ao se escrever CSS apontavam para um mesmo caminho por
anos: escrever CSS o mais desacoplado possível do JavaScript e do HTML, usando
nomes bem descritivos para as classes.
O problema dessa abordagem é que ela não resolve o maior defeito do CSS: tudo o
que você cria é global. Cada vez que você cria uma nova classe CSS ela é, por
definição, global. Isso gera diversos problemas na manutenção, principalmente em
aplicações maiores.
.button {
background-color: blue;
border: none;
color: white;
padding: 5px 10px;
}
view raw styles.css hosted with ❤ by GitHub
Nesse, o próprio componente já teria seus estilos escritos em JavaScript, sem que
nenhum arquivo CSS seja sequer criado.
Uma das vantagens do styled-components, é que o code-splitting fica muito mais fácil
de ser feito, e assim como o CSS Modules, não existe CSS global. A desvantagem é que
você não escreve o CSS padrão que muitos já estão acostumados, o que pode não ser
muito intuitivo.
Um exemplo simples:
Bundlers
Resolver dependências no front-end, apesar de ser uma questão comum, sempre foi
extremamente problemático.
Na maioria dos projetos temos que lidar, no mínimo, com essas questões:
Caching
Code Splitting (entrar código sob demanda)
Tree Shaking (eliminação de código não usado)
Hot Module Replacement (após salvar o código novo, ele já aparece no browser
em ambiente de desenvolvimento sem a necessidade de refresh)
State containers
Para aplicações mais complexas usar apenas o setState nativo do React pode não ser o
suficiente para controlar toda a lógica da aplicação.
Existem diversos gerenciadores de estado feitos exclusivamente para lidar com esse
problema, dentre eles: Flux, MobX, Reflux e o mais famoso deles, o Redux.
Dito isso, **toda vez que tivermos que tomar uma decisão de se adicionar uma nova
biblioteca no projeto, temos que pesar o custo/benefício dessa decisão. **E para a
grande maioria das aplicações, que não são complexas o bastante, nenhuma das opções
acima (inclusive o Redux) são necessárias.
Testes
Outro ponto crucial para o desenvolvimento de aplicações web é o uso de testes
unitários. As garantias de que os testes nos dão são consideráveis. Podemos refatorar,
encontrar e evitar novos bugs, e até mesmo para escrever código a partir dos testes
(TDD).
No mundo React, a principal ferramenta para escrever testes unitários é o Jest, que é
mais um open source do Facebook.
Esse último é tão interessante que vale a pena se aprofundar um pouco mais.
A ideia das Snapshots é simples: o Jest tira uma “foto” do seu componente, e se algo
mudar o seu teste vai quebrar e te avisar dessa mudança, mostrando exatamente como o
componente era e como ele ficou.
Conclusão
E pra recapitular, nesse post aprendemos as partes mais centrais do React como: JSX,
Virtual DOM, Lifecycle, Componentização, One-way data binding, etc.
E além disso, conhecemos também os principais atores que fazem parte do ecossistema
do React, dentre eles: Webpack, create-react-app, Jest, CSS Modules, etc.
Mas se mesmo assim ficou alguma dúvida, basta adicionar a pergunta nos comentários
abaixo :)
**Se você gostou do post não se esqueça de dar um ❤ aqui embaixo!E se quiser
receber de antemão mais posts como esse, assine nossa newsletter.**
JSCasts