Testes são frequentemente vistos como um processo tedioso. É código extra que você tem que escrever e, em alguns casos, para ser honesto, não é necessário. Todo desenvolvedor, no entanto, deve saber pelo menos o básico de testes. Isso aumenta a confiança nos produtos que eles constroem e, na maioria das empresas, é um requisito.

No mundo do React, há uma incrível biblioteca chamada react-testing-library, que auxilia no teste mais eficiente de suas aplicações em React. Você a utiliza com o Jest.

Neste artigo, veremos 8 etapas simples para começar a testar suas aplicações em React como um especialista.

• Pré-requisitos
• Básico
• O que é a React Testing Library?
• 1. Como criar um snapshot do teste?
• 2. Testando elementos do DOM
• 3. Testando eventos
• 4. Testando ações assíncronas
• 5. Testando o React Redux
• 6. Testando o React Context
• 7. Testando o React Router
• 8. Testando requisições HTTP
• Conclusão
• Próximos passos

Pré-requisitos

Neste tutorial, pressupõe-se que você tenha, pelo menos, um entendimento básico do React. Vou focar apenas na parte de testes.

Para acompanhá-lo, você precisa clonar o projeto, executando no seu terminal:

  git clone https://github.com/ibrahima92/prep-react-testing-library-guide

Depois, execute:

  yarn

Ou, se estiver usando o npm:

npm install

É isso! Agora, vamos mergulhar em alguns princípios básicos.

Básico

Alguns pontos-chave serão amplamente utilizados neste artigo. Compreender o papel deles pode auxiliar na compreensão

it ou test: descreve o próprio teste. Recebe como parâmetros o nome do teste e uma função que contém os testes.

expect: a condição que o teste precisa satisfazer. Ela vai comparar o parâmetro recebido com um 'matcher'.

matcher: a função aplicada à condição esperada.

render: o método usado para renderizar um determinado componente

import React from 'react'
import {render} from '@testing-library/react'
import App from './App'
 
 it('should take a snapshot', () => {
    const { asFragment } = render(<App />)
    
    expect(asFragment(<App />)).toMatchSnapshot()
   })
});

Como você pode ver, descrevemos o teste com isso. Em seguida, usamos o render para exibir o componente e esperamos que asFragment(<App />) corresponda a toMatchSnapshot() (o verificador fornecido pelo jest-dom).

A propósito, o método render retorna vários métodos que podemos usar para testar nossos recursos. Também usamos a desestruturação para obter o método.

Dito isso, vamos avançar e aprender mais sobre a React Testing Library na próxima seção.

O que é a React Testing Library?

A React Testing Library é um pacote muito leve e excelente criado por Kent C. Dodds. É uma substituição para o Enzyme e fornece funções utilitárias leves em cima do `react-dom`  e `react-dom/test-utils`.

O React Testing Library é uma biblioteca de teste de DOM, o que significa que, em vez de lidar com instâncias de componentes do React renderizados, ele lida com elementos do DOM e com o modo como eles se comportam diante de usuários reais.

É uma ótima biblioteca, relativamente fácil de começar a usar, e promove boas práticas de teste. Observação: você também pode utilizá-la sem o Jest.

"Quanto mais seus testes se assemelharem à maneira como seu software é utilizado, maior confiança eles podem lhe proporcionar".

Agora, vamos começar a utilizá-los na próxima seção. Aliás, você não precisa instalar nenhum pacote, já que o create-react-app vem com a biblioteca e suas dependências.

1. Como criar um snapshot de teste

Um snapshot (em português, algo como uma fotografia ou instantâneo), como o nome sugere, nos permite salvar uma imagem do estado atual de um componente específico. Isso é especialmente útil quando você faz atualizações ou realiza alguma refatoração e deseja obter ou comparar as mudanças.

Agora, vamos tirar um snapshot do arquivo App.js .

• App.test.js

import React from 'react'
import {render, cleanup} from '@testing-library/react'
import App from './App'

 afterEach(cleanup)
 
 it('should take a snapshot', () => {
    const { asFragment } = render(<App />)
    
    expect(asFragment(<App />)).toMatchSnapshot()
   })
});

Para tirar um snapshot, primeiro precisamos importar os métodos render e cleanup. Esses dois métodos serão amplamente utilizados ao longo deste artigo

render, como você pode imaginar, é usado para renderizar um componente do React. A função cleanup é passada como um parâmetro para o afterEach para limpar tudo após cada teste, a fim de evitar vazamentos de memória.

Agora, podemos renderizar o componente App com o método render e obter asFragment como o valor retornado. Por fim, nos certificamos de que o fragmento do componente corresponda ao snapshot.

Agora, para executar o teste, abra o termina, navegue até a raiz do projeto e execute o seguinte comando:

  yarn test

Ou, se estiver usando npm:

  npm test

Como resultado, ele criará uma outra pasta __snapshots__ e um arquivo App.test.js.snap na pasta src, que se parecerá com isto:

• App.test.js.snap

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`Take a snapshot should take a snapshot 1`] = `
<DocumentFragment>
  <div class="App">
    <h1>Testing</h1>
  </div>
</DocumentFragment>
`;

Se você fizer outra alteração em App.js, o teste falhará, pois o snapshot não corresponderá mais à condição. Para fazê-lo passar, basta pressionar 'u' para atualizá-lo. Você terá o snapshot atualizado no arquivo App.test.js.snap.

Agora, vamos prosseguir e começar a testar nossos elementos.

2. Testando elementos do DOM

Para testar nossos elementos do DOM, primeiro devemos examinar o arquivo TestElements.js

• TestElements.js

import React from 'react'

const TestElements = () => {
 const [counter, setCounter] = React.useState(0)
  
 return (
  <>
    <h1 data-testid="counter">{ counter }</h1>
    <button data-testid="button-up" onClick={() => setCounter(counter + 1)}> Up</button>
    <button disabled data-testid="button-down" onClick={() => setCounter(counter - 1)}>Down</button>
 </>
    )
  }
  
export default TestElements

Aqui, a única coisa que você precisa manter é o data-testid. Ele será usado para selecionar esses elementos no arquivo de teste. Agora, vamos escrever nosso teste unitário.

Teste se o contador está igual a 0:

TestElements.test.js

import React from 'react';
import { render, cleanup } from '@testing-library/react';
import TestElements from './TestElements'

afterEach(cleanup);

  it('should equal to 0', () => {
    const { getByTestId } = render(<TestElements />); 
    expect(getByTestId('counter')).toHaveTextContent(0)
   });

Como você pode notar, a sintaxe é bastante similar ao teste anterior. A única diferença é que usamos getByTestId para selecionar os elementos necessários (lembre-se de data-testid) e checamos se isso passava no teste. Em outras palavras, verificamos se o conteúdo do texto <h1 data-testid="counter">{ counter }</h1> é igual a zero.

Teste se os botões estão habilitados ou desabilitados:

TestElements.test.js (adicione o seguinte bloco de código no arquivo)

   it('should be enabled', () => {
    const { getByTestId } = render(<TestElements />);
    expect(getByTestId('button-up')).not.toHaveAttribute('disabled')
  });

  it('should be disabled', () => {
    const { getByTestId } = render(<TestElements />); 
    expect(getByTestId('button-down')).toBeDisabled()
  });

Aqui, como de costume, usamos getByTestId para selecionar os elementos e verificar no primeiro teste se o botão possui o atributo 'disabled'. No segundo teste, verificamos se o botão está desabilitado ou não.

Se você salvar o arquivo ou rodar novamente no seu terminal o comando 'yarn test', os testes passarão.

Parabéns! Seu primeiro teste passou!

Agora, vamos aprender como testar um evento na próxima seção.

3. Testando eventos

Antes de escrever nossos testes unitários, vamos primeiro verificar como é o arquivo TestEvents.js

• TestEvents.js

import React from 'react'

const TestEvents = () => {
  const [counter, setCounter] = React.useState(0)
  
return (
  <>
    <h1 data-testid="counter">{ counter }</h1>
    <button data-testid="button-up" onClick={() => setCounter(counter + 1)}> Up</button>
    <button data-testid="button-down" onClick={() => setCounter(counter - 1)}>Down</button>
 </>
    )
  }
  
  export default TestEvents

Agora, vamos escrever os testes.

Teste se o contador incrementa e decrementa corretamente quando clicamos nos botões

TestEvents.test.js

import React from 'react';
import { render, cleanup, fireEvent } from '@testing-library/react';
import TestEvents from './TestEvents'

  afterEach(cleanup);
  
  it('increments counter', () => {
    const { getByTestId } = render(<TestEvents />); 
    
    fireEvent.click(getByTestId('button-up'))

    expect(getByTestId('counter')).toHaveTextContent('1')
  });

  it('decrements counter', () => {
    const { getByTestId } = render(<TestEvents />); 
    
    fireEvent.click(getByTestId('button-down'))

    expect(getByTestId('counter')).toHaveTextContent('-1')
  });

Como você pode ver, esses dois testes são muito semelhantes, exceto pelo conteúdo de texto esperado. O primeiro teste dispara um evento de clique com fireEvent.click() para verificar se o contador incrementa para 1 quando o botão é clicado.

O segundo teste verifica se o contador decrementa para -1 quando o botão é clicado.

fireEvent tem vários métodos que você pode usar para testar eventos. Fique à vontade para mergulhar na documentação e aprender mais.

Agora que sabemos como testar eventos, vamos avançar e aprender na próxima seção como lidar com ações assíncronas.

4. Testando ações assíncronas

Uma ação assíncrona é algo que pode levar tempo para ser concluído. Pode ser uma solicitação HTTP, um temporizador e assim por diante.

Agora, vamos verificar o arquivo TestAsync.js.

• TestAsync.js

import React from 'react'

const TestAsync = () => {
  const [counter, setCounter] = React.useState(0)

  const delayCount = () => (
    setTimeout(() => {
      setCounter(counter + 1)
    }, 500)
  )
  
return (
  <>
    <h1 data-testid="counter">{ counter }</h1>
    <button data-testid="button-up" onClick={delayCount}> Up</button>
    <button data-testid="button-down" onClick={() => setCounter(counter - 1)}>Down</button>
 </>
    )
  }
  
  export default TestAsync

Aqui, usamos setTimeout() para atrasar o evento de incremento em 0,5 segundo.

Teste se o contador é incrementado após 0,5 segundo: TestAsync.test.js

import React from 'react';
import { render, cleanup, fireEvent, waitForElement } from '@testing-library/react';
import TestAsync from './TestAsync'

afterEach(cleanup);
  
  it('increments counter after 0.5s', async () => {
    const { getByTestId, getByText } = render(<TestAsync />); 

    fireEvent.click(getByTestId('button-up'))

    const counter = await waitForElement(() => getByText('1')) 

    expect(counter).toHaveTextContent('1')
  });

Para testar o evento de incremento, primeiro precisamos usar async/await para lidar com a ação, porque, como mencionei anteriormente, ela leva tempo para ser concluída.

Em seguida, usamos um novo método auxiliar getByText(). Ele é semelhante ao getByTestId(), exceto pelo fato de que getByText() seleciona o conteúdo do texto em vez do id ou data-testid.

Agora, após clicar no botão, esperamos que o contador seja incrementado com waitForElement(() => getByText('1')). Uma vez que o contador foi incrementado para 1, podemos passar para a condição e verificar se o contador é efetivamente igual a 1. Dito isso, vamos agora passar para casos de teste mais complexos.

Você está pronto?

5. Testando o React Redux

Se você é novo no React Redux, este artigo (texto em inglês) pode ajudar você. Caso contrário, vamos verificar como o TestRedux.js se parece.

• TestRedux.js

import React from 'react'
import { connect } from 'react-redux'

const TestRedux = ({counter, dispatch}) => {

 const increment = () => dispatch({ type: 'INCREMENT' })
 const decrement = () => dispatch({ type: 'DECREMENT' })
  
 return (
  <>
    <h1 data-testid="counter">{ counter }</h1>
    <button data-testid="button-up" onClick={increment}>Up</button>
    <button data-testid="button-down" onClick={decrement}>Down</button>
 </>
    )
  }
  
export default connect(state => ({ counter: state.count }))(TestRedux)

Agora, para o Redux:

• store/reducer.js

export const initialState = {
    count: 0,
  }
  
  export function reducer(state = initialState, action) {
    switch (action.type) {
      case 'INCREMENT':
        return {
          count: state.count + 1,
        }
      case 'DECREMENT':
        return {
          count: state.count - 1,
        }
      default:
        return state
    }
  }

Como você pode ver, não há nada extravagante – é apenas um componente Counter básico manipulado pelo React Redux.

Agora, vamos escrever os testes unitários.

Teste se o estado inicial é igual a 0:

TestRedux.test.js

import React from 'react'
import { createStore } from 'redux'
import { Provider } from 'react-redux'
import { render, cleanup, fireEvent } from '@testing-library/react';
import { initialState, reducer } from '../store/reducer'
import TestRedux from './TestRedux'

const renderWithRedux = (
  component,
  { initialState, store = createStore(reducer, initialState) } = {}
) => {
  return {
    ...render(<Provider store={store}>{component}</Provider>),
    store,
  }
}

 afterEach(cleanup);

it('checks initial state is equal to 0', () => {
    const { getByTestId } = renderWithRedux(<TestRedux />)
    expect(getByTestId('counter')).toHaveTextContent('0')
  })

Existem algumas coisas que precisamos importar para testar o React Redux. Aqui, criamos nossa própria função auxiliar renderWithRedux() para renderizar o componente, já que ele será usado várias vezes.

renderWithRedux() recebe como parâmetros o componente a ser renderizado, o estado inicial e a loja.

Se não houver loja, ele criará uma. Se não receber um estado inicial ou uma loja, ele retornará um objeto vazio.

Em seguida, usamos render() para renderizar o componente e passamos a loja para o Provider. Dito isso, agora, podemos passar o componente TestRedux para renderWithRedux() para testar se o contador é igual a 0.

Teste se o contador incrementa e decrementa corretamente: TestRedux.test.js (adicione o seguinte bloco de código ao arquivo)

it('increments the counter through redux', () => {
  const { getByTestId } = renderWithRedux(<TestRedux />, 
    {initialState: {count: 5}
})
  fireEvent.click(getByTestId('button-up'))
  expect(getByTestId('counter')).toHaveTextContent('6')
})

it('decrements the counter through redux', () => {
  const { getByTestId} = renderWithRedux(<TestRedux />, {
    initialState: { count: 100 },
  })
  fireEvent.click(getByTestId('button-down'))
  expect(getByTestId('counter')).toHaveTextContent('99')
})

Para testar os eventos de incremento e decremento, passamos um estado inicial como segundo argumento para renderWithRedux().

Agora, podemos clicar nos botões e testar se o resultado esperado corresponde à condição ou não.

Vamos passar para a próxima seção e introduzir o React Context. React Router e Axios virão em seguida – você ainda está comigo?

6. Testando o React Context

Se você é novo no React Context, confira este artigo primeiro (texto em inglês). Caso contrário, vamos verificar o arquivo TextContext.js.

• TextContext.js

import React from "react"

export const CounterContext = React.createContext()

const CounterProvider = () => {
  const [counter, setCounter] = React.useState(0)
  const increment = () => setCounter(counter + 1)
  const decrement = () => setCounter(counter - 1)

  return (
    <CounterContext.Provider value={{ counter, increment, decrement }}>
      <Counter />
    </CounterContext.Provider>
  )
}

export const Counter = () => {  
    const { counter, increment, decrement } = React.useContext(CounterContext)   
    return (
     <>
       <h1 data-testid="counter">{ counter }</h1>
       <button data-testid="button-up" onClick={increment}> Up</button>
       <button data-testid="button-down" onClick={decrement}>Down</button>
    </>
       )
}

export default CounterProvider

Agora, o estado do contador é gerenciado por meio do React Context. Vamos escrever o teste unitário para verificar se ele se comporta conforme esperado.

Teste se o estado inicial é igual a 0:

TextContext.test.js

import React from 'react'
import { render, cleanup,  fireEvent } from '@testing-library/react'
import CounterProvider, { CounterContext, Counter } from './TestContext'

const renderWithContext = (
  component) => {
  return {
    ...render(
        <CounterProvider value={CounterContext}>
            {component}
        </CounterProvider>)
  }
}

afterEach(cleanup);

it('checks if initial state is equal to 0', () => {
    const { getByTestId } = renderWithContext(<Counter />)
    expect(getByTestId('counter')).toHaveTextContent('0')
})

Assim como na seção anterior com o React Redux, aqui usamos a mesma abordagem, criando uma função auxiliar renderWithContext() para renderizar o componente.

Dessa vez, porém, ela recebe apenas o componente como parâmetro. Para criar um outro contexto, passamos CounterContext para o Provider. Agora, podemos testar se o contador é inicialmente igual a 0 ou não.

Teste se o contador incrementa e decrementa corretamente: TextContext.test.js (adicione o seguinte bloco de código ao arquivo)

  it('increments the counter', () => {
    const { getByTestId } = renderWithContext(<Counter />)

    fireEvent.click(getByTestId('button-up'))
    expect(getByTestId('counter')).toHaveTextContent('1')
  })

  it('decrements the counter', () => {
    const { getByTestId} = renderWithContext(<Counter />)

    fireEvent.click(getByTestId('button-down'))
    expect(getByTestId('counter')).toHaveTextContent('-1')
  })

Como você pode ver, aqui disparamos um evento de clique para testar se o contador incrementa corretamente para 1 e decrementa para -1.

Dito isso, podemos passar para a próxima seção e introduzir o React Router.

7. Testando o React Router

Se você quiser se aprofundar no React Router, este artigo pode ajudar você (texto em inglês). Caso contrário, vamos verificar o arquivo TestRouter.js.

• TestRouter.js

import React from 'react'
import { Link, Route, Switch,  useParams } from 'react-router-dom'

const About = () => <h1>About page</h1>

const Home = () => <h1>Home page</h1>

const Contact = () => {
  const { name } = useParams()
  return <h1 data-testid="contact-name">{name}</h1>
}

const TestRouter = () => {
    const name = 'John Doe'
    return (
    <>
    <nav data-testid="navbar">
      <Link data-testid="home-link" to="/">Home</Link>
      <Link data-testid="about-link" to="/about">About</Link>
      <Link data-testid="contact-link" to={`/contact/${name}`}>Contact</Link>
    </nav>
    
      <Switch>
        <Route exact path="/" component={Home} />
        <Route path="/about" component={About} />
        <Route path="/about:name" component={Contact} />
      </Switch>
    </>
  )
}

export default TestRouter

Aqui, temos alguns componentes para renderizar ao navegar pela página inicial.

Agora, vamos escrever os testes:

• TestRouter.test.js

import React from 'react'
import { Router } from 'react-router-dom'
import { render, fireEvent } from '@testing-library/react'
import { createMemoryHistory } from 'history'
import TestRouter from './TestRouter'


const renderWithRouter = (component) => {
    const history = createMemoryHistory()
    return { 
    ...render (
    <Router history={history}>
        {component}
    </Router>
    )
  }
}

it('should render the home page', () => {

  const { container, getByTestId } = renderWithRouter(<TestRouter />) 
  const navbar = getByTestId('navbar')
  const link = getByTestId('home-link')

  expect(container.innerHTML).toMatch('Home page')
  expect(navbar).toContainElement(link)
})

Para testar o React Router, primeiro, precisamos ter um histórico de navegação para começar.

Portanto, usamos createMemoryHistory() para, como o nome sugere, criar um histórico de navegação. Em seguida, usamos nossa função auxiliar renderWithRouter() para renderizar o componente e passamos o histórico para o componente Router. Com isso, podemos agora testar se a página carregada no início é a página inicial ou não e se a barra de navegação é carregada com os links esperados.

Teste se ele navega para outras páginas com os parâmetros quando clicamos nos links: TestRouter.test.js (adicione o seguinte bloco de código ao arquivo)

it('should navigate to the about page', ()=> {
  const { container, getByTestId } = renderWithRouter(<TestRouter />) 

  fireEvent.click(getByTestId('about-link'))

  expect(container.innerHTML).toMatch('About page')
})

it('should navigate to the contact page with the params', ()=> {
  const { container, getByTestId } = renderWithRouter(<TestRouter />) 
   
  fireEvent.click(getByTestId('contact-link'))
   
  expect(container.innerHTML).toMatch('John Doe')
})

Agora, para verificar se a navegação funciona, precisamos disparar um evento de clique nos links de navegação. Para o primeiro teste, verificamos se o conteúdo é igual ao texto na página Sobre (em inglês, about) e, para o segundo, testamos os parâmetros de roteamento e verificamos se foram passados corretamente.

Podemos passar para a seção final e aprender como testar uma solicitação com o Axios.

Estamos quase lá!

8. Testando requisições HTTP

Como de costume, vamos primeiro ver como é o arquivo TextAxios.js.

• TextAxios.js

import React from 'react'
import axios from 'axios'

const TestAxios = ({ url }) => {
  const [data, setData] = React.useState()

  const fetchData = async () => {
    const response = await axios.get(url)
    setData(response.data.greeting)    
 }     
 
 return (
  <>
    <button onClick={fetchData} data-testid="fetch-data">Load Data</button>
    { 
    data ?
    <div data-testid="show-data">{data}</div>:
    <h1 data-testid="loading">Loading...</h1>
    }
  </>
     )
}

export default TestAxios

Como você pode ver aqui, temos um componente simples que tem um botão para fazer uma solicitação.

Se os dados não estiverem disponíveis, ele exibirá uma mensagem de carregamento.

Agora, vamos escrever os testes. Teste se os dados são buscados e exibidos corretamente:

TextAxios.test.js

import React from 'react'
import { render, waitForElement, fireEvent } from '@testing-library/react'
import axiosMock from 'axios'
import TestAxios from './TestAxios'

jest.mock('axios')

it('should display a loading text', () => {

 const { getByTestId } = render(<TestAxios />)

  expect(getByTestId('loading')).toHaveTextContent('Loading...')
})

it('should load and display the data', async () => {
  const url = '/greeting'
  const { getByTestId } = render(<TestAxios url={url} />)

  axiosMock.get.mockResolvedValueOnce({
    data: { greeting: 'hello there' },
  })

  fireEvent.click(getByTestId('fetch-data'))

  const greetingData = await waitForElement(() => getByTestId('show-data'))

  expect(axiosMock.get).toHaveBeenCalledTimes(1)
  expect(axiosMock.get).toHaveBeenCalledWith(url)
  expect(greetingData).toHaveTextContent('hello there')
})

Esse caso de teste é um pouco diferente, pois lidamos com uma requisição HTTP e, para fazer isso, temos que simular uma solicitação do Axios com a ajuda de jest.mock('axios').

Agora, podemos usar axiosMock e aplicar um método get() a ele. Finalmente, usaremos a função mockResolvedValueOnce() do Jest para passar os dados simulados como parâmetro.

Com isso, para o segundo teste, podemos clicar no botão para buscar os dados e usar async/await para resolvê-los.

Temos que testar 3 coisas:

1. Se a requisição HTTP foi feita corretamente;
2. Se a requisição HTTP foi feita com o URL correto;
3. Se os dados buscados correspondem à expectativa.

Para o primeiro teste, apenas verificamos se a mensagem de carregamento é exibida quando não temos dados para mostrar. Dito isso, terminamos com os 8 passos simples para começar a testar suas aplicações em React.

Não tenha mais medo de testar.

Conclusão

A React Testing Library é um ótimo pacote para testar aplicações em React. Ela nos dá acesso aos matchers do jest-dom que podemos usar para testar nossos componentes de maneira mais eficiente e com boas práticas.

Espero que este artigo tenha sido útil e que ajude você a criar aplicações em React robustas no futuro.

Você pode encontrar o projeto finalizado aqui.

Obrigado pela leitura!

Leia mais artigos do autor – Inscreva-se na newsletter do autor – Siga o autor no Twitter

Você pode ler outros artigos como este no blog do autor.

Próximos passos (documentações em inglês)

Documentação da React Testing Library

Ficha informativa da React Testing Library

Ficha informativa dos matchers do Jest DOM

Documentação do Jest

O Kubernetes  é uma ferramenta muito útil para desenvolvedores nativos da nuvem. No entanto, por si só, ele não abrange todos os aspectos – existem algumas coisas que o Kubernetes não consegue resolver ou que estão fora de seu escopo.

Essa é uma das razões pelas quais os projetos de código aberto são tão bons. Eles ajudam ferramentas incríveis a se tornarem ainda mais incríveis quando as combinamos com outras ferramentas incríveis de código aberto. Muitas vezes, essas ferramentas foram desenvolvidas com o único propósito de preencher lacunas. Uma dessas ferramentas é o Helm.

O que é o Helm?

O Helm é amplamente conhecido como o "gerenciador de pacotes do Kubernetes". Embora se apresente assim, seu funcionamento vai muito além de um simples gerenciador de pacotes. No entanto, vamos começar do início.

Helm é um projeto de código aberto que foi originalmente criado pela DeisLabs e doado à CNCF (texto em inglês), que agora o mantém. O objetivo original do Helm era proporcionar aos usuários uma maneira melhor de gerenciar todos os arquivos YAML do Kubernetes que criamos em projetos no Kubernetes.

O caminho que o Helm seguiu para resolver esse problema foi criar Helm Charts. Cada chart (em português, algo como "gráfico") é um pacote com um ou mais arquivos de configuração do Kubernetes – um chart pode ter charts filhos e charts dependentes também.

Isso significa que o Helm instala toda a árvore de dependências de um projeto se você executar o comando de instalação para o chart de nível superior. Você precisa apenas de um único comando para instalar toda a sua aplicação, em vez de listar os arquivos para instalação via kubectl.

Os charts também permitem que você controle a versão dos arquivos de configuração, assim como fazemos com o Node.js ou qualquer outro pacote. Isso permite que você instale versões específicas do chart, o que significa manter configurações específicas para sua infraestrutura na forma de código.

O Helm também mantém todo o histórico de lançamento de todos os charts, para que você possa voltar para uma versão anterior se algo der errado.

O Helm oferece suporte nativo ao Kubernetes. Isso significa que você não precisa escrever nenhum arquivo de sintaxe complexa ou algo do tipo para começar a usar o Helm. Basta colocar seus arquivos de modelo em um novo chart e você está pronto para começar.

Porém, você pode se perguntar o porquê devemos usá-lo. Gerenciar manifestos de aplicações pode ser facilmente feito com algumas combinações de comandos.

Por que você deve usar o Helm?

O Helm realmente se destaca onde o Kubernetes não consegue. Por exemplo, na criação de templates.
O escopo do projeto Kubernetes é lidar com seus contêineres para você, não com seus arquivos de template (em português, modelos).

Isso torna muito difícil a criação de arquivos verdadeiramente genéricos para serem usados por meio de uma grande equipe ou organização, com diferentes parâmetros que precisam ser definidos para cada arquivo.

Além disso, como você versiona informações sensíveis usando o Git quando os arquivos de modelo são texto simples?

A resposta: com os templates. O Helm permite que você adicione variáveis e use funções dentro de seus arquivos de modelo. Isso o torna perfeito para aplicações escaláveis que, em algum momento, precisarão ter seus parâmetros alterados. Vamos ver um exemplo:

Eu tenho um projeto de código aberto chamado Zaqar, um microsserviço de e-mail simples para Node.js, que se comunica com o SendGrid. O projeto é basicamente composto por um serviço, um deployment e um escalonamento automático.

Vamos pegar o arquivo de deployment como exemplo. Eu teria algo assim:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: zaqar
  namespace: default
  labels:
    app: zaqar
    version: v1.0.0
    env: production
spec:
  replicas: 1
  selector:
    matchLabels:
      app: zaqar
      env: production
  template:
    metadata:
      labels:
        app: zaqar
        version: v1.0.0
        env: production
    spec:
      containers:
        - name: zaqar
          image: "khaosdoctor/zaqar:v1.0.0"
          imagePullPolicy: IfNotPresent
          env:
            - name: SENDGRID_APIKEY
              value: "MY_SECRET_KEY"
            - name: DEFAULT_FROM_ADDRESS
              value: "my@email.com"
            - name: DEFAULT_FROM_NAME
              value: "Lucas Santos"
          ports:
            - name: http
              containerPort: 3000
              protocol: TCP
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi

Se eu quiser usar esse modelo em um pipeline de integração contínua (CI) ou publicá-lo no meu GitHub, precisarei substituir as partes variáveis por marcadores de posição. Assim, podemos substituir esses textos pelas informações necessárias.

Nesse caso, tanto a tag da versão, a etiqueta de ambiente e as variáveis de ambiente seriam substituídas por marcadores de posição, como mostrado abaixo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: zaqar
  namespace: default
  labels:
    app: zaqar
    version: #!VERSION!#
    env: #!ENV!#
spec:
  replicas: 1
  selector:
    matchLabels:
      app: zaqar
      env: #!ENV!#
  template:
    metadata:
      labels:
        app: zaqar
        version: #!VERSION!#
        env: #!ENV!#
    spec:
      containers:
        - name: zaqar
          image: "khaosdoctor/zaqar:#!VERSION!#"
          imagePullPolicy: IfNotPresent
          env:
            - name: SENDGRID_APIKEY
              value: "#!SENDGRID_KEY!#"
            - name: DEFAULT_FROM_ADDRESS
              value: "#!FROM_ADDR!#"
            - name: DEFAULT_FROM_NAME
              value: "#!FROM_NAME!#"
          ports:
            - name: http
              containerPort: 3000
              protocol: TCP
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi

Agora podemos executar nosso pipeline de CI. Antes de fazer isso, contudo, precisamos substituir nossos marcadores de posição pelos valores reais.

Para isso, podemos usar o sed e sua sintaxe "super fácil"  sed  s/#!PLACEHOLDER!#/substituicao/g e aplicá-la até que tenhamos substituído todos os marcadores de posição. O comando final seria algo assim:

cat deploy.yaml | \
    sed 's/#!ENV!#/production/g' | \
    sed 's/#!VERSION!#/v1.0.0/g' | \
    sed 's/#!SENDGRID_KEY!#/MyKey/g' | \
    sed 's/#!FROM_ADDR!#/my@email.com/g' | \
    sed 's/#!FROM_NAME!#/Lucas Santos/g'

Por padrão, o sed imprime tudo no stdout. Então, podemos adicionar outro I para o kubectl -f, como <todo o comando anterior> | kubectl -f -. Desse modo, teremos nossa implantação no lugar. O único problema é que precisamos fazer o mesmo para todos os outros arquivos.

Agora, imagine um projeto maior, com muitas outras variáveis e marcadores de posição. Você provavelmente escreveria um script para fazer isso por você, não é mesmo? Esse script é o Helm.

Quando você cria um Chart (mais sobre isso posteriormente), temos uma árvore de diretórios específica que devemos seguir para que o Helm entenda o que queremos fazer. Dentro do diretório de modelos templates, podemos adicionar nossos arquivos de manifesto, com go templating nativo, assim

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
  namespace: {{ default .Release.Namespace .Values.namespace }}
  labels:
    app: {{ .Values.name }}
    version: {{ .Values.image.tag }}
    env: {{ .Values.env }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Values.name }}
      env: {{ .Values.env }}
  template:
    metadata:
      labels:
        app: {{ .Values.name }}
        version: {{ .Values.image.tag }}
        env: {{ .Values.env }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "khaosdoctor/zaqar:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          env:
            - name: SENDGRID_APIKEY
              value: {{ required "You must set a valid Sendgrid API key" .Values.environment.SENDGRID_APIKEY | quote }}
            - name: DEFAULT_FROM_ADDRESS
              value: {{ required "You must set a default from address" .Values.environment.DEFAULT_FROM_ADDRESS | quote }}
            - name: DEFAULT_FROM_NAME
              value: {{ required "You must set a default from name" .Values.environment.DEFAULT_FROM_NAME | quote }}
          ports:
            - name: http
              containerPort: 3000
              protocol: TCP
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Todos esses valores podem ser obtidos de um arquivo Values.yaml (para valores padrão), ou você pode defini-los na linha de comando usando a flag --set <caminho> valor.

Se queremos instalar nosso chart, podemos emitir o seguinte comando

helm upgrade --install --create-namespace myChart ./path/to/my/chart \
  --set image.tag=v1.0.0 \
  --set env=production \
  --set environment.SENDGRID_APIKEY=myKey \
  --set environment.DEFAULT_FROM_ADDRESS="my@email.com" \
  --set environment.DEFAULT_FROM_NAME="Lucas Santos"

O Helm também nos permite usar funções dentro de nossos deployments. Assim, podemos ter funções padrões para recorrer a valores padrões se não forem preenchidos, como o namespace. Também podemos ter a função required, que exibe uma mensagem e falha na instalação do Chart se o valor não for fornecido, como é o caso de nossas variáveis de ambiente.

Há muitas outras funções úteis na documentação deles – confira.

Agora, somos capazes de gerenciar não apenas de modo mais eficiente os recursos de nossa aplicação, mas também de publicar esses recursos em um sistema de controle de versão de código aberto sem nenhum problema ou questão de segurança.

Como criar um Helm Chart

É bem fácil criar um chart no Helm. Primeiro, você precisa ter o Helm instalado. Em seguida, basta digitar helm create <nome do chart> e ele criará um diretório preenchido com arquivos e outros diretórios. Esses arquivos são necessários para que o Helm crie um chart.

Vamos dar uma olhada mais detalhada em como é essa árvore de diretórios e quais são os arquivos dentro dela:

• chart.yaml: aqui é onde você colocará as informações relacionadas ao seu chart. Isso inclui a versão do chart, o nome e a descrição, para que você possa encontrá-lo se o publicar em um repositório aberto. Nesse arquivo, você também poderá definir dependências externas usando a chave dependencies (documentação em inglês).
• values.yaml: como vimos antes, este é o arquivo que contém os valores padrão para as variáveis.
• templates (dir): esse é o local onde você colocará todos os seus arquivos de manifesto. Tudo aqui será passado e criado no Kubernetes.
• charts: se o seu chart depender de outro chart que você possui, ou se você não quiser depender da biblioteca padrão do Helm (o registro padrão de onde o Helm baixa os charts), você pode trazer essa mesma estrutura dentro desse diretório. As dependências do chart são instaladas de baixo para cima, o que significa que se o chart A depende do chart B, e B depende do C, a ordem de instalação será C -> B -> A.

Há outros campos, mas estes são os mais comuns e são os obrigatórios. Você pode dar uma olhada rápida no repositório do Zaqar para ver como podemos publicar charts de código aberto.

Um aviso rápido: ao instalar o Helm, certifique-se de estar instalando a versão 3. A versão 2 ainda funciona, mas precisa de um componente do lado do servidor chamado Tiller, que vincula sua instalação do Helm a um único cluster. O Helm 3 removeu essa necessidade com a adição de vários CRDs, mas não é suportado em todas as versões do Kubernetes.

Como hospedar um Helm Chart

Ok, você criou seu chart, e agora? Precisamos baixar o repositório inteiro para instalar esses charts? Não! O Helm tem uma biblioteca pública para os charts mais usados, que funciona de modo semelhante ao Docker Hub.

Você também pode criar seu próprio repositório de charts e hospedá-lo on-line (documentação em inglês). O Helm bebe da mesma fonte que o HomeBrew, ou o Linux. Você pode acessar esses repositórios para baixar os charts contidos neles.

Uma vez que um repositório de charts é basicamente um arquivo index.yaml servido a partir de um servidor da web estático, você pode praticamente criar um repositório de charts de qualquer lugar.

Vamos pegar o Zaqar, por exemplo – ele está hospedado no GitHub Pages e é acessível por meio do meu domínio. Quando o Helm procura por um arquivo index.yaml, na verdade está procurando a lista de versões disponíveis desse chart, seus resumos SHA256 e a localização do arquivo empacotado .tgz para baixar o próprio chart. Isso é mais ou menos o que o NPM faz nos bastidores (de modo bastante simplificado).

Isso significa que você não precisa ter seu repositório clonado para sempre, e seus charts podem ser privados também. Você só precisa criar um repositório de charts.

Você pode até mesmo usar serviços hospedados como o Azure CR para fazer o trabalho, ou você pode ter uma solução completa chamada Chart Museum, que permite armazenar seus charts e oferece uma interface de usuário organizada.

Conclusão

O Helm veio para ficar. Ele ajudou e continuará a ajudar muitos desenvolvedores do Kubernetes por muito tempo.

Se você quer saber como usar o Helm, pode consultar a documentação deles, ou pode fazer este módulo de aprendizagem gratuito sobre como implantar suas aplicações no Kubernetes de maneira fácil com o Helm.

Este guia mostra como usar o Docker para baixar uma imagem do MSSQL Server e executá-la. O Azure Data Studio é a ferramenta de banco de dados multiplataforma que usaremos para conectar nosso contêiner do Docker ao MSSQL e para executar instruções SQL.

No final, mostrarei como importar um banco de dados para o sistema de arquivos do Docker para que você possa acessá-lo por meio do Azure Data Studio.

Confira outras dicas relacionadas aqui (em inglês):

• Como conectar seu AWS RDS Microsoft SQL Server usando Azure Data Studio
• Como importar um banco de dados de amostra para seu Microsoft SQL Server AWS RDS usando S3

Vamos abordar as tecnologias mencionadas abaixo:

• Banco de Dados: Microsoft SQL Server
• Contêiner para baixar o mssql-server-demo: Docker
• Instalador para o mssql-cli: Node.js (ambiente de execução)/Gerenciador de Pacotes do Node (NPM)
• Ferramenta de banco de dados e interface gráfica: Azure Data Studio

Como criar nosso ambiente com o Docker

Instalar o Docker

Guia completo aqui (em inglês):

1. Baixe o Docker CE (Community Edition) para Mac aqui .
2. Para instalar, clique duas vezes no arquivo .dmg e arraste o ícone do aplicativo Docker para o aplicativo de pasta.

Nota da tradução: para usuários de outras plataformas, como Windows e Linux, sugerimos o guia da própria Microsoft de instalação do SQL Server em português. Para o Docker, veja como instalar em outras plataformas aqui e aqui.

O que é Docker?

O Docker é uma plataforma que permite que o software seja executado em seu próprio ambiente isolado. O SQL Server (a partir de 2017) pode ser executado no Docker em seu próprio contêiner isolado.

Uma vez que o Docker esteja instalado, você simplesmente faz o download - ou "puxa" - a Imagem Docker do SQL Server no Linux para o seu Mac e, em seguida, a executa como um contêiner do Docker. Este contêiner é um ambiente isolado que contém tudo o que o SQL Server precisa para funcionar.

Iniciar o Docker

Abra seu aplicativo do Docker. Ele deve estar localizado na pasta Aplicativos.

Aumentar a memória

Por padrão, Docker terá 2GB de memória alocados para ele. O SQL Server precisa de pelo menos 3,25 GB. Para segurança, aumente para 4 GB, se puder. Já que esse é apenas um "playground", 2 GB deverão ser suficientes.

Opcional – caso queria aumenta o tamanho da memória:

1. Selecione Preferences no ícone pequeno do Docker no menu superior
2. Deslize o controle deslizante de memória para pelo menos 2 GB
3. Clique em Apply e Restart

Baixar o SQL Server

Abra uma janela no terminal e execute o seguinte comando:

sudo docker pull mcr.microsoft.com/mssql/server:2019-latest

Isso baixará a imagem mais recente do SQL Server 2019 para Linux do Docker para o seu computador.

Você também pode verificar a versão mais recente do contêiner no site do Docker, se desejar.

Iniciar a imagem do Docker

Execute o seguinte comando para iniciar uma instância da imagem do Docker que você acabou de baixar.

docker run -d --name sql_server_demo -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=really

Exemplo de saída:

Verificar o contêiner do Docker (opcional)

Você pode executar o seguinte comando para verificar se o contêiner do Docker está em execução:

docker ps

Se estiver instalado e funcionando, deverá retornar algo assim:

Se você fechou acidentalmente seu aplicativo do Docker, abra seu terminal e digite:

docker start sql_server_demo

Instalar o Node.js e o NPM

Verifique se você possui o Node.js e o NPM. Execute os seguintes comandos em seu terminal.

node -v
npm -v

Se a saída foi o número da versão, pule o restante desta seção.

Em seguida, visite o site do Node.js clicando no seguinte link:

https://nodejs.org/en/

Clique no botão de download da versão LTS (o número da versão pode ser diferente) para baixar o pacote Node.js:

Em seguida, clique e execute o pacote após o download. MacOS e Windows terão processos de instalação diferentes. Siga as instruções para instalar o Node.js.

Em seguida, teste novamente se o Node.js e o NPM foram instalados com sucesso executando os seguintes comandos no terminal:

node -v
npm -v

A saída deverá ser algo assim:

Instalar o sql-cli

Execute o seguinte comando para instalar a ferramenta de linha de comando do sql-cli. Essa ferramenta permite que você execute consultas e outros comandos em sua instância do SQL Server.

npm install -g sql-cli

Se houver algum erro de permissão, digite sudo antes do comando:

sudo npm install -g sql-cli

Conectar-se ao MSSQL Server

Conecte-se ao seu SQL Server usando o comando mssql, seguido dos parâmetros de nome de usuário e senha. Sintaxe:  -u <nome de usuário> -p <senha>

mssql -u sa -p reallyStrongPwd123

Sua saída deverá ser assim, se você se conectar com sucesso:

Executar um teste rápido

Execute um teste rápido para verificar se você consegue se conectar ao SQL Server. Use a seguinte instrução SQL para verificar sua versão do SQL Server:

SELECT @@VERSION;

Se estiver em execução, você deverá ver algo assim:

Baixar uma GUI do SQL Server – Azure Data Studio

O Azure Data Studio (anteriormente SQL Operations Studio) é uma ferramenta gratuita de gerenciamento de GUI que você pode usar para gerenciar o SQL Server em seu computador. Você pode usá-lo para criar e gerenciar bancos de dados, escrever consultas, fazer backup e restaurar bancos de dados e muito mais.

O Azure Data Studio está disponível para Windows, Mac e Linux.

Instalar o Azure Data Studio

Para instalar o Azure Data Studio em seu Mac:

1. Visite a página de download do Azure Data Studio (em inglês – você pode encontrar a versão para as plataformas Windows e Linux na mesma página) e clique no arquivo .zip para macOS
2. Assim que o download do arquivo .zip para conclusão, clique duas vezes nele para expandir seu conteúdo
3. Arraste o arquivo .app para a pasta Aplicativos (o arquivo provavelmente será chamado Azure Data Studio.app )

Conectar-se ao SQL Server

Agora que o Azure Data Studio está instalado, você pode usá-lo para se conectar ao SQL Server.

1. Inicie o Azure Data Studio. Ele está localizado na pasta Aplicativos.
2. Insira as credenciais de login e outras informações da instância do SQL Server à qual você deseja se conectar:

Deve ser semelhante a isto:

Deve ser semelhante a isto:

• Nome do servidor : localhost, [número da porta]
  Exemplo : localhost, 1433
• Tipo de autenticação : Login SQL
• Nome de usuário : [seu nome de usuário do SQL Server] ou sa
• Senha : [sua senha do SQL Server] ou reallyStrongPwd123
• Nome do banco de dados : <Default>
• Grupo de servidores : <Default>

Se você estiver usando uma porta diferente da padrão 1433, clique em Advanced... e insira-a no campo de Port.

Alternativamente, você pode acrescentá-la ao nome do seu servidor com uma vírgula no meio.

Por exemplo, se você estiver usando a porta 1400, digite localhost,1400. Agora você pode prosseguir e criar bancos de dados, executar scripts e realizar outras tarefas de gerenciamento do SQL Server.

1. Clique em New Query (Nova consulta).

2.     Digite SELECT @@VERSION, e clique em Run Query (Executar consulta).

Você deverá conseguir ver: Microsoft SQL Server em Results.

Importar um banco de dados de exemplo para o SQL Server usando o Azure Data Studio

Baixar o arquivo de banco de dados de exemplo AdventureWorks

Para obter os downloads OLTP do AdventureWorks, acesse este link e escolha qualquer banco de dados de amostra. No meu exemplo, eu escolho AdventureWorks2017.bak. Faremos o upload disso para o S3 Bucket.

Copiar o arquivo para sua janela de encaixe

Digite o seguinte comando no terminal seguindo esta sintaxe:

docker cp <location_of_file> <container_id>:/var/opt/mssql/data

Deverá ficar assim:

Se você esqueceu o ID do contêiner, use o comando docker ps.

Importar o banco de dados de exemplo no Docker

Vá para Azure Data Studio e clique em localhost, 1443 e escolha Restore (Restaurar).

Em seguida, escolha "Backup file" como a opção a partir da qual fazer a restauração. Em seguida, clique no botão azul à direita do caminho do arquivo de backup.

Procure o arquivo de banco de dados de exemplo. Deve estar localizado em:

/var/opt/mssql/data/AdventureWorks2017.bak

Escolha Restore.

Verifique seu host local, 1443. Ele deve gerar um banco de dados chamado AdventureWorks2017 e conter conteúdo como tabelas e visualizações. Caso contrário, clique com o botão direito em localhost, 1443 e escolha Refresh (Atualizar). Você também pode reiniciar seu aplicativo Azure Data Studio.

Testar o banco de dados de amostra

1. Escolha AdventureWorks2017 no menu suspenso.
2. Escreva uma consulta SQL:

SELECT * FROM HumanResources.Department;

3. Clique em Executar para executar a consulta.

Você deve ter uma saída como esta:

Parabéns! Você conclui o processo!

Recursos:

• Como instalar o SQL Server em um Mac (em inglês)

Conecte-se com o autor pelo LinkedIn aqui.

Escrito por: Nayeem Reza

Recentemente, estive analisando o desempenho de uma aplicação do React na qual eu trabalhava e, de repente, pensei em definir algumas métricas de desempenho para essa aplicação. Com isso, descobri que a primeira coisa que precisaria resolver são as renderizações desnecessárias que estou fazendo em cada uma das páginas da web. Você pode estar se perguntando o que são renderizações desnecessárias, não é mesmo? Vamos aprofundar nisso.

Desde o começo, o React mudou toda a filosofia de criação de aplicações para a web e, consequentemente, o modo como pessoas que desenvolvem o front-end pensam. Com a introdução do Virtual DOM, o React torna as atualizações de interface do usuário mais eficiente e, com isso, a experiência da aplicação para a web se torna mais "limpa".

Você já se perguntou como deixar suas aplicações em React mais rápida? Por que aplicações para a web em React de tamanho moderado continuam tendo um desempenho ruim? O problema está no modo como utilizamos o React!

Como o React funciona

Uma biblioteca moderna de front-end como o React não torna nossa aplicação magicamente mais rápida. Primeiro, nós, pessoas desenvolvedoras, devemos entender como o React funciona. Como os componentes atravessam os ciclos de vida ao longo da existência da aplicação? Portanto, antes de mergulharmos em qualquer técnica de otimização, precisamos entender melhor como o React realmente funciona nos bastidores.

Na essência do React, temos a sintaxe do JSX e a poderosa habilidade do React de construir e comparar Virtual DOMs (texto em inglês). Desde o seu lançamento, o React influenciou muitas outras bibliotecas de front-end. Por exemplo, o Vue.js também depende da ideia de Virtual DOMs.

Cada aplicação do React começa com um componente raiz. Podemos pensar na aplicação inteira como uma estrutura em forma de árvore onde cada galho é um componente. Componentes no React são 'funções' que renderizam a interface do usuário com base nos dados, ou seja, nas props e no state. Podemos representar com: CF (componente funcional)

UI = CF(dados)

Usuários interagem com a interface e causam alterações nos dados. As interações são tudo que o usuário pode fazer na nossa aplicação. Exemplos disso são: clicar em um botão, ver um carrossel de imagens, fazer solicitações a APIs. Todas essas interações alteram apenas os dados. Elas nunca causam nenhuma alteração na interface.

Aqui, os dados desempenham um papel fundamental na definição do estado de uma aplicação. Não apenas o que armazenamos em nosso banco de dados. Mesmo diferentes estados na interface do usuário, como qual aba está atualmente selecionada ou se uma caixa de seleção está marcada ou não, fazem parte desses dados. Sempre que ocorre uma alteração nos dados, o React utiliza as funções do componente para recriar a interface do usuário, mas apenas virtualmente:

UI1 = CF(dados1)
UI2 = CF(dados2)

O React calcula a diferença entre a interface atual e a nova interface aplicando um algoritmo de comparação (documentação em inglês) nas duas versões de seu Virtual DOM.

Mudancas = Diferenca(UI1, UI2)

Nota da tradução: caso tente acessar a documentação apontada no parágrafo acima e mais abaixo, você verá que os links, agora, apontam para uma página de documentação legada. Ocorreram diversas mudanças tanto no React quanto em sua documentação a partir da versão 18, mas a explicação sobre o algoritmo de comparação ainda é válida para o entendimento do processo.

Em seguida, o React prossegue aplicando apenas as alterações na interface do usuário (UI) real no navegador. Quando os dados associados a um componente mudam, o React determina se uma atualização na DOM "real" é necessária. Isso permite ao React evitar operações demoradas e que consomem muitos recursos no navegador, como a criação de elementos no DOM e a interação com elementos já existentes quando isso não é estritamente necessário.

Essa diferenciação e renderização repetida de componentes pode ser uma das principais fontes de problemas de desempenho no React. Criar uma aplicação em React na qual o algoritmo de diferenciação não consegue conciliar (documentação em inglês) efetivamente, leva a uma renderização repetida de toda a aplicação, na verdade, resultando em renderizações desperdiçadas e podendo resultar em uma experiência lenta e frustrante.

Durante o processo de renderização inicial, o React constrói uma árvore DOM como esta:

Suponha que uma parte dos dados mude. O que queremos que o React faça é renderizar novamente apenas os componentes que são diretamente afetados por essa mudança específica. Possivelmente, queremos que pule até mesmo o processo de diferenciação para o restante dos componentes. Vamos supor que alguns dados mudam no Componente 2 na imagem acima, e que esses dados foram passados de R para B e, depois, para 2. Se R for renderizado novamente, ele também renderizará outra vez cada um de seus filhos (A, B, C e D). O que o React realmente faz é o seguinte:

Na imagem acima, todos os nós amarelos são renderizados e diferenciados. Isso resulta em desperdício de tempo/recursos de computação. Aqui é onde concentrarmos principalmente nossos esforços de otimização. Configurando cada componente para renderizar e diferenciar apenas quando for necessário. Isso nos permitirá recuperar aqueles ciclos de CPU desperdiçados. Primeiro, veremos como identificar renderizações desnecessárias na nossa aplicação.

Identificar renderizações desnecessárias

Existem algumas maneiras diferentes de se fazer isso. O método mais simples é ativar a opção de atualizações de destaque na preferência de ferramentas de desenvolvimento do React.

Durante a interação com a sua aplicação, as atualizações são destacadas na tela com bordas coloridas. Você verá os componentes que foram renderizados novamente. Isso nos permite identificar novas renderizações que não eram necessárias.

Vamos seguir este exemplo:

Observe que, quando inserimos uma segunda tarefa, a primeira tarefa também pisca na tela a cada tecla pressionada. Isso significa que ela está sendo renderizada novamente pelo React juntamente com a entrada. Chamamos esse acontecimento de renderização "desnecessária". Sabemos que é desnecessária porque o conteúdo da primeira tarefa não mudou, mas o React não sabe disso.

Mesmo que o React atualize apenas os nós do DOM que foram alterados, a nova renderização ainda leva algum tempo. Em muitos casos, isso não é um problema, mas, se a lentidão for perceptível, devemos considerar algumas coisas para impedir essas renderizações redundantes.

Usando o método shouldComponentUpdate

Por padrão, O React renderizará o virtual DOM e comparará a diferença de cada componente na árvore para qualquer alteração em suas props ou state. Isso, no entanto, não é uma boa opção. À medida que nossa aplicação cresce, tentar renderizar novamente e comparar toda virtual DOM em cada ação acabará tornando tudo mais lento.

O React, então, fornece um método de ciclo de vida simples para indicar se um componente precisa de uma nova renderização. Isso é feito através de shouldComponentUpdate, que é acionado antes do início do processo da nova renderização. A implementação padrão dessa função retorna true.

Quando essa função retorna true para qualquer componente, ela permite que o processo de diferenciação de renderização seja acionado. Isso nos dá o poder de controlar esse processo de diferenciação. Suponha que precisemos evitar que um componente seja renderizado novamente, precisamos apenas retornar false dessa função. Como podemos ver na implementação do método, podemos comparar as props e state atuais e próximos para determinar se uma nova renderização é necessária.

Uso de componentes puros

Você já deve conhecer o React.Component, mas e React.PureComponent? Nós já falamos aqui sobre o método de ciclo de vida shouldComponentUpdate. Em componentes puros, já existe uma implementação padrão de shouldComponentUpdate() com uma comparação rasa de props e state. Portanto, um componente puro é um componente que apenas é renderizado novamente se as props e o state forem diferentes dos anteriores.

Na comparação rasa, tipos de dados primitivos como string, booleano e número são comparados pelo seu valor, enquanto tipos de dados complexos como array, objeto e função são comparados pela referência.

Se tivermos um componente funcional sem state em que precisamos implementar esse método de comparação antes que cada nova renderização ocorra, como podemos fazer isso? O React possui um Componente de Ordem Superior, chamado React.memo. É semelhante ao React.PureComponent, mas para componentes funcionais em vez de classes.

Por padrão, ele faz o mesmo que o shouldComponentUpdate(), que apenas compara superficialmente o objeto de props. Se, contudo, quisermos ter o controle sobre essa comparação, o que faremos? Também podemos fornecer uma função de comparação customizada como segundo argumento.

Tornar os dados imutáveis

Poderíamos usar um React.PureComponent e ainda ter uma maneira eficiente de detectar automaticamente quando qualquer prop complexa ou state – como um array, objeto ou outras opções – fossem alterados? É aqui que a estrutura de dados imutáveis torna a vida mais fácil.

A ideia por trás do uso de estruturas de dados imutáveis é simples. Como falamos anteriormente, para tipos de dados complexos, a comparação é feita com base em suas referências. Sempre que um objeto contendo dados complexos é alterado, em vez de fazer as alterações nesse objeto, podemos criar uma cópia desse objeto com as alterações, o que criará uma referência.

O ES6 possui o operador de spread que torna isso possível.

Podemos fazer o mesmo com arrays:

Evite passar uma nova referência para os mesmos dados antigos

Sabemos que sempre que props de um componente mudam, uma nova renderização acontece. Às vezes, porém, as props não mudam. Escrevemos o código de um modo que o React pensa que mudou, e isso acaba causando uma nova renderização. Dessa vez, no entanto, é uma renderizacão desnecessária. Então, basicamente, precisamos garantir que estamos passando uma referência diferente como props para dados diferentes. Além disso, precisamos evitar passar uma nova referência para os mesmos dados. Agora, vamos analisar alguns casos em que estamos criando esse problema. Veja o código abaixo:

Aqui está o conteúdo do componente BookInfo, onde estamos renderizando dois componentes, BookDescription e BookReview. Esse é o código correto e funciona bem, mas há um problema. BookDescription será renderizado novamente sempre que recebermos novos dados de avaliações como props. Por quê? Assim que o componente BookInfo recebe novas props, a função render é chamada para criar a sua árvore de elementos. A função de renderização cria uma constante book, o que significa criar outra referência. Portanto, BookDescription receberá book como uma nova referência, o que causará uma nova renderização de BookDescription. Para resolver isso, vamos refatorar esse código do seguinte modo:

Agora, a referência é sempre a mesma, this.book. Um outro objeto não é criado durante a renderização. Essa filosofia de nova renderização se aplica a todas as props, incluindo eventos, como abaixo:

Aqui, usamos duas maneiras diferentes (vincular métodos e usar uma arrow function na renderização) para chamar os métodos manipuladores de eventos, mas ambas criarão uma função sempre que o componente for renderizado novamente. Para resolver esses problemas, podemos vincular o método no constructor e usar propriedades de classe, o que ainda é experimental e não padronizado, mas muitos desenvolvedores já estão usando para passar funções para outros componentes em aplicações prontas para produção:

Conclusão

Internamente, o React utiliza diversas técnicas inteligentes para minimizar a quantidade de operações custosas no DOM e necessárias para atualizar a interface do usuário. Para muitas aplicações, o uso do React resultará em uma interface de usuário rápida sem a necessidade de fazer muito trabalho para otimizar o desempenho especificamente. No entanto, se conseguirmos seguir as técnicas que mencionei acima para resolver as renderizações desnecessárias, então, para aplicações grandes, também teremos uma experiência muito fluida em termos de desempenho.