Escrito por: Kevin Turney

Como combinar a eficiência de inserção de uma lista vinculada e a busca rápida de um array ordenado.

O que é uma árvore binária de busca?

Vamos começar com a terminologia básica para que possamos falar a mesma língua e investigar conceitos relativos. Primeiramente, quais princípios definem a árvore binária de busca (em inglês, Binary Search Tree ou BST)?

Observação: a partir daqui, usarei somente "BST" para facilitar.

Uma BST é considerada uma estrutura de dados feita a partir de nós (em inglês nodes), assim como as listas encadeadas (em inglês, linked lists – leia mais no artigo em inglês). Esses nós podem ser nulos ou ter referências (encadear) para outros nós. Esses "outros" nós são nós filhos, chamados de nó esquerdo e nó direito. Nós tem valores e esses valores determinam quando eles serão alocados dentro da BST.

Da mesma maneira que ocorre com uma lista vinculada, cada nó é referenciado somente por um outro nó, seu próprio pai, exceto o nó originário ou raiz. Podemos dizer, então, que cada nó em uma BST é uma BST própria, pois ao seguirmos a árvore, logo abaixo, nós alcançamos outro nó que tem outros dois filhos, um esquerdo e um direito. Independentemente de onde formos, esse nó vai ter um nó direito e um esquerdo como filhos e assim por diante.

1. O nó esquerdo é sempre menor que seu pai.

2. O nó direito é sempre maior que seu pai.

3. Uma BST é considerada balanceada se cada nível da árvore está completamente preenchido com exceção do último nível. Nele, a árvore é preenchida da esquerda pra direita.

4. Uma BST perfeita é aquela que é tanto cheia como completa (todos os nós filhos estão no mesmo nível e cada nó tem um nó esquerdo e um direito)

Aplicações úteis da BST

Quais são os exemplos reais das BSTs? Árvores são comumente usadas em buscas, lógicas de jogos, tarefas de preenchimento automático e gráficos.

Velocidade. Como mencionado anteriormente, a BST é uma estrutura ordenada de dados. Após a inserção, os nós são colocados de maneira ordenada. Essa ordem herdada faz as buscas serem mais rápidas. Similarmente a busca binária (com um array que é ordenado), cortamos pela metade o número de dados para ordenar a cada iteração. Por exemplo, suponha que estamos buscando por um nó com um pequeno valor. A cada iteração, continuamos movendo à esquerda em direção ao nó buscado. Isso elimina a metade dos valores maiores automaticamente!

Assim como um array, o dado é guardado por referência. Ao adicionar para a estrutura de dados, criamos um grupo na memória e o conectamos a ele. Fazer isso é mais rápido que criar um array com mais espaços e só então inserir o dado do menor array para o novo e maior.

Para resumir, inserção, exclusão e busca são habilidades de destaque para as BSTs.

Agora que entendemos os princípios, os benefícios e os componentes básicos de uma BST, vamos implementar uma em javascript.

A API para BST contém o seguinte: Insert, Contains, Get Min, Get Max, Remove Node, Check if Full, Is Balanced e os tipos de Busca — Depth First (preOrder, inOrder, postOrder), Breadth First Search e, por fim, Get Height. Essa é uma API bem grande, vamos olhar uma seção de cada vez.

Implementação

O construtor

A BST é feita de nós – e cada nó tem um valor.

function Node(value){  
	this.value = value;
    this.left = null;
    this.right = null;
}

O construtor da BST é criado a partir de um nó raiz.

function BinarySearchTree() {
	this.root = null;
}

let bst = new BST();
let node = new Node();

console.log(node, bst); // Node { value: undefined, left: null, right: null } BST { root: null }

Até agora, tudo vai bem.

Inserção (Insert)

BinarySearchTree.prototype.insert = function(value){
	let node = new Node(value);
	if(!this.root) this.root = node;
	else{    
    	let current = this.root;
        while(!!current){
        	if(node.value < current.value){
           		if(!current.left){
               		current.left = node;
                   	break;
               	}
        	   	current = current.left;
            }
            else if(node.value > current.value){
            	if(!current.right){
                	current.right = node;
                   	break;
               	}
                current = current.right;
            } 
            else {
            	break;
            }
     	}
     }
     return this;
};

let bst = new BST();
bst.insert(25); // BST { root: Node { value: 25, left: null, right: null } }

Vamos adicionar mais valores.

bst.insert(40).insert(20).insert(9).insert(32).insert(15).insert(8).insert(27);

BST { root:  Node { value: 25, left: Node { value: 20, left: [Object], right: null }, right: Node { value: 40, left: [Object], right: null } } }

Para uma visualização melhor, basta só clicar aqui!

Vamos decifrar isso.

1. Primeiramente, passamos um valor e criamos um nó
2. Observar se tem um nó raiz. Senão, configurar esse nó recém-criado para apontar para o nó raiz
3. Se existir um nó raiz, criamos uma variável declarada como "current" e configuramos esse valor para o nó raiz
4. Se o nó for recém-criado, node.value, for menor que o nó raiz, movemos o nó para a esquerda
5. Continuamos comparando esse node.value para os valores da esquerda.
6. Se o valor for bem menor e alcançarmos um ponto onde não existirem mais nós esquerdos, colocaremos esse item aqui.
7. Se o node.value é maior, repetiremos os mesmos passos acima exceto que em direção à direita.
8. Precisamos inserir um break, porque não há um contador de passos para terminar o laço.

Contém (contains)

Essa abordagem é bem direta.

BinarySearchTree.prototype.contains = function(value){
	let current = this.root;
    while(current){
    	if(value === current.value) return true;
        if(value < current.value) current = current.left;
        if(value > current.value) current = current.right;
    }
    return false;
};

Obter o mínimo e o máximo (Get Min e Get Max).

Siga para a esquerda para achar o menor valor e para a direita para o maior valor.

BinarySearchTree.prototype.getMin = function(node){
	if(!node) node = this.root;
    while(node.left) {
    	node = node.left;
    }
    return node.value
};

BinarySearchTree.prototype.getMax = function(node){
	if(!node) node = this.root;
    while(node.right) {
    	node = node.right;
    }
    return node.value;
};

Remoção (removal)

Remover um nó é uma operação mais complicada, pois os nós tem que ser reordenados para que as propriedades da BST sejam mantidas. Existe um caso onde um nó tem apenas um filho e um caso onde o nó tem tanto o filho da direita como da esquerda. Usaremos a uma função para nos ajudar a fazer o trabalho pesado.

BinarySearchTree.prototype.removeNode = function(node, value){
	if(!node){
    	return null;
    }
    if(value === node.value){ // sem filhos
    if(!node.left && !node.right) return null; // um filho e é o da direita
    if(!node.left) node.right;// um filho e é o da esquerda
    if(!node.right) node.left;  // dois filhos
    const temp = this.getMin(node.right);
    node.value = temp;
    node.right = this.removeNode(node.right, temp);
    return node;
    } else if(value < node.value) {
    	node.left = this.removeNode(node.left, value);
        return node;
   } else  {
      	node.right = this.removeNode(node.right, value);
        return node;
   }
};

BinarySearchTree.prototype.remove = function(value){
	this.root = this.removeNode(this.root, value);
};

Funciona assim…

Diferente de deleteMin e deleteMax, onde apenas cruzamos todo o caminho para a direita ou esquerda e pegamos o último valor, aqui, temos que retirar o nó e substituí-lo por algo. Essa solução foi desenvolvida em 1962 por T. Hibbard. Contamos com o caso onde podemos excluir um nó filho ou nenhum, esse é o caso mais fácil. Sem filhos, sem problemas. Se o filho estiver presente é só movê-lo para cima.

Entretanto, quando temos um nó para ser removido que tem dois filhos, qual deles fará a substituição? Certamente, não podemos mover o filho maior para baixo, então o que fazemos é trocá-lo pelo seu sucessor. Temos que buscar o menor filho à direita que é maior que o filho esquerdo.

1. Crie uma variável temporária e guarde o menor nó na sua direita. Isso cumprirá o requisito de que a propriedade que tem o valor da esquerda, ainda assim, é menor e os valores da esquerda que ainda são maiores;
2. Reinicialize o valor do nó essa variável temporária;
3. Exclua o nó direito;
4. Compare os valores na esquerda e na direita e determine qual será o valor atribuído.

Acho que uma imagem ilustrará isso melhor:

Busca (search)

Existem dois tipo de busca: Depth First e Breadth First. Breadth First (busca por largura, em português) é simplesmente quando você para a cada nível ao descer pela árvore. Seria algo parecido com isso: começamos na raiz, então filho esquerdo e depois filho direito. Passamos para o próximo nível, filhos esquerdos e filhos direitos. Pense nisso como se estivesse se movendo horizontalmente. Empregamos, até diria que simulamos, uma fila para ajudar a ordenar o processo. Passamos a função, porque, muitas vezes, queremos operar em um valor.

BinarySearchTree.prototype.traverseBreadthFirst = function(fn) {
	let queue = [];
    queue.push(this.root);
    while(!!queue.length) {
    	let node = queue.shift();
        fn(node);
        node.left && queue.push(node.left);
        node.right && queue.push(node.right);
    }
}

A busca Depth First (busca por profundidade, em português) envolve seguir para baixo da BST de uma maneira específica, ou seja: preOrder, inOrder, ou postOrder (pré-ordem, na ordem ou pós-ordem, respectivamente). Explicarei as diferenças em breve.

Em termos de código, temos uma função básica, traverseDepthFirst, e passamos uma função e um método. Outra vez, a função implica que queremos fazer algo com o valor no percurso, enquanto o método é o tipo de busca que estamos tentando realizar. Na traverseDepthFirst, temos uma alternativa, a busca preOrder, pré-selecionada.

Agora, qual a diferença entre elas? Primeiro, enviamos a função inOrder. Deveria ser autoexplicativo, mas não é. Estamos querendo dizer em ordem de inserção, em ordem do maior para o menor, ou do menor para o maior? Eu quero apenas que você tenha isso em mente de antemão. Nesse caso, sim, quer dizer do menor para o maior.

preOrder pode ser pensado como Pai, Filho Esquerdo, Filho Direito.

postOrder, por outro lado, seria como Filho Esquerdo, Filho Direito, Pai.

BinarySearchTree.prototype.traverseDFS = function(fn, method){
	let current = this.root;
    if(!!method) this[method](current, fn);
    else this._preOrder(current, fn);
};

BinarySearchTree.prototype._inOrder = function(node, fn){
	if(!!node){
    	this._inOrder(node.left, fn);
	    if(!!fn) fn(node);
    	this._inOrder(node.right, fn);
    }
};

BinarySearchTree.prototype._preOrder = function(node, fn){
	if(node){ 
    	if(fn) fn(node);
    	this._preOrder(node.left, fn);
    	this._preOrder(node.right, fn);
    }
};

BinarySearchTree.prototype._postOrder = function(node, fn){
	if(!!node){ 
    		this._postOrder(node.left, fn);
    		this._postOrder(node.right, fn);
        	if(!!fn) fn(node);
    }
};

Checar se a BST está cheia

Lembre-se do que comentamos antes: uma BST está cheia se cada nó existente na árvore tiver ou Zero ou dois filhos.

// uma BST está cheia se cada nó tiver ou zero ou dois filhos (nenhum nó pode ter apenas um filho)

BinarySearchTree.prototype.checkIfFull = function(fn){
	let result = true;
    this.traverseBFS = (node) => {
    	if(!node.left && !node.right) result = false;
        else if(node.left && !node.right) result = false;
    }
    return result;
};

Obter a altura da BST

O que significa obter a altura de uma árvore? Por que é importante? Aqui é onde a Complexidade de Tempo (também conhecida como Big O) aparece. Operações básicas são proporcionais ao tamanho da árvore. Então, se lembrarmos do que foi dito antes, ao buscar por um valor específico, o número de operações que temos a fazer é reduzido a metade a cada etapa.

Isso significa que temos um pão e vamos cortá-lo a metade, depois dividir essa metade em outros dois pedaços e continuamos fazendo isso até termos exatamente o pedaço de pão que queremos.

Em ciência da computação, chamamos isso de O(log n). Começamos com algum tipo de tamanho de entrada e, com o tempo, o tamanho fica melhor (mais achatado). Uma busca linear direta é denotada como O(n). Conforme o tamanho da entrada aumenta, também aumenta o tempo para executar as operações. O(n), conceitualmente, é uma linha de 45° começando da origem zero em um gráfico se movendo para a direita. A escala horizontal representa o tamanho de uma entrada e a escala vertical representa o tempo levado para completá-la.

Tempo constante é O(1). Não importa o tamanho da entrada, seja grande ou pequena, a operação leva exatamente o mesmo tempo. Por exemplo, push() e pop() de um array possuem tempo constante, assim como obter o valor em uma HashTable.

Eu vou explicar mais sobre isso em um artigo futuro, mas já quis adiantar um pouco as coisas agora.

De volta à altura.

Temos uma função recursiva. Nosso caso base é: "se não temos um nó, então começamos em this.root". Isso implica que podemos começar em valores menores na árvore e obter árvores com subalturas.

Então se passamos em this.root para começar, recursivamente movemos para baixo e adicionamos funções que chamarão a pilha de execução (em inglês execution stack). Quando alcançamos o fundo, a pilha é preenchida e, então, a chamada é executada e comparamos as alturas da esquerda e da direita e incrementamos um.

BinarySearchTree.prototype._getHeights = function(node){
	if(!node) return -1;
    let left = this._getHeights(node.left);
    let right = this._getHeights(node.right);
    return Math.max(left, right) + 1;
};

BinarySearchTree.prototype.getHeight = function(node){
	if(!node) node = this.root;
    return this._getHeights(node);
};

Por último, Is Balanced (está balanceada)

O que estamos fazendo aqui é observar se a árvore está preenchida em cada nível, e se  no último nível ela está preenchida da esquerda para a direita.

BinarySearchTree.prototype._isBalanced = function(node){
	if(!node) return true;
    let heightLeft = this._getHeights(node.left);
    let heightRight = this._getHeights(node.right);
    let diff = Math.abs(heightLeft — heightRight);
    if(diff > 1) return false;
    else return this._isBalanced(node.left) &&    this._isBalanced(node.right);
};

BinarySearchTree.prototype.isBalanced = function(node){
	if(!node) node = this.root;
    return this._isBalanced(node);
};

Imprimir a árvore (print)

Use isso para visualizar todos os métodos que você vê, especialmente travessias depth first e breadth first.

BinarySearchTree.prototype.print = function() {
	if(!this.root) {
    	return console.log('Nó raiz não encontrado');
    }
    let newline = new Node('|');
    let queue = [this.root, newline];
    let string = ''; 
    while(queue.length) {
    	let node = queue.shift();
        string += node.value.toString() + ' ';
        if(node === newline && queue.length) queue.push(newline);
        if(node.left) queue.push(node.left);
        if(node.right) queue.push(node.right);
     }
     console.log(string.slice(0, -2).trim());
};

Nosso amigo, o console.log! Sinta-se livre para brincar com ele e experimentar.

const binarySearchTree = new BinarySearchTree();
binarySearchTree.insert(5);
binarySearchTree.insert(3);

binarySearchTree.insert(7);
binarySearchTree.insert(2);
binarySearchTree.insert(4);
binarySearchTree.insert(4);
binarySearchTree.insert(6);
binarySearchTree.insert(8);
binarySearchTree.print(); // => 5 | 3 7 | 2 4 6 8

binarySearchTree.contains(4);

//binarySearchTree.printByLevel(); // => 5 \n 3 7 \n 2 4 6 8
console.log('--- DFS inOrder');

binarySearchTree.traverseDFS(function(node) {
	console.log(node.value);
}, '_inOrder'); // => 2 3 4 5 6 7 8

console.log('--- DFS preOrder');

binarySearchTree.traverseDFS(function(node) {
	console.log(node.value);
}, '_preOrder'); // => 5 3 2 4 7 6 8

console.log('--- DFS postOrder');

binarySearchTree.traverseDFS(function(node) {
	console.log(node.value);
}, '_postOrder'); // => 2 4 3 6 8 7 5

console.log('--- BFS');

binarySearchTree.traverseBFS(function(node) {
	console.log(node.value);
}); // => 5 3 7 2 4 6 8

console.log('min é 2:', binarySearchTree.getMin()); // => 2

console.log('máx é 8:', binarySearchTree.getMax()); // => 8

console.log('árvore contém 3 é true:', binarySearchTree.contains(3)); // => true

console.log('árvore contém 9 é false:', binarySearchTree.contains(9)); // => false

// console.log('altura da árvore é 2:', binarySearchTree.getHeight()); // => 2

console.log('árvore balanceada é true:', binarySearchTree.isBalanced(),'line 220'); // => true

binarySearchTree. remove(11); // remove o nó inexistente

binarySearchTree.print(); // => 5 | 3 7 | 2 4 6 8

binarySearchTree.remove(5); // remove 5 e 6 sobe

binarySearchTree.print(); // => 6 | 3 7 | 2 4 8

console.log(binarySearchTree.checkIfFull(), 'deve ser verdadeiro');

var fullBSTree = new BinarySearchTree(10);

fullBSTree.insert(5).insert(20).insert(15).insert(21).insert(16).insert(13);

console.log(fullBSTree.checkIfFull(), 'should be true');

binarySearchTree.remove(7); // remove 7 e 8 sobe

binarySearchTree.print(); // => 6 | 3 8 | 2 4

binarySearchTree.remove(8); // remove 8 e a árvore fica desbalanceada

binarySearchTree.print(); // => 6 | 3 | 2 4

console.log('árvore balanceada é false:', binarySearchTree.isBalanced()); // => true

console.log(binarySearchTree.getHeight(),'altura é 2')

binarySearchTree.remove(4);

binarySearchTree.remove(2);

binarySearchTree.remove(3);

binarySearchTree.remove(6);

binarySearchTree.print(); // => 'Não foi encontrado o nó raiz'

//binarySearchTree.printByLevel(); // => 'Não foi encontrado o nó raiz'

console.log('altura da árvore é -1:', binarySearchTree.getHeight()); // => -1

console.log('árvore balanceada é true:', binarySearchTree.isBalanced()); // => true

console.log('---');

binarySearchTree.insert(10);

console.log('altura da árvore é 0:', binarySearchTree.getHeight()); // => 0

console.log('ávroe balanceada é true:', binarySearchTree.isBalanced()); // => true

binarySearchTree.insert(6);

binarySearchTree.insert(14);

binarySearchTree.insert(4);

binarySearchTree.insert(8);

binarySearchTree.insert(12);

binarySearchTree.insert(16);

binarySearchTree.insert(3);

binarySearchTree.insert(5);

binarySearchTree.insert(7);

binarySearchTree.insert(9);

binarySearchTree.insert(11);

binarySearchTree.insert(13);

binarySearchTree.insert(15);

binarySearchTree.insert(17);

binarySearchTree.print(); // => 10 | 6 14 | 4 8 12 16 | 3 5 7 9 11 13 15 17

binarySearchTree.remove(10); // remove 10 e 11 sobe

binarySearchTree.print(); // => 11 | 6 14 | 4 8 12 16 | 3 5 7 9 x 13 15 17

binarySearchTree.remove(12); // remove 12 e 13 sobe

binarySearchTree.print(); // => 11 | 6 14 | 4 8 13 16 | 3 5 7 9 x x 15 17

console.log('árvore balanceada é true:', binarySearchTree.isBalanced()); // => true

//console.log('árvore balanceada otimizada é true:', binarySearchTree.isBalancedOptimized()); // => true

binarySearchTree.remove(13); // remove 13 e 13 não tem filhos - nada acontece

binarySearchTree.print(); // => 11 | 6 14 | 4 8 x 16 | 3 5 7 9 x x 15 17

console.log('árvore balanceada é false:', binarySearchTree.isBalanced()); // => false

Complexidade de tempo

1. Inserção O(log n)
2. Remoção O(log n)
3. Busca O(log n)

Uau, isso foi realmente muita informação. Espero que as explicações tenham sido claras e introdutórias o máximo possível. Outra vez, escrever me ajuda a solidificar conceitos e, como dizia Richard Feynman: "Quando uma pessoa ensina, duas pessoas aprendem."

Recursos

Estes são recursos ótimos para visualização (em inglês):

• Data Structure Visualization
• BinaryTreeVisualiser - Binary Search Tree
• VisuAlgo - Binary Search Tree, AVL Tree
• Big-O Algorithm Complexity Cheat Sheet (Know Thy Complexities!)
• Algorithms, 4th Edition by Robert Sedgewick and Kevin Wayne
• Binary search tree - Wikipedia

Versão da Wikipédia em português: Árvore binária de busca

Escrito por: Kevin Turney

Já vou dizendo isso de cara: você sabe os eventos que acontecem quando uma função é invocada? Não? Então, começaremos daqui.

Chamando uma função

Quando nós chamamos uma função, um contexto de execução ocorre na pilha de execução. Vamos entrar em detalhes mais específicos abaixo.

Primeiro, o que é uma pilha?

Uma pilha é uma estrutura de dados que opera com base em "o último a entrar é o primeiro a sair". Um item é "colocado" (em inglês, pushed) em uma pilha quando o estamos adicionando e é "retirado" (em inglês, popped) da pilha quando queremos removê-lo.

Usar uma pilha é um método de ordenar um determinado número de operações para a execução.

Agora, o que seria um contexto de execução? Um contexto de execução é criado quando temos uma chamada de função. Esse contexto ocorre em uma pilha de execução, uma ordem de operações. O item que é sempre o primeiro nessa pilha é o contexto de execução global. Logo após, estão os contextos criados pelas funções.

Esses contextos de execução tem propriedades, um objeto de ativação e um "this" vinculado. O "this" vinculado é uma referência de volta ao contexto de execução. O objeto de ativação inclui: parâmetros passados, declaração de variáveis e declaração de funções.

Então, toda vez que colocamos um novo contexto na pilha, normalmente, temos tudo de que precisamos para executar o código.

Por que eu disse normalmente?

Com recursão, estamos esperando retornar valores vindo de outros contextos de execução. Esses outros contextos de execução estão em pontos mais altos na pilha. Quando o último item na pilha finaliza a execução, esse contexto gerado retorna um valor. Esse valor retornado é passado como um valor retornado pelo caso recursivo para o próximo item. O contexto de execução, então, é retirado da pilha.

Recursão

Então, o que é recursão?

Uma função recursiva é uma função que chama a si mesma até que a "condição base" seja verdadeira e a execução pare.

Enquanto for falsa, continuaremos colocando o contexto de execução em cima da pilha. Isso pode acontecer até que tenhamos um sobrefluxo da pilha – ou, em inglês, "stack overflow". Um stack overflow ocorre quando ficamos sem memória para manter os itens na pilha.

Em geral, uma função recursiva tem ao menos duas partes: uma condição base e, ao menos, um caso recursivo.

Vamos olhar um exemplo clássico.

Fatorial

const fatorial = function(num) {
	debugger;
    if (num === 0 || num === 1) {
    	return 1  
    } else {
    	return num * fatorial(num - 1)
    }
}

fatorial(5)

Aqui, estamos tentando encontrar 5! (o fatorial de cinco). A função fatorial (texto em inglês) é definida como o produto de todos os números positivos menores ou iguais ao seu argumento.

A primeira condição é: "se o parâmetro passado for igual a 0 ou 1, terminaremos a chamada e retornaremos 1".

Para os casos recursivos, faremos o seguinte:

"Se o parâmetro não for 0 ou 1, passaremos o valor de num vezes o valor de retorno da função chamada outra vez com o argumento de num-1".

Então, se chamarmos fatorial(0), a função retornará 1 e nunca atingirá o caso recursivo.

A mesma situação ocorre com fatorial(1).

Podemos ver o que está acontecendo se inserirmos uma instrução debugger dentro do código e se usarmos as ferramentas do desenvolvedor para segui-lo e observar a chamada da pilha (em inglês, stack).

1. A stack de execução coloca o 5 como argumento dentro da função fatorial(). O caso base é falso, entrando na condição recursiva.
2. A stack de execução então chama a função fatorial() uma segunda vez com o argumento num-1 (4) como argumento. O caso base é falso entrando, assim, na condição recursiva.
3. A stack de execução chamará fatorial() uma terceira vez com o argumento num-1 (3). O caso base é falso. Portanto, outra vez, entramos na condição recursiva.
4. A stack de execução chama fatorial() uma quarta vez com num-1 (2) como seu argumento. O caso base é falso. Entramos na condição recursiva.
5. A stack executa fatorial() uma quinta vez com  num-1 (1) como seu argumento. Aqui o caso base é verdadeiro. Então, retornamos 1.

Nesse ponto, diminuímos o argumento passado por 1 em cada chamada de função, até alcançarmos a condição de retorno 1.

6. A partir daí, o último contexto de execução completa num === 1. Então, a função retorna 1.

7. A seguir, temos num === 2. O valor retornado é 2. (1×2).

8. Depois, temos num === 3. Retornamos 6. (2×3). Até agora, temos 1×2×3.

9. Posteriormente, temos num === 4, (4×6). 24 é o valor retornado no próximo contexto.

10. Finalmente, num === 5, (5×24) e, aqui, teremos 120 como valor final.

Recursão é bem elegante, certo?

Poderíamos ter feito a mesma coisa com um laço for ou while, mas, usando recursão, temos uma alternativa mais apresentável e bonita.

É por isso que usamos soluções recursivas.

Muitas vezes, um problema dissecado em partes menores é mais eficiente e ajuda a superá-lo mais facilmente. Desse modo, recursão é uma abordagem do tipo dividir-e-conquistar para resolver obstáculos.

• Subproblemas são mais fáceis de solucionar que o problema original;
• Soluções para subproblemas são combinadas para resolver o problema original.

"Dividir-e-conquistar" é bastante utilizado para atravessar ou buscar em estrutura de dados como em árvores de busca binária, gráficos e pilhas. Isso também funciona com muitos algoritmos de ordenação, como quicksort e heapsort (links em inglês).

Vamos trabalhar com alguns exemplos. Usaremos as ferramentas do desenvolvedor para ter um entendimento conceitual do que está acontecendo, onde e quando. Vamos lembrar de usar a ferramenta debugger e seguir passo a passo cada parte do processo.

Fibonacci

const fibonacci = function(num) {
    if (num <= 1) {
    	return num
    } else {
        return fibonacci(num - 1) + fibonacci(num - 2)
	}
}

fibonacci(5);

Arrays recursivos

function aplainar(arr) {
	var result = []  arr.forEach(function(element) {
    	if (!Array.isArray(element)) {
        	result.push(element)
        } else {
        	result = result.concat(aplainar(element))
		}
	})
    return result
}

aplainar([1, [2], [3, [[4]]]]);

Invertendo uma string

function inverter(str) {
	if (str.length === 0) return ''
    return str[str.length - 1] + inverter(str.substr(0, str.length - 1))
}

inverter('abcdefg');

Quicksort

function quickSort(arr, lo, hi) {
	if (lo === undefined) lo = 0
    if (hi === undefined) hi = arr.length - 1
    if (lo < hi) {    // fazer o particionamento do array
    	var p = partition(arr, lo, hi)
        console.log('partição de, ' + lo + ' até ' + hi + '=> partition: ' + p)    // ordenar os subarrays
        quickSort(arr, lo, p - 1)
        quickSort(arr, p + 1, hi)  
    }  // para a chamada inicial, retornar um array ordenado
    if (hi - lo === arr.length - 1) return arr
}

function partition(arr, lo, hi) {  
	// seleciona o último elemento como pivot
	var pivot = arr[hi]  
    // rastreia o index onde colocar o pivot  
    var pivotLocation = lo  
    // percorre o subarray e se element <= pivot, coloca element antes do pivot  
    for (var i = lo; i < hi; i++) {
    	if (arr[i] <= pivot) {
        	swap(arr, pivotLocation, i)
            pivotLocation++
        }
    }
    swap(arr, pivotLocation, hi)
    return pivotLocation
}

function swap(arr, index1, index2) {
	if (index1 === index2) return
    var temp = arr[index1]
    arr[index1] = arr[index2]
    arr[index2] = temp
    console.log('trocados' + arr[index1], arr[index2], +' em ', arr)  
    return arr
}

quickSort([1, 4, 3, 56, 9, 8, 7, 5])

Praticar técnicas de recursão é importante. Para estruturas de dados aninhadas como árvores, gráficos e pilhas, a recursão é inestimável.

Em um artigo futuro, discutirei otimização das chamada da cauda (em inglês, tail-call), técnicas de memoização e como elas se relacionam à recursão.

Agradeço por ter me acompanhado até aqui!

Recursos complementares

Wikipédia

Software Engineering (em inglês)

Outro artigo interessante (em inglês)

Material de curso aberto (gratuito) da M.I.T. (em inglês)

Na ciência da computação, análise de algoritmos é uma parte fundamental. É importante encontrar o algoritmo mais eficiente para a resolução de um problema. É possível que muitos algoritmos sejam capazes de resolver um problema, mas o desafio, aqui, é escolher o mais eficiente.

O ponto agora é: como vamos reconhecer o mais eficiente se temos um grupo com diversos algoritmos? Aqui, o conceito de complexidade de tempo e de espaço dos algoritmos ganha vida. A complexidade de tempo e a de espaço agem como uma medida escalonável para algoritmos. Comparamos os algoritmos com base na sua complexidade de espaço (total de memória) e de tempo (número de operações).

O valor total de memória do computador usada por um algoritmo quando executado é a complexidade de espaço daquele algoritmo. Para deixar este artigo um pouco menor, não discutiremos esse tipo de complexidade aqui.

Complexidade de tempo

Complexidade de tempo é o numero de operações que um algoritmo necessita para completar seu objetivo (considerando que cada operação leva o mesmo tanto de tempo). O algoritmo que executa a tarefa no menor número de operações possível é considerado o mais eficiente em termos de complexidade de tempo. Entretanto, as complexidades de tempo e de espaço também são afetadas por fatores como seu sistema operacional e hardware, mas não incluiremos isso nessa discussão.

Agora, para entender a complexidade de tempo, veremos um exemplo em que comparamos dois algoritmos diferentes que foram usados para resolver um problema específico.

O problema é a busca. Temos que buscar por um elemento em um array (nesse problema, assumiremos que o array está ordenado em ordem ascendente). Para resolver esse problema, temos dois algoritmos:

1. a busca linear (em inglês, linear search)

2. a busca binária (em inglês, binary search)

Vamos assumir que o array contém dez elementos e temos que encontrar o número 10 no array.

const array = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
const buscar_elemento = 10;

O algoritmo de busca linear compara cada elemento no array com a variável buscar_elemento. Quando o encontra dentro do array, retorna true.

Agora, vamos contar o número de operações necessárias. Aqui, a resposta é 10 (visto que compara cada elemento do array). Então, a busca linear usa dez operações para encontrar o elemento desejado (este é o número máximo de operações para esse array; no caso da busca linear, também é considerado o pior caso para um algoritmo).

Em geral, a busca linear necessitará de um número n de operações no seu pior caso (onde n é o tamanho do array).

Vamos examinar o algoritmo de busca binária para esse caso.

A busca binária pode ser facilmente entendida nesse exemplo:

Se estivermos tentando aplicar essa lógica no nosso problema, primeiro comparamos buscar_elemento com o elemento do meio do array, que é 5. Agora visto que 5 é menor que 10, começaremos a procurar por buscar_elemento no array de elementos maiores do que 5, e continuaremos assim até encontrar o desejado elemento – que, neste caso, é 10.

Agora, tente contar o número de operações de busca binária necessários para encontrar o elemento desejado. Levou, aproximadamente, quatro operações. Esse foi o pior caso para a busca binária. Isso mostra que existe uma relação logarítmica entre o número de operações necessárias e o tamanho total do array.

número de operações = log(10) = 4 na base 2 (aproximadamente)

Podemos generalizar esse resultado para a busca binária:

Para um array de tamanho n, o número de operações executadas pela busca binária é log(n)

Notação Big O

Nas declarações acima, vimos que, para um array de tamanho n, a busca linear executará n operações para completar a busca. Em contrapartida, a busca binária executou log(n) operações. Para isso, consideramos os respectivos piores casos. Podemos representar isso através de um gráfico (onde o eixo x é o número de elementos do array e o eixo y é o número de operações).

É bem claro pela figura que a taxa na qual a complexidade aumenta para a busca linear é muito mais alta que para a busca binária.

Quando analisamos um algoritmo, usamos uma notação para representar sua complexidade de tempo – essa notação se chama Big O.

Por exemplo: a complexidade de tempo para a busca linear pode ser representada como O(n). Para a busca binária, temos O(log n). Consideraremos que n e log(n) são o número de operações para cada tipo de busca.

A complexidade de tempo (ou notação Big O) para alguns dos algoritmos populares está listada abaixo:

1. Busca binária: O(log n)
2. Busca linear: O(n)
3. Ordenamento rápido (em inglês, Quick Sort): O(n * log n)
4. Ordenação por seleção (em inglês, Selection Sort): O(n * n)
5. Algoritmo do caixeiro viajante (em inglês, Travelling salesperson): O(n!)

Conclusão

Parabéns se você chegou até este ponto do artigo. Agora, você pode estar se perguntando: porque a complexidade de tempo é tão importante de entender?

Sabemos que, para um número pequeno de elementos (digamos que 10), a diferença entre o número de operações realizadas pela busca binária e pela busca linear não é tão grande, No mundo real, porém, na maioria das vezes, lidamos com problemas que tem um grande volume de dados.

Por exemplo, se tivermos 4 bilhões de elementos usando a busca linear, então, no pior dos casos faremos 4 bilhões de operações para completar a tarefa. A busca binária completará a tarefa em apenas 32 operações. É uma diferença enorme! Agora, vamos assumir que, se uma operação leva 1 ms para completar, a busca binária levará apenas 32 ms enquanto a busca linear levará 4 bilhões de milissegundos (aproximadamente, 46 dias). É uma diferença realmente significativa.

Esse é o motivo pelo qual o estudo da complexidade de tempo se torna importante quando falamos de um grande volume de dados.

Recursos (em inglês)

Grokking Algorithms – escrito por Aditya Y Bhargava

Introduction to Big O notation and Time Complexity – vídeo do CS Dojo

Escrito por: Margarita Obraztsova

Eu diria que essa foi uma bela de uma jornada. Eu sabia que o Webpack não era fácil de configurar: tem muitas partes com muitas opções, tem o npm hell, e isso tudo muda com as novas atualizações. Não é surpresa que possa se tornar, facilmente, uma tarefa problemática de se resolver depois que alguma coisa não saiu como você esperava (ou seja, não do modo como está na documentação).

Tentando resolver

Minha jornada de debug começou com a seguinte configuração:

webpack.config.js

// webpack v4.6.0

const path = require('path');const HtmlWebpackPlugin = require('html-webpack-plugin');const WebpackMd5Hash = require('webpack-md5-hash');const CleanWebpackPlugin = require('clean-webpack-plugin');const webpack = require('webpack');

module.exports = {  entry: { main: './src/index.js' },  output: {    path: path.resolve(__dirname, 'dist'),    filename: '[name].[chunkhash].js'  },  devServer: {    contentBase: './dist',    hot: true,    open: true  },  module: {    rules: [      {         test: /\.js$/,        exclude: /node_modules/,        use: [          { loader: 'babel-loader' },          {            loader: 'eslint-loader',            options: {               formatter: require('eslint/lib/formatters/stylish')             }           }         ]       }     ]  },  plugins: [    new CleanWebpackPlugin('dist', {}),    new HtmlWebpackPlugin({      inject: false,      hash: true,      template: './src/index.html',      filename: 'index.html'    }),    new WebpackMd5Hash()  ]

};

package.json

{  "name": "post",  "version": "1.0.0",  "description": "",  "main": "index.js",  "scripts": {    "build": "webpack --mode production",    "dev": "webpack-dev-server"   },  "author": "",  "license": "ISC",  "devDependencies": {    "babel-cli": "^6.26.0",    "babel-core": "^6.26.0",    "babel-loader": "^7.1.4",    "babel-preset-env": "^1.6.1",    "babel-preset-react": "^6.24.1",    "babel-runtime": "^6.26.0",    "clean-webpack-plugin": "^0.1.19",    "eslint": "^4.19.1",    "eslint-config-prettier": "^2.9.0",    "eslint-loader": "^2.0.0",    "eslint-plugin-prettier": "^2.6.0",    "eslint-plugin-react": "^7.7.0",    "html-webpack-plugin": "^3.2.0",    "prettier": "^1.12.1",    "react": "^16.3.2",    "react-dom": "^16.3.2",    "webpack": "^4.6.0",    "webpack-cli": "^2.0.13",    "webpack-dev-server": "^3.1.3",    "webpack-md5-hash": "0.0.6"  }}

.babelrc

{  "presets": ["env", "react"]}

.eslintrc.js

module.exports = {  env: {    browser: true,    commonjs: true,    es6: true  },  extends: [    'eslint:recommended',    'plugin:react/recommended',    'prettier',    'plugin:prettier/recommended'  ],  parserOptions: {    ecmaFeatures: {      experimentalObjectRestSpread: true,      jsx: true    },    sourceType: 'module'  },  plugins: ['react', 'prettier'],  rules: {    indent: ['error', 2],    'linebreak-style': ['error', 'unix'],    quotes: ['warn', 'single'],    semi: ['error', 'always'],    'no-unused-vars': [      'warn',      { vars: 'all', args: 'none', ignoreRestSiblings: false }    ],    'prettier/prettier': 'error'   }};

prettier.config.js

// .prettierrc.js

module.exports = {  printWidth: 80,  tabWidth: 2,  semi: true,  singleQuote: true,  bracketSpacing: true};

e, dentro da pasta src/:

index.html

<html> <head></head> <body>    <div id="app"></div>    <script src="<%= htmlWebpackPlugin.files.chunks.main.entry %>"></script> </body></html>

index.js

import React from 'react';import { render } from 'react-dom';import Hello from './Hello';

class App extends React.Component {  render() {    return (      <div>        <Hello hello={'Hello, world! And the people of the world!'} />     </div>    );  }}render(<App />, document.getElementById('app'));

Hello.js

import React from 'react';import PropTypes from 'prop-types';

class Hello extends React.Component {  render() {    return <div>{this.props.hello}</div>;  }}

Hello.propTypes = {  hello: PropTypes.string};

export default Hello;

Este era o panorama geral da estrutura do projeto:

Então, qual era o problema?

Como você pode perceber, eu configurei o ambiente, o ESLinting, e assim por diante. Criei tudo para que eu pudesse começar a escrever meus códigos e adicionar meus novos componentes à minha nova e brilhante biblioteca.

Se eu tivesse um erro, porém, o que eu faria? Vamos bagunçar as coisas um pouco.

Se tentarmos rastrear a origem do erro direto do console do nosso navegador do Google Chrome, seria muito difícil. Nos depararíamos com algo assim:

Os mapas de origem não estão configurados!

Eu quero apontar para um arquivo Hello.js, não para o arquivo minificado.

Isso, provavelmente, é uma coisa pequena

OU, ao menos, era o que eu pensava. Então, tentei configurar os mapas de origem como era descrito na documentação, adicionando a devtool.

Quando o webpack coloca seu código-fonte em um bundle, pode se tornar difícil de rastrear erros e avisos de volta ao local original. Por exemplo, se você colocar em um bundle três (chamado bundle.js) arquivos-fonte, a.js, b.js e c.js, e se um dos arquivos-fonte contiver um erro, o stack trace simplesmente apontará para bundle.js. Isso nem sempre é útil, pois você provavelmente vá querer saber em qual arquivo-fonte está o erro.

Para facilitar o rastreamento de erros e avisos, o JavaScript oferece mapas de origem (texto em inglês), que mapeiam seu código compilado de volta ao código-fonte original. Se um erro vier de b.js, o mapa de origem informará isso com exatidão. (fonte)

Então, eu, inocentemente, assumi que isso funcionaria no meu arquivo webpack.config.js:

...

module.exports = {  entry: { main: './src/index.js' },  output: {    path: path.resolve(__dirname, 'dist'),    filename: '[name].[chunkhash].js'  },  devtool: 'inline-source-map',  devServer: {    contentBase: './dist',    hot: true,    open: true  },  ...

e no package.json

..."scripts": {  "build": "webpack --mode production",  "dev": "webpack-dev-server --mode development"}...

Você tem que adicionar uma flag de desenvolvimento quando estiver trabalhando, ou, então, não vai funcionar como a documentação está dizendo. Ainda assim, mesmo com o valor sugerido, o mapa de origem não estava se comportando como eu esperei que fosse.

Se você ler este guia d0 SurviveJS – e você deveria fazê-lo – verá com seus próprios olhos.

Depois de esgotar todas as opções, eu fui ao Github tentar achar alguma solução possível.

Buscando soluções no GitHub

Tentei todas as sugestões nessa busca e nenhuma delas me ajudou.

Em certo ponto, cheguei a me questionar se havia algo errado com o meu webpack-dev-server. Acabei descobrindo que o webpack-dev-server já estava em manutenção há alguns meses.

Descobri, depois de encontrar por acaso esta issue, onde eles recomendam usar webpack-serve ao invés de webpack-dev-server.

Honestamente, foi a primeira vez que eu escutei sobre essa alternativa chamada webpack-serve. As documentações não pareciam promissoras também, mas eu, ainda assim, decidi dar uma oportunidade.

npm install webpack-serve --save-dev

Eu criei serve.config.js

const serve = require('webpack-serve');

const config = require('./webpack.config.js');

serve({ config });

Eu substituí webpack-dev-server por webpack serve no meu arquivo package.json.

Entretanto, o webpack-serve não me ajudou tampouco.

Nesse momento, eu me sentia como se tivesse esgotado cada sugestão que encontrei no GitHub:

• Webpack 4 — Sourcemaps : essa issue sugere que devtool: 'source-map' deveria funcionar, mas esse não foi o caso para mim;
• Como fazer o mapa de origem do webpack para os arquivos originais: adicionando devtoolModuleFilenameTemplate: info =>'file://' + path.resolve(info.absoluteResourcePath).replace(/\\/g, '/'). A minha configuração de saída não me ajudou, mas, ao invés de me mostrar o arquivo client.js, me mostrou o index.js;
• https://github.com/webpack/webpack/issues/6400: essa aqui não é uma descrição muito precisa do meu problema, então tentar executá-la não parecia que me ajudaria;
• Eu tentei usar webpack.SourceMapDevToolPlugin, mas não funcionou com a minha configuração, mesmo quando eu excluí devtools ou o configurei como false;
• Eu não usei o plug-in UglifyJS aqui, então configurar opções para isso não seria uma solução;
• Eu sei que o webpack-dev-server está em manutenção por agora. Então, eu tentei webpack-serve, mas parece que os arquivos de configuração não funcionaram também;
• Eu tentei o pacote source-map-support também, mas sem sorte. Eu vi uma situação similar aqui.

O abençoado StackOverflow

Eu estava perdendo um tempão para configurar os mapas de origem. Então, criei uma issue no StackOverflow.

Fazer o debugging da configuração do webpack normalmente é uma tarefa pesada: a melhor maneira a seguir é criar uma configuração do zero. Se alguma coisa nas documentações não funcionar como o esperado, talvez seja uma boa ideia encontrar uma issue parecida em uma branch, ou criar sua própria issue. Era o que eu pensava.

O primeiro rapaz que me respondeu estava realmente tentando me ajudar. Ele compartilhou sua própria configuração de trabalho. Ele até me ajudou criando um pull request.

Porém, tínhamos um problema aqui: por que sua configuração funciona? Olha, isso provavelmente não é magia, e temos alguma incompatibilidade de módulo aqui. Infelizmente, eu não pude entender por que minhas configurações não estavam funcionando:

O que passou é que ele fez, com a melhor das intenções, uma reestruturação do projeto do seu próprio jeito.

Isso significa que eu teria mais configurações ainda no projeto e teria também que mudar bastante coisa. Talvez, isso seria ok se eu tivesse fazendo uma configuração de teste, mas eu decidi fazer mudanças graduais nos arquivos para ver o que estava quebrando.

Dissecando a issue

Vamos dar uma olhada nas diferenças entre os arquivos Webpack e package.json dele e os meus. Apenas para deixar registrado, eu usei um repositório diferente na questão. Então, aqui está meu link para o repositório e para minha configuração.

// webpack v4.6.0

const path = require('path');const HtmlWebpackPlugin = require('html-webpack-plugin');const WebpackMd5Hash = require('webpack-md5-hash');const CleanWebpackPlugin = require('clean-webpack-plugin');const stylish = require('eslint/lib/formatters/stylish');const webpack = require('webpack');

module.exports = {  entry: { main: './src/index.js' },  output: {   devtoolModuleFilenameTemplate: info => 'file://' + path.resolve(info.absoluteResourcePath).replace(/\\/g, '/'),

   path: path.resolve(__dirname, 'dist'),   filename: '[name].[hash].js'  },  mode: 'development',  devtool: 'eval-cheap-module-source-map',  devServer: {    contentBase: './dist',    hot: true  },  module: {    rules: [      {        test: /\.js$/,        exclude: /node_modules/,        loader: 'babel-loader'      },      {        test: /\.js$/,        exclude: /node_modules/,        loader: 'eslint-loader',        options: {          formatter: stylish         }       }     ]   },   plugins: [    // new webpack.SourceMapDevToolPlugin({    //   filename: '[file].map',    //   moduleFilenameTemplate: undefined,    //   fallbackModuleFilenameTemplate: undefined,    //   append: null,    //   module: true,    //   columns: true,    //   lineToLine: false,    //   noSources: false,    //   namespace: ''    // }),    new CleanWebpackPlugin('dist', {}),    new HtmlWebpackPlugin({      inject: false,      hash: true,      template: './src/index.html',      filename: 'index.html'    }),    new WebpackMd5Hash(),    // new webpack.NamedModulesPlugin(),    new webpack.HotModuleReplacementPlugin()  ]

};

package.json

{

"name": "post","version": "1.0.0","description": "","main": "index.js","scripts": {  "storybook": "start-storybook -p 9001 -c .storybook",  "dev": "webpack-dev-server --mode development --open",  "build": "webpack --mode production"},"author": "","license": "ISC","devDependencies": {  "@storybook/addon-actions": "^3.4.3",  "@storybook/react": "v4.0.0-alpha.4",  "babel-cli": "^6.26.0",  "babel-core": "^6.26.0",  "babel-loader": "^7.1.4",  "babel-preset-env": "^1.6.1",  "babel-preset-react": "^6.24.1",  "babel-runtime": "^6.26.0",  "clean-webpack-plugin": "^0.1.19",  "eslint": "^4.19.1",  "eslint-config-prettier": "^2.9.0",  "eslint-loader": "^2.0.0",  "eslint-plugin-prettier": "^2.6.0",  "eslint-plugin-react": "^7.7.0",  "html-webpack-plugin": "^3.2.0",  "prettier": "^1.12.1",  "react": "^16.3.2",  "react-dom": "^16.3.2",  "webpack": "v4.6.0",  "webpack-cli": "^2.0.13",  "webpack-dev-server": "v3.1.3",  "webpack-md5-hash": "0.0.6",  "webpack-serve": "^0.3.1"},"dependencies": {  "source-map-support": "^0.5.5"}

}

Eu deixei eles interagirem propositalmente para que vocês pudessem ver minhas tentativas de debug. Tudo funcionou exceto os mapas de origem. Abaixo, eu vou compartilhar o que ele mudou na minha configuração - mas, obviamente, é melhor checar o pull request completo aqui.

 // webpack v4.6.0 const path = require('path'); const HtmlWebpackPlugin = require('html-webpack-plugin'); // deleting this module from the config-const WebpackMd5Hash = require('webpack-md5-hash'); const CleanWebpackPlugin = require('clean-webpack-plugin'); const stylish = require('eslint/lib/formatters/stylish'); const webpack = require('webpack');  module.exports = {  // adding the mode setting here instead of a flag+  mode: 'development',   entry: { main: './src/index.js' },   output: {  // deleting the path and the template from the output-    devtoolModuleFilenameTemplate: info =>-      'file://' + path.resolve(info.absoluteResourcePath).replace(/\\/g, '/'),-    path: path.resolve(__dirname, 'dist'),     filename: '[name].[hash].js'   },  // adding resolve option here+  resolve: {+    extensions: ['.js', '.jsx']+  },   //changing the devtool option   devtool: 'eval-cheap-module-source-map',  // changing the devServer settings   devServer: {-    contentBase: './dist',-    hot: true+    hot: true,+    open: true   },   module: {     rules: [    // putting my two checks into one (later he asked me in the chat to delete eslint option completely)       {-        test: /\.js$/,-        exclude: /node_modules/,-        loader: 'babel-loader'-      },-      {-        test: /\.js$/,+        test: /\.jsx?$/,         exclude: /node_modules/,-        loader: 'eslint-loader',-        options: {-          formatter: stylish-        }+        use: [+          { loader: 'babel-loader' },+          { loader: 'eslint-loader', options: { formatter: stylish } }+        ]       }     ]   },   plugins: [    //cleaned some options-    new CleanWebpackPlugin('dist', {}),+    new CleanWebpackPlugin('dist'),    //deleted some settings from the HTMLWebpackPlugin     new HtmlWebpackPlugin({-      inject: false,-      hash: true,-      template: './src/index.html',-      filename: 'index.html'+      template: './src/index.html'     }),  //completely removed the hashing plugin and added a hot module replacement one

-    new WebpackMd5Hash(),-    new webpack.NamedModulesPlugin(),+    new webpack.HotModuleReplacementPlugin()   ] };

package.json

"main": "index.js",   "scripts": {     "storybook": "start-storybook -p 9001 -c .storybook",  //added different flags for webpack-dev-server-    "dev": "webpack-dev-server --mode development --open",+    "dev": "webpack-dev-server --config ./webpack.config.js",     "build": "webpack --mode production"   },   "author": "",@@ -31,11 +31,6 @@     "react-dom": "^16.3.2",     "webpack": "v4.6.0",     "webpack-cli": "^2.0.13",-    "webpack-dev-server": "v3.1.3",-    "webpack-md5-hash": "0.0.6",-    "webpack-serve": "^0.3.1"-  },-  "dependencies": {//moved dev server to dependencies

-    "source-map-support": "^0.5.5"+    "webpack-dev-server": "v3.1.3"   } }

Como você pôde perceber, ele deletou um montão de módulos e adicionou mode dentro das configurações. Dando uma olhada no pull request, você pode ver que ele também adicionou alguns hot-module replacement específicos orientados ao React.

Isso ajudou os mapas de origem a funcionarem através do sacrifício de vários plug-ins, mas não tem uma explicação muito concreta para ele fazer o que ele fez. Como uma pessoa que costuma ler a documentação, isso não era muito satisfatório para mim.

Mais tarde, peguei meu webpack.config.js inicial e comecei adicionar as mudanças passo a passo para ver quando os mapas de origem finalmente começariam a funcionar.

Mudança 1:

-    new CleanWebpackPlugin('dist', {}),+    new CleanWebpackPlugin('dist'),

Mudança 2:

Adicionei o webpack-dev-server às dependências, não às devDependencies:

...

},

"dependencies": {

  "webpack-dev-server": "^3.1.3"

}

}

...

Mudança 3:

Em seguida, removi algumas das configurações de devServer:

devServer: {-    contentBase: './dist',+    hot: true,+    open: true   },

Mudança 4:

Remover o estilo:

...

},

devtool: 'inline-source-map',  devServer: {    hot: true,    open: true  },

...

use: [  { loader: 'babel-loader' },  {    loader: 'eslint-loader'  }

]

....

Mudança 5:

Vamos tentar remover o plug-in de hashing WebpackMd5Hash agora:

...

module.exports = {mode: 'development',entry: { main: './src/index.js' },output: {  path: path.resolve(__dirname, 'dist'),  filename: '[name].js'  },devtool: 'inline-source-map',...

plugins: [  new CleanWebpackPlugin('dist'),  new HtmlWebpackPlugin({    inject: false,    hash: true,    template: './src/index.html',    filename: 'index.html'  })-    new WebpackMd5Hash(), ]

};

Mudança 6:

Agora, vamos tentar remover algumas configurações do HtmlWebpackPlugin:

...

plugins: [  new CleanWebpackPlugin('dist'),  new HtmlWebpackPlugin({    template: './src/index.html'  })]};

...

Mudança 7:

Como podemos perceber nesse código, ele adicionou algumas opções aqui. Eu, pessoalmente, não entendo por que precisamos delas aqui. Eu não encontrei a informação nas documentações tampouco.

...

resolve: {  extensions: ['.js', '.jsx']},module: {

...

Mudança 8:

Deletando o caminho de saída:

...

entry: { main: './src/index.js' },output: {  filename: '[name].js'},devtool: 'inline-source-map',

...

Mudança 9:

Adicionando o plug-in hot-module replacement:

...

const HtmlWebpackPlugin = require('html-webpack-plugin');const CleanWebpackPlugin = require('clean-webpack-plugin');const webpack = require('webpack');

...

plugins: [  new CleanWebpackPlugin('dist'),  new HtmlWebpackPlugin({    template: './src/index.html'  }),  new webpack.HotModuleReplacementPlugin()]};

...

Mudança 10:

Adicionando — config ao package.json:

-    "dev": "webpack-dev-server --mode development --open",+    "dev": "webpack-dev-server --config ./webpack.config.js",

Vamos deixar as coisas claras: nesse ponto, eu já tinha quase reescrito a configuração.

Isso é um grande problema, visto que eu não posso reescrever tudo toda vez que algo não está funcionando!

Create-react-app na melhor fonte para aprender sobre webpack

Como último recurso, eu fui verificar como o create-react-app implementa o mapa de origem. Essa foi a melhor decisão depois de tudo. Essa é a configuração do webpack na versão dev.

Se conferirmos como o devtool é implementado aqui, veremos que:

// Você pode querer 'avaliar' se você prefere ver a saída compilada no DevTools.

https://github.com/facebook/create-react-app/issues/343.

devtool: ‘cheap-module-source-map’

Então, isso me apontou uma outra issue, encontrada aqui.

// webpack v4

const path = require('path');const HtmlWebpackPlugin = require('html-webpack-plugin');const WebpackMd5Hash = require('webpack-md5-hash');const CleanWebpackPlugin = require('clean-webpack-plugin');

module.exports = {

mode: "development",entry: { main: './src/index.js' },output: {  path: path.resolve(__dirname, 'dist'),  filename: '[name].[hash].js'},devtool: 'cheap-module-source-map',devServer: {  contentBase: './dist',  hot: true,  open: true},module: {

Mudar as linhas ainda não funcionou - ainda! Eu aprendi que mapa de origem é uma questão que demanda tempo.

Perguntando para a pessoa certa

Todo projeto open source tem pessoas para mantê-lo. Nesse caso, era definitivamente uma boa alternativa perguntar aos meninos diretamente.

Embora meu método de tentativa e erro não tenha funcionado exatamente como eu esperava, fui surpreendida positivamente em como o time de manutenção estava disponível para responder.

Então, criei um repositório com a configuração que você encontra aqui. Dê uma olhada no segundo commit lá.

Para torná-lo mais fácil para você, aqui está meu projeto webpack.js, onde eu voltei para a minha configuração inicial, mais limpa:

// webpack v4

const path = require('path');const HtmlWebpackPlugin = require('html-webpack-plugin');const WebpackMd5Hash = require('webpack-md5-hash');const CleanWebpackPlugin = require('clean-webpack-plugin');

module.exports = {  mode: 'development',  entry: { main: './src/index.js' },  output: {    path: path.resolve(__dirname, 'dist'),    filename: '[name].[hash].js'  },  devtool: 'inline-source-map',  devServer: {    contentBase: './dist',    hot: true,    open: true  },  module: {    rules: [      {        test: /\.js$/,        exclude: /node_modules/,        use: [          { loader: 'babel-loader' },          {            loader: 'eslint-loader',            options: {               formatter: require('eslint/lib/formatters/stylish')             }          }         ]        }      ]  },  plugins: [    new CleanWebpackPlugin('dist'),    new HtmlWebpackPlugin({      inject: false,      hash: true,      template: './src/index.html',      filename: 'index.html'    }),    new WebpackMd5Hash()  ]};

Depois de verificar meu código, o responsável pela manutenção criou uma issue.

Vamos recapitular o que ele incluiu aqui:

Configuração da opção mode

O primeiro problema que encontrei dizia respeito a como  a opção mode foi configurada. Nos scripts do npm, mode estava definido como:

webpack --mode production

A maneira correta seria:

webpack --mode=production

Os scripts do npm aparecem mais ou menos assim para mim no final:

"scripts": {
"build": "webpack --mode=production",
"start": "webpack-dev-server --mode=development --hot"
}

Também alterei dev para start, já que é mais padrão e esperado de outros desenvolvedores como comando. Você pode, de fato, usar npm start, sem o comando run?

...

"scripts": {  "build": "webpack --mode production",  "dev": "webpack-dev-server --mode=development --hot"},

...

A seguir, ele sugeriu o seguinte:

devtool para mapas de origem

Sempre recomendo a opção inline-source-map. É a mais direta e está incluída no próprio bundle como um comentário ao final.

module.exports = {
+ devtool: 'inline-source-map',
// rest of your config
}

Eu também recomendo criar um objeto separado e populá-lo somente em desenvolvimento:

comando

webpack-dev-server --mode=development NODE_ENV=development

webpack.config.js

const webpackConfig = {}

if (process.env.NODE_ENV === 'development') {
webpackConfig.devtool = 'inline-source-map'
}

Dessa maneira, você tem certeza de que o bundle em produção não é afetado por isso.

Então, ele sugeriu remover o ESLint da configuração de carregamento (em inglês, loaders):

Linting e experiência do desenvolvedor

Honestamente, eu deletaria eslint como um loader. É superinvasivo e atrapalha o fluxo de desenvolvimento. Eu prefiro adicionar um githook de precommit para verificar isso.

Isso é superfácil e somente precisa adicionar um script como esse:

"scripts": {
+ "lint": "eslint ./src/**/*.js"
"build": "webpack --mode=production",
"start": "webpack-dev-server --mode=development --hot"
}

Então, combiná-lo com husky

e adicioná-lo aos scripts:

...

"scripts": {

"lint": "eslint ./src/**/*.js",

"build": "webpack --mode production",

"dev": "webpack-dev-server --mode=development --hot"

},

...

Eu cometi um erro em src/Hello.js de propósito para ver como os mapas de origem funcionariam dessa vez.

import React from 'react';import PropTypes from 'prop-types';

class Hello extends React.Component {  console.log(hello.world);  render() {    return <div>{this.props.hello}</div>;  }}Hello.propTypes = {  hello: PropTypes.string};export default Hello;

Como eu consertei o problema

O problema era o ESLint. Depois de especificar os modos corretamente e de remover o eslint-loader, os mapas de origem funcionaram corretamente!

Seguindo o exemplo que o mantenedor me deu, eu atualizei meu Webpack para:

// webpack v4

const path = require('path');const HtmlWebpackPlugin = require('html-webpack-plugin');const WebpackMd5Hash = require('webpack-md5-hash');const CleanWebpackPlugin = require('clean-webpack-plugin');module.exports = {  entry: { main: './src/index.js' },  output: {    path: path.resolve(__dirname, 'dist'),    filename: '[name].[hash].js'  },  devtool: 'inline-source-map',  devServer: {    contentBase: './dist',    hot: true,    open: true  },  module: {    rules: [     {      test: /\.js$/,      exclude: /node_modules/,      use: [{ loader: 'babel-loader' }]     }    ]  },  plugins: [    new CleanWebpackPlugin('dist'),    new HtmlWebpackPlugin({      inject: false,      hash: true,      template: './src/index.html',      filename: 'index.html'    }),    new WebpackMd5Hash()  ]};

e meu package JSON para:

{

"name": "post","version": "1.0.0","description": "","main": "index.js","scripts": {  "build": "webpack --mode=production",  "start": "NODE_ENV=development webpack-dev-server --mode=development --hot"},"author": "","license": "ISC","devDependencies": {  "babel-cli": "^6.26.0",  "babel-core": "^6.26.0",  "babel-loader": "^7.1.4",  "babel-preset-env": "^1.6.1",  "babel-preset-react": "^6.24.1",  "babel-runtime": "^6.26.0",  "clean-webpack-plugin": "^0.1.19",  "eslint": "^4.19.1",  "eslint-config-prettier": "^2.9.0",  "eslint-loader": "^2.0.0",  "eslint-plugin-prettier": "^2.6.0",  "eslint-plugin-react": "^7.7.0",  "html-webpack-plugin": "^3.2.0",  "prettier": "^1.12.1",  "react": "^16.3.2",  "react-dom": "^16.3.2",  "webpack": "^4.6.0",  "webpack-cli": "^2.0.13",  "webpack-md5-hash": "0.0.6"},"dependencies": {  "webpack-dev-server": "^3.1.3"}

}

Finalmente, meus mapas de origem funcionaram!

Conclusões:

Mapas de origem tem pautado varias discussões de bugs desde 2016, como você pode ver aqui.

O Webpack precisa de ajuda com auditoria!

Depois de encontrar esse bug, eu submeti uma issue para o pacote ESLint loader.

Quando estamos falando de verificar a qualidade dos mapas de origem, nós podemos usar esta ferramenta.

O que você pode fazer se tiver um problema com o webpack?

Caso você se veja preso em um problema com Webpack, não se desespere! Siga os passos abaixo:

• Procure nas issues do GitHub situações similares às suas.
• Tente conferir os arquivos iniciais e ver como o recurso foi implementado lá, com o create-react-app, por exemplo.
• Faça perguntas no StackOverflow — não tenha medo! Tenha certeza de que você tentou todas as soluções possíveis ao seu alcance.
• Não hesite em fazer um tweet sobre o assunto e perguntar diretamente aos mantenedores.
• Crie issues no Github quando as encontrar. Isso vai ajudar muito os contribuidores!

Neste artigo, eu deixo o meu arquivo de configuração e o processo usado para configurá-lo passo a passo.

Nota: considerando que muitas das dependências do npm podem ter mudado quando você estiver lendo isso, essa mesma configuração pode não funcionar para você!

Se puder, compartilhe este artigo. Obrigada!

Às vezes, fico me perguntando se eu sei muito sobre poucas coisas.

Há algumas semanas, eu conversava com um amigo que mencionou despretensiosamente que "você nunca deveria rodar uma aplicação do Node diretamente em produção".

Eu balancei minha cabeça vigorosamente em sinal de afirmação para demonstrar que eu também nunca rodaria Node em produção porque... hahaha... todo mundo sabe disso. Só que eu não sabia disso!  Eu deveria saber disso? EU AINDA TENHO PERMISSÃO PARA PROGRAMAR?

Se eu fosse desenhar um Diagrama de Venn do que eu sei em comparação com o que eu acho que os outros sabem, seria algo assim...

A propósito, aquele pontinho bem pequeno ali fica cada vez menor conforme eu fico velho.

Existe um diagrama melhor criado por Alicia Liu que, de certo modo, mudou minha vida. Ela diz que, na verdade, seria mais parecido com isso...

Eu amo esse diagrama porque eu quero muito que ele seja verdade. Eu não quero passar o resto da minha vida como um pontinho azul pequeno – e cada vez menor – e insignificante.

MUITO DRAMÁTICO. Ao menos, não estamos partindo da estakazero. Eu não estou controlando qual a próxima música que vai tocar enquanto estou escrevendo, mas escrever artigos com confidências é viciante como uma droga

Bem, assumindo que o diagrama de Alicia seja verdade, eu gostaria de compartilhar com você o que eu sei agora sobre rodar aplicações do Node em produção. Talvez nossos Diagramas de Venn relativos não se sobreponham nesse tema.

Primeiro, vamos analisar a declaração "nunca rodar aplicações do Node diretamente em produção".

Nunca rodar o Node diretamente em produção

Talvez, sim; talvez, não. Vamos falar sobre o raciocínio por trás dessa declaração. Primeiro, vamos dar uma olhada nos motivos contra fazermos isso.

Suponha que temos um simples servidor do Express. O servidor do Express mais simples que eu posso pensar...

const express = require("express");
const app = express();
const port = process.env.PORT || 3000;

// Visível em http://localhost:3000
app.get("/", function(req, res) {
  res.send("Again I Go Unnoticed"); //"De novo, ninguém me nota", em português 
});

app.listen(port, () => console.log(`Example app listening on port ${port}!`)); //"App de exemplo escutando na porta... ", em português 

Rodaríamos isso usando o script start no arquivo package.json.

"scripts": {
  "dev": "npx supervisor index.js",
  "start": "node index.js"
}

Existem dois problemas aqui. O primeiro é um problema de desenvolvimento. O segundo é um problema de produção.

O problema de desenvolvimento: ao mudarmos o código, teremos que parar e começar a aplicação para termos nossas mudanças captadas.

Para solucionar isso, normalmente usamos algo como um gerenciador de processos do Node, como o supervisor ou o nodemon. Esses pacotes observarão nosso projeto e reiniciarão nosso servidor sempre que fizermos mudanças. Eu normalmente faço algo assim:

"scripts": {  "dev": "npx supervisor index.js",  "start": "node index.js"}

Então, eu rodo npm run dev. Note que eu estou rodando npx supervisor aqui, o que me permite usar o pacote supervisor sem ter de instalá-lo. Eu amo a modernidade (na maior parte do tempo).

Nosso outro problema é que ainda estamos rodando diretamente o Node e já dissemos que era algo ruim. Agora, estamos prestes a descobrir o porquê.

Adiciono outro roteador aqui, que tenta ler um arquivo do disco que não existe. Esse é um erro que poderia facilmente aparecer em qualquer aplicação do mundo real.

const express = require("express");
const app = express();
const fs = require("fs");
const port = process.env.PORT || 3000;

// viewed at http://localhost:3000
app.get("/", function(req, res) {
  res.send("Again I Go Unnoticed");
});

app.get("/read", function(req, res) {
  // Isso aqui não existe 
  fs.createReadStream("minha-autoestima.txt");
});

app.listen(port, () => console.log(`Example app listening on port ${port}!`));

Se rodarmos diretamente o Node com o npm start e navegarmos até o endpoint read, vamos obter um erro, pois o arquivo não existe.

Não é um grande problema, certo? É um erro. Acontece.

É um grande problema, sim. Se você voltar ao seu terminal, verá que sua aplicação quebrou completamente.

Isso significa que, se você voltar ao navegador e se tentar acessar o URL raiz do site, terá a mesma mensagem de erro. Um erro em apenas um método quebrou sua aplicação para todos os usuários.

Isso é péssimo – muito ruim, mesmo. Essa é uma das razões principais porque as pessoas dizem "nunca rode o Node diretamente em produção".

OK. Então, se nós não podemos rodar o Node diretamente em produção, qual seria a maneira certa de fazê-lo?

Opções para o Node em produção

Temos algumas opções.

Uma delas seria simplesmente usar algo como o supervisor ou o nodemon em produção da mesma maneira que o usamos em ambiente de desenvolvimento. Isso poderia funcionar, mas essas ferramentas são muito pouco para um controle adequado. Uma opção melhor é chamada de pm2.

Resolva com o pm2

O pm2 é um gerenciador de processos do Node que tem muitos alertas. Assim como todo o resto em "JavaScript", você o instala (globalmente) através do npm — ou pode simplesmente usar o npx outra vez. Faça como você quiser.

Existem muitas maneiras de rodar sua aplicação com o pm2. A maneira mais simples possível seria apenas chamar pm2 start no seu ponto de entrada.

"scripts": {
  "start": "pm2 start index.js",
  "dev": "npx supervisor index.js"
},

Você verá algo mais ou menos assim no seu terminal…,

Esse é o nosso processo rodando, monitorado pelo pm2 em segundo plano. Se você visitar o endpoint read e se a aplicação quebrar, o pm2 vai reinicializá-la automaticamente. Você não verá nada disso no terminal, pois está rodando em segundo plano. Se você quiser observar o pm2 fazendo o trabalho, precisará rodar pm2 log 0, sendo 0 o id do processo cujos relatórios desejamos ver.

Pronto, tudo certo! Você pode ver a reinicialização da aplicação quando ela cair devido ao nosso erro não tratado.

Podemos também colocar nosso comando dev e fazer com que o pm2 observe os arquivos para nós e os reinicialize em quaisquer mudanças.

"scripts": {
  "start": "pm2 start index.js --watch",
  "dev": "npx supervisor index.js"
},

Note que, em função de o pm2 rodar tudo em segundo plano, você não pode simplesmente apertar ctrl+c para terminar o processo do pm2. Você tem que pará-lo usando o ID ou o nome.

pm2 stop 0

pm2 stop index

Observe, também, que o pm2 retém uma referência para o processo para que você possa recomeçá-lo.

Se você quiser excluir a referência do processo, precisa executar pm2 delete. Você pode parar e excluir um processo em um comando com delete.

pm2 delete index

Também podemos usar o pm2 para rodar múltiplos processos da nossa aplicação. O pm2 automaticamente balanceará o carregamento através dessas instâncias.

Múltiplos processos com pm2 no modo fork

O pm2 tem diversas opções de configuração e elas estão contidas em um arquivo de "ecossistema". Para criar um, execute pm2 init. Você vai obter um resultado parecido com esse...

module.exports = {
  apps: [
    {
      name: "Express App",
      script: "index.js",
      instances: 4,
      autorestart: true,
      watch: true,
      max_memory_restart: "1G",
      env: {
        NODE_ENV: "development"
      },
      env_production: {
        NODE_ENV: "production"
      }
    }
  ]
};

Eu vou ignorar a seção "deploy" nesse artigo, pois não tenho a menor ideia do que ela faz.

A seção "apps" é onde você define as aplicações que você deseja que o pm2 rode e monitore. Você pode rodar mais de uma. Muitas dessas configurações do arquivo são, provavelmente, autoexplicativas. Eu quero me concentrar naquela configuração chamada instances (em português, instâncias).

O pm2 pode rodar múltiplas instâncias da sua aplicação. Você pode informar um número de instances que você deseja rodar e o pm2 fará o trabalho. Então, se queremos rodar 4 instances, podemos rodar o seguinte arquivo de configuração:

module.exports = {
  apps: [
    {
      name: "Express App",
      script: "index.js",
      instances: 4,
      autorestart: true,
      watch: true,
      max_memory_restart: "1G",
      env: {
        NODE_ENV: "development"
      },
      env_production: {
        NODE_ENV: "production"
      }
    }
  ]
};

Então, tudo que precisamos é digitar pm2 start.

O pm2 está agora rodando em um modo cluster (em português, "agrupamento"). Cada um desses processos está rodando em uma CPU diferente na minha máquina, dependendo de quantos núcleos de processamento (em inglês, cores) eu tiver. Se rodarmos um processo para cada core, sem saber quantos cores temos, precisamos apenas passar o parâmetro max para o valor instances.

{
   ...
   instances: "max",
   ...
}

Vamos descobrir quantos cores eu tenho nessa máquina.

8 CORES! Nossa!!! Eu vou instalar Subnautica na minha máquina da Microsoft. Não diga a eles que eu disse isso.

A parte coisa sobre rodar processos em CPUs separadas é que, se você tiver um processo que perca o controle e tome 100% da CPU, os outros ainda funcionarão. Se você passar mais instâncias do que cores, o pm2 dobrará o número de processos em uma CPUs conforme for necessário.

Você pode fazer MUITO mais com o pm2, incluindo monitoramento e o tratamento daquelas variáveis de ambiente irritantes.

Um outro item a se observar: se, por alguma razão, você quiser executar seu script npm start, você pode fazer isso através do npm como processo e passar a bandeira -- start. O espaço antes de start (em português, "início") é super importante aqui.

pm2 start npm -- start

No Azure AppService, incluímos o pm2 por padrão em segundo plano. Se você quiser usar o pm2 no Azure, não precisa incluí-lo em seu arquivo package.json. Você somente precisa adicionar um arquivo de ecossistema e está pronto para continuar.

Certo! Agora que aprendemos tudo sobre o pm2, vamos falar um pouco mais sobre o porquê você pode querer não usá-lo. Também veremos que pode, de fato, não haver problema em rodar o Node diretamente.

Rodando o Node diretamente em produção

Eu tinha algumas dúvidas sobre isso. Então, falei com Tierney Cyren, que é uma parte enorme do círculo laranja de conhecimento, especialmente quando o assunto é o Node.

Tierney me apontou algumas desvantagens de se usar o Node baseado em gerenciadores de processos, como o pm2.

A principal delas é que você não deveria usar Node para monitorar a si mesmo. Você não quer usar a coisa que você está monitorando para monitorar a si mesma. Seria como pedir ao meu filho adolescente para tomar conta de si mesmo em uma sexta-feira à noite: isso acabaria mal? Pode ser que sim, pode ser que não, mas você não quer descobrir da pior maneira.

Tierney recomenda que você não tenha um gerenciador de processos do Node rodando em sua aplicação nunca. Ao invés disso, tenha algo em um nível mais alto que observe em conjunto as instâncias separadas de sua aplicação. Por exemplo, uma configuração ideal seria se você tivesse um agrupamento de Kubernetes com sua aplicação rodando em contêineres separados. O Kubernetes podem, então, monitorar aqueles contêineres e, se algum deles cair, pode trazê-lo de volta e registrar sua condição de integridade.

Nesse caso, você pode rodar o Node diretamente porque você o está monitorando um nível acima.

Acontece que o Azure já está fazendo isso. Se não subirmos um arquivo de ecossistema do pm2 para o Azure, a aplicação iniciará com nosso script start do nosso arquivo package.json e podemos, então, rodar diretamente o Node.

"scripts": {
  "start": "node index.js"
}

Nesse caso, estamos rodando diretamente o Node e não há problema. Se a aplicação quebrar, você notará que ela reinicializará. Isso acontece porque, no Azure, sua aplicação roda em um contêiner. O Azure está orquestrando o contêiner que sua aplicação está rodando e saberá quando ela tiver problemas.

Porém, você ainda tem apenas uma instância aqui. É necessário, ao contêiner, algum tempo para voltar a ficar on-line depois de quebrar, o que significa que, nesse tempo, sua aplicação estaria fora do ar para seus usuários.

Idealmente, você vai querer ter mais de um contêiner rodando. A solução para isso seria subir múltiplas instances de sua aplicação para múltiplos sites do Azure AppService e, então, usar o Azure Front Door para balancear a carga das aplicações por detrás de um único endereço de IP. O Front Door saberá quando um contêiner cair e roteará o tráfego para outras instâncias funcionais de sua aplicação.

Saiba mais sobre o serviço Azure Front Door aqui.

systemd

Outra sugestão que o Tierney nos dá é rodar o Node com systemd. Eu não entendo muito (na verdade, não entendo nada) sobre systemd e já estraguei tudo parafraseando ele uma vez. Então, vamos deixar Tierney isso dizer com suas próprias palavras…

Essa opção só é possível se você tiver acesso ao Linux na sua implementação (em inglês, deployment), e se você controlar o modo como o Node é inicializado em nível de serviço. Se você estiver rodando seu processo do Node.js em uma máquina virtual (em inglês, VM), Linux de longa duração, como as VMs do Azure, poderá rodar o Node.js com systemd sem problemas. Se você só estiver fazendo o deploy de seus arquivos para um serviço como o Azure AppService ou o Heroku ou rodando o Node dentro de um ambiente conteinerizado, como o Azure Container Instances, você provavelmente deverá evitar essa opção.

Rodando seu App Node.js com Systemd - Parte 1 (texto em inglês sobre o assunto)

Worker Threads do Node.js

Tierney também gostaria de informar que as Worker Threads estão chegando ao Node. Isso permitirá a você começar sua aplicação em múltiplos "trabalhadores" (em inglês, workers), evitando, desse modo, a necessidade de algo como o pm2. Talvez. Eu não sei. De fato, não li esse artigo.

Documentação d0 Node.js sobre Worker Threads

Seja um adulto

A última sugestão de Tierney era apenas para lidar com o erro e escrever alguns testes (como um adulto faria), mas quem tem tempo para isso, não é mesmo?

O pequeno círculo permanece

Agora você sabe a maior parte do que está no pequeno círculo azul. O restante tem a ver apenas com fatos inúteis sobre bandas e cerveja.

Para mais informações sobre o pm2, Node e Azure, confira os recursos a seguir:

• Site do PM2
• Implantação do Node.js com o VS Code

Em criptomoedas, uma chave privada permite aos usuários acessar suas carteiras. A pessoa que possui a chave privada controla completamente as moedas naquela carteira. Por essa razão, você deve mantê-la em segredo. Se você realmente quiser gerar sua própria chave, faz sentido que ela seja gerada de uma maneira segura.

Aqui, vou introduzir o assunto das chaves privadas e mostrar como você pode gerar sua própria chave usando várias funções criptográficas. Vou fornecer a descrição de um algoritmo e seu código em Python.

Eu preciso gerar uma chave privada?

Na maioria das vezes, não. Por exemplo, se você usar uma carteira web como a Coinbase ou Blockchain.info, elas criam e administram a chave privada para você. A mesma coisa acontece com as transações.

Carteiras de celulares e desktops também geram normalmente uma chave privada para você, embora elas também possam dar a opção de gerar sua própria chave.

Então, porque gerá-la mesmo assim? Aqui, eu cito alguns motivos meus:

• Você quer ter certeza de que ninguém sabe qual é a chave
• Você quer apenas aprender mais sobre criptografia e geração de números aleatórios (do inglês, random number generation, ou RNG)

O que exatamente é uma chave privada?

Formalmente, uma chave privada para Bitcoin (e muitas outras criptomoedas) é uma série de 32 bytes. Hoje em dia, existem muitas maneiras de gravar esses bytes. Eles podem ser gravados como uma sequência de caracteres (em inglês, string) de 256 zeros e uns (32 * 8 = 256) ou 100 jogadas de dados. Pode ser uma string binária, uma string de base 64, uma chave WIF (texto em inglês), uma frase mnemônica (texto em inglês) ou ainda uma string hexadecimal. Neste artigo, usaremos uma string hexadecimal de 64 caracteres.

Por que exatamente 32 bytes? Ótima pergunta! Para criar uma chave pública a partir de uma privada, Bitcoin usa o ECDSA, ou Algoritmo de Assinatura Digital de Curva Elíptica (em inglês, Elliptic Curve Digital Signature Algorithm). Mais especificamente, usa uma curva particular chamada secp256k1.

Essa curva tem um arranjo de 256 bits, tem uma entrada de 256 bits e uma saída contendo números de 256 bits. 256 bits são exatamente 32 bytes. Isso quer dizer que precisamos de 32 bytes de dados para alimentar esse algoritmo de curva.

Existe um requisito adicional para uma chave privada. Por usarmos ECDSA, a chave deve ser positiva e inferior ao arranjo da curva. O arranjo de secp256k1 é FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141, o que é relativamente grande: quase todo número de 32 bytes será menor que ele.

Modo iniciante

Então, como geramos um número de 32 bytes? A primeira coisa que nos vem à mente é usar uma biblioteca RNG na linguagem de sua escolha. Python até oferece uma maneira bonita de gerar esses números com apenas alguns bits necessários:

import random
bits = random.getrandbits(256)
# 30848827712021293731208415302456569301499384654877289245795786476741155372082
bits_hex = hex(bits)
# 0x4433d156e8c53bf5b50af07aa95a29436f29a94e0ccc5d58df8e57bdc8583c32
private_key = bits_hex[2:]
# 4433d156e8c53bf5b50af07aa95a29436f29a94e0ccc5d58df8e57bdc8583c32

Parece bom, mas na verdade não é. Bibliotecas RNG comuns não foram criadas para criptografia. Sendo assim, elas não são muito seguras. Elas geram números baseados em uma semente (em inglês seed), que por padrão, é a hora atual. Sendo assim, se você souber aproximadamente quando eu gerei os bits acima, tudo o que você precisa é tentar um ataque de força bruta com algumas variantes.

Quando você gera uma chave privada, deseja estar extremamente seguro. Lembre-se de que, se alguém souber a chave privada, poderá facilmente roubar todas as moedas da carteira correspondente. Você não terá chance nenhuma de recuperá-las de volta.

Então, vamos tentar uma maneira mais segura.

RNG criptograficamente forte

Junto com o método básico de RNG, linguagens de programação normalmente fornecem um RNG desenhado especificamente para operações criptográficas. Esse método é usualmente muito mais seguro, pois extrai entropia diretamente do sistema operacional. O resultado desse RNG é muito mais difícil de reproduzir. Você não pode obtê-lo apenas sabendo a hora que foi gerado ou sua seed, pois não há nenhuma seed. Bom, ao menos o usuário não insere nenhuma seed. Ela é criada pelo programa.

Em Python, um RNG criptograficamente forte é implementado pelo módulo secrets. Vamos modificar o código acima para tornar a geração da chave privada mais segura!

import secrets
bits = secrets.randbits(256)
# 46518555179467323509970270980993648640987722172281263586388328188640792550961
bits_hex = hex(bits)
# 0x66d891b5ed7f51e5044be6a7ebe4e2eae32b960f5aa0883f7cc0ce4fd6921e31
private_key = bits_hex[2:]
# 66d891b5ed7f51e5044be6a7ebe4e2eae32b960f5aa0883f7cc0ce4fd6921e31

Isso é incrível. Eu aposto que você não seria capaz de reproduzi-lo, mesmo com acesso ao meu PC. Podemos, no entanto, ir mais longe.

Sites especializados

Existem sites que geram esses números aleatórios para você. Vamos analisar apenas dois aqui. Um é o random.org, um gerador de números bem conhecido. Outro é o bitaddress.org, que é desenhado especificamente para geração de chaves privadas de Bitcoin.

O random.org poderianos ajudar a gerar uma chave? Com certeza, já que eles têm um serviço para geração de bytes aleatórios. Porém, dois problemas emergem aqui. O random.org afirma ser um gerador verdadeiramente aleatório, mas será que você pode confiar? Você consegue ter certeza que é, de fato, aleatório? Como ter certeza de que o proprietário não grava todos os resultados gerados, especialmente os que se parecem com chaves privadas? Essa resposta fica a seu critério. Ah, você também não pode executá-lo localmente, o que gera um problema adicional. Esse método, definitivamente, não é 100% seguro.

Já com o bitaddress.org, a história é completamente diferente. Ele é de código aberto (em inglês open source). Então, você pode checar o que há debaixo dos panos. É client-side, ou seja você pode fazer o download e executá-lo localmente, até mesmo sem conexão a internet.

Então, como funciona? Ele usa você – sim, você – como uma fonte de entropia. Ele pede que você mova seu mouse ou pressione teclas aleatórias. Você realiza esses passos até que seja inviável reproduzir os resultados.

Tem interesse em descobrir como o bitaddress.org funciona? Para fins educacionais, vamos dar uma olhada no seu código e tentar reproduzi-lo em Python.

Nota rápida: o bitaddress.org fornece a chave privada em formato de WIF comprimido, que é parecido ao formato WIF (texto em inglês) que discutimos previamente. Para nossos propósitos, faremos o algoritmo retornar uma string hexadecimal. Dessa maneira, poderemos usá-la mais tarde na geração de uma chave pública.

Bitaddress: as especificidades

O Bitaddress cria uma entropia em duas maneiras: pelo movimento do mouse e pelo pressionamento das teclas. Vamos falar sobre ambos, mas vamos focar no pressionamento das teclas, já que é difícil de implementar o rastreamento do mouse na biblioteca do Python. Esperaremos o usuário apertar teclas suficientes até que tenhamos entropia suficiente. Então, geraremos uma chave.

O Bitaddress faz três coisas. Ele inicializa um array de bytes, tentando obter o máximo de entropia possível de seu computador, preenche o array com inserções do usuário (em inglês, inputs) e, então, gera uma chave privada.

O Bitaddress usa o array de 256 bytes para guardar a entropia. Esse array é reescrito em ciclos. Então, quando o array é preenchido pela primeira vez, o ponteiro vai para zero e o processo de preenchimento começa de novo.

O programa inicia um array com 256 bytes a partir de window.crypto. Então, ele escreve um número representativo de um momento específico (nesse caso, a hora atual – em inglês, timestamp) para obter 4 bytes adicionais de entropia. Por fim, ele obtém dados como o tamanho da tela, seu fuso horário, informações sobre os plugins do seu navegador, sua localização e mais. Isso resulta em outros 6 bytes.

Depois da inicialização, o programa continuamente espera os inputs do usuário para reescrever os bytes iniciais. Quando o usuário move o cursor, o programa escreve a posição do cursor. Quando o usuário pressiona teclas, o programa escreve o código da tecla pressionada.

Finalmente, o bitaddress usa a entropia acumulada para gerar uma chave privada. É preciso gerar 32 bytes. Para essa tarefa, o bitaddress usa um algoritmo RNG chamado ARC4. O programa inicializa o ARC4 com a hora atual e a entropia coletada e, então, coleta os bytes um por um 32 vezes.

Isso tudo é uma simplificação de como o programa funciona, mas eu espero que tenha dado uma ideia de como ele é. Você pode checar o algoritmo completo e seus detalhes no Github.

Faça você mesmo

Para nossos propósitos, construiremos uma versão mais simples do bitaddress. Não vamos coletar dados sobre a localização e a máquina do usuário, somente inseriremos a entropia via texto, visto que é bem desafiador receber continuamente a posição do mouse em um script do Python (dê uma olhada em PyAutoGUI se tiver interesse em fazer isso).

Isso nos traz para especificação formal de nossa biblioteca geradora. Primeiro, vamos inicializar um array de byte com RNG criptográfico. Depois, preencheremos com a timestamp e, finalmente, preencheremos com os caracteres inseridos pelo usuário. Depois que o agrupamento de seeds for preenchido, a biblioteca deixará o desenvolvedor criar a chave. Na verdade, o desenvolvedor será capaz de criar quantas chaves privadas ele quiser – tudo seguro de acordo com a entropia coletada.

Inicializando o agrupamento

Aqui, colocamos alguns bytes de RNG criptográfico e uma timestamp. __seed_int e__seed_byte são dois métodos auxiliares que inserem entropia ao nosso array agrupador. Note que usamos a biblioteca secrets.

def __init_pool(self):
    for i in range(self.POOL_SIZE):
        random_byte = secrets.randbits(8)
        self.__seed_byte(random_byte)
    time_int = int(time.time())
    self.__seed_int(time_int)
def __seed_int(self, n):
    self.__seed_byte(n)
    self.__seed_byte(n >> 8)
    self.__seed_byte(n >> 16)
    self.__seed_byte(n >> 24)
def __seed_byte(self, n):
    self.pool[self.pool_pointer] ^= n & 255
    self.pool_pointer += 1
    if self.pool_pointer >= self.POOL_SIZE:
        self.pool_pointer = 0

Alimentando com input

Aqui, primeiro colocamos uma timestamp e, então, inserimos os caracteres, um a um.

def seed_input(self, str_input):
    time_int = int(time.time())
    self.__seed_int(time_int)
    for char in str_input:
        char_code = ord(char)
        self.__seed_byte(char_code)

Gerando a chave privada

Essa parte pode parecer difícil, mas, na verdade, é bem simples.

Primeiro, precisamos gerar um número de 32 bytes usando nosso agrupador. Infelizmente, não podemos apenas criar nosso próprio objeto random e usá-lo somente para a geração da chave. Ao invés disso, existe um objeto compartilhado que é usado por qualquer código que está sendo executado em um único script.

O que isso significa para nós? Significa que a cada momento, em qualquer lugar do código, um simples random.seed(0) pode destruir toda nossa entropia coletada. Não queremos isso. Por sorte, o Python nos dá os métodos getstate e setstate. Dessa maneira, para salvar nossa entropia cada vez que geramos uma chave, nós lembramos o estado onde paramos e o configuramos na próxima vez que necessitamos fazer uma chave.

Em segundo lugar, queremos ter certeza de que nossa chave está em uma variação específica (1, CURVE_ORDER). Isso é um requisito para todas chaves privadas ECDSA. O CURVE_ORDER é o arranjo da curva secp256k1, que é FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141.

Por fim, por conveniência, convertemos para hexadecimal e cortamos a parte '0x'.

def generate_key(self):
    big_int = self.__generate_big_int()
    big_int = big_int % (self.CURVE_ORDER — 1) # key < curve order
    big_int = big_int + 1 # key > 0
    key = hex(big_int)[2:]
    return key
def __generate_big_int(self):
    if self.prng_state is None:
    seed = int.from_bytes(self.pool, byteorder=’big’, signed=False)
    random.seed(seed)
    self.prng_state = random.getstate()
    random.setstate(self.prng_state)
    big_int = random.getrandbits(self.KEY_BYTES * 8)
    self.prng_state = random.getstate()
    return big_int

Em ação

Vamos tentar usar a biblioteca. Na verdade, é bem simples: você pode gerar uma chave privada em três linhas de código!

kg = KeyGenerator()
kg.seed_input(‘Uma frase completamente aleatória. Eu joguei um dado e obtive 4.’)
kg.generate_key()
# 60cf347dbc59d31c1358c8e5cf5e45b822ab85b79cb32a9f3d98184779a9efc2

Veja você mesmo. A chave é aleatória e totalmente válida. Além disso, cada vez que você rodar o código, obterá um resultado diferente.

Conclusão

Como pudemos ver, existem muitas maneiras de se gerar uma chave privada. Elas diferem em simplicidade e segurança.

Gerar uma chave privada é apenas o primeiro passo. O próximo passo é extrair uma chave pública e uma carteira que será usada para receber seus pagamentos. O processo de gerar uma carteira difere um pouco para Bitcoin e Ethereum. Eu planejo escrever outros dois artigos explorando mais esse tópico.

Se você quiser brincar com o código, ele está nesse repositório do Github.

O autor também trabalhou em um curso de criptomoedas. A primeira parte (texto em inglês) é uma descrição detalhada de blockchain.

Ele também publica pensamentos aleatórios sobre criptografia e criptomoedas no Twitter. Talvez você queira conferir.

Quando eu comecei aprender a testar minhas aplicações antigamente, fiquei muito frustrado com os diferentes tipos, estilos e tecnologias usadas para fazer testes, junto com os inúmeros posts espalhados pelos blogs, tutoriais e artigos. Eu penso que isso é verdade, também, para testagem em React.

Então, eu decidi escrever um guia completo de testagem em React em um só artigo.

Você poderia me perguntar: "Guia completo? Então, você vai cobrir todas as possibilidades e cenários de teste?" A resposta é: claro, que não! Porém, será um guia completo de fundamentos para testar e será o suficiente para construir a maioria para os outros casos extremos.

Também selecionei uma grande coleção de publicações em blogs, artigos e tutoriais para uma seção de leitura complementar ao final que deve dar a você conhecimento suficiente para entrar no top 10% de desenvolvedores em termos de testagem.

Você pode encontrar o projeto completo aqui:

https://github.com/iqbal125/react-hooks-testing-complete

Tabela de conteúdos

Teoria

• O que é a testagem?
• Por que testar?
• O que testar?
• O que não testar?
• Como testar
• Testes com shallow x testes com mount
• Testes unitários x testes de integração x testes de ponta a ponta

Informações preliminares

• Algumas informações extras

Enzyme

• Configuração do Enzyme
• react-test-renderer
• Testes de snapshot
• Implementação dos detalhes da testagem

Biblioteca de testagem no React

• useState e props
• useReducer()
• useContext()
• Componentes de formulário controlados
• useEffect() e requisições para a API do Axios

Cypress

• Uma testagem completa de ponta a ponta

Integração contínua

• Travis.yml
• Cobertura de código com coveralls

Teoria

O que é testagem?

Vamos começar pelo início e discutir o que é testagem. Testagem é um processo de três passos que se parece assim:

Organização é o estado original em que se encontra sua aplicação. Ação é alguma coisa acontece (como um evento de clique, entrada de usuário e assim por diante). Então, ocorre a declaração, ou é criada uma hipótese, sobre o novo estado da aplicação. Os testes passarão se a hipótese estiver correta e falharão se estiver errada.

Ao contrário dos componentes do React, os testes não são executados no navegador. Jest é o executor de testes e, também, o framework utilizado pelo React. O Jest é o ambiente onde todos os seus testes serão executados. É por isso que você não precisa importar expect e describe dentro desse arquivo. Essas funções já estão disponíveis globalmente no ambiente do Jest.

A sintaxe dos testes terá a seguinte aparência:

describe('Teste de soma', () => {
    function sum(a, b) {
       return a + b;
    }

    it('deve ser igual a 4',()=>{
       expect(sum(2,2)).toBe(4);
      })

    test('também deve ser igual a 4', () => {
        expect(sum(2,2)).toBe(4);
      }) 
});

describe envolve nossos blocos it ou test. É uma maneira de agrupá-los. Tanto it quanto test são palavras-chaves que podem ser usadas intercambiadas. O texto entre aspas descreverá algo que deveria acontecer com os testes e que será impressa no console. toBe() é um combinador que funciona com expectativas que permitem fazer declarações. Existem mais combinadores e variáveis globais oferecidas pelo Jest. Clique nos links abaixo para ver uma lista completa.

https://jestjs.io/pt-BR/docs/using-matchers

https://jestjs.io/pt-BR/docs/api

Por que testar?

A testagem é feita para garantir que sua aplicação está funcionando como foi planejada para seus usuários finais. Ter uma testagem fará com que sua aplicação fique mais robusta e menos propensa a erros. É uma maneira de verificar que seu código está fazendo o que os desenvolvedores projetaram.

Potenciais desvantagens:

• Escrever testes consome muito tempo e é difícil
• Em certos cenários, executar testes em Integração Contínua (em inglês, Continuous Integration, ou CI) pode ter um custo em dinheiro.
• Se feito incorretamente, pode gerar falsos positivos. Os testes passarão, mas a aplicação não funcionará como se espera.
• Pode gerar falsos negativos. Os testes falharão, mas a aplicação funcionará como pretendida.

O que testar?

Ao construí-los cobrindo o último estado da aplicação, os testes devem testar a funcionalidade da aplicação, simulando como ele será utilizado pelos usuários finais. Isso dará a você a confiança de que a aplicação funcionará como projetado em ambiente de produção. Naturalmente, entraremos em muito mais detalhes durante este artigo, mas essa é a essência básica.

O que não testar?

Eu gosto da filosofia de Kent C. Dodds, que diz que você não deve testar detalhes da implementação.

Detalhes da implementação representam testar coisas que não são funcionalidades do usuário final. Veremos um exemplo disso na seção do Enzyme mais adiante.

Parece que você está testando funcionalidades, mas, na verdade, não está. Você está testando o nome da função. Você pode alterar o nome da função e seus testes falharão, mas sua aplicação continuará funcionando, dando a você um falso negativo.

Preocupar-se constantemente com nomes de funções e variáveis é uma dor de cabeça. Ter que reescrever testes toda vez que você muda os nomes é tedioso. Então, mostrarei aqui uma abordagem melhor.

Variáveis const: essas variáveis são imutáveis. Você não tem a necessidade de testá-las.

Bibliotecas externas: não é seu trabalho testá-las. Quem precisa fazer isso são os criadores delas. Se você não tem certeza se a biblioteca foi testada, você não deve usá-la ou deve ler o código-fonte para ver se o autor incluiu testes. Você também pode fazer o download do código-fonte e rodar os testes você mesmo. Uma alternativa é perguntar ao autor se a biblioteca está pronta para produção ou não.

Minha abordagem pessoal para a testagem

Muito de minha abordagem pessoal de testagem é baseada nos ensinamentos de Kent C. Dodds. Então, você perceberá um pouco das falas de Kent ecoadas aqui, juntamente com algumas ideias minhas.

Muitos testes de integração, nenhum teste de snapshot, poucos testes unitários e poucos testes de ponta a ponta.

Testes unitários são um passo acima do teste de snapshot, mas não são ideais. Eles são, no entanto, muito mais fáceis de compreender e de se fazer sua manutenção do que os testes de snapshot.

Escreva, em sua maioria, testes de integração. Testes unitários são bons, mas eles não necessariamente se assemelham à maneira como o seu usuário final interage com a aplicação. É muito fácil testar detalhes de implementação com testes unitários, especialmente com a renderização superficial (em inglês, shallow render).

Testes de integração devem usar o mínimo de mocks (uma espécie de "dublê de teste"), se possível.

Não teste detalhes de implementação, como nomes de variáveis e funções.

Por exemplo, se você estiver testando um botão e muda o nome da função no método onClick de increment() para handleClick(), os testes quebrarão, mas o componente permanecerá funcionando. Essa não é uma boa prática, pois estamos basicamente testando o nome da função, que é um detalhe da implementação com o qual nosso usuário final não se importa.

Testes com shallow x testes com mount

Testes com mount(), de fato, executam o código html, css e js como um navegador faria, mas de maneira simulada. Eles não renderizam ou imprimem nada na interface, mas agem como um navegador da web simulado e executam o código em segundo plano.

Não perder tempo imprimindo nada na interface torna os testes muito mais rápidos. No entanto, testes com mount() ainda são bem mais lentos que testes com shallow().

É por isso que você desmonta ou faz a limpeza do componente depois de cada teste. É quase como uma aplicação em funcionamento. Um teste acabará afetando o outro.

Testes com mount()/render() são tipicamente usados para testes de integração, enquanto testes com shallow() são usados para testes unitários.

Os testes com shallow() apenas imprimem um único componente, aquele que estamos testando. Por não renderizar componentes filhos, conseguimos testar nossos componentes em isolamento.

Por exemplo, considere esse componente filho e o componente pai.

import React from 'react';

const App = () => {
  return (
    <div> 
      <ComponenteFilho /> 
    </div> 
  )
}

const ComponenteFilho = () => {
  return (
    <div>
     <p> Componentes filhos </p>
    </div>
  )
}

Se usarmos o teste com shallow() de App.js, teremos algo como o que vemos abaixo. Observe que nenhum dos nós do DOM para o componente filho está presente. Por isso, usamos o termo shallow render (em português, renderização superficial).

<App>
  <div> 
    <ComponenteFilho /> 
  </div>
</App> 

Agora, podemos comparar isso com a montagem do componente:

<App>
  <div> 
    <ComponenteFilho> 
      <div>
       <p> Componentes filhos </p>
      </div>
    </ComponenteFilho>
   </div>
</App> 

O que temos acima é muito mais próximo do que veremos na aplicação no navegador. Por isso, dizemos que os testes com mount()/render() são superiores.

Testes unitários x testes de integração x testes de ponta a ponta

Teste unitário: teste de uma parte isolada da aplicação, normalmente feita em combinação com o teste com shallow(). Exemplo: um componente renderizado com props (propriedades) padrão.

Teste de integração: testa se as partes distintas funcionam ou se integram corretamente entre si. Normalmente, é feito na criação ou na renderização do componente. Exemplo: teste se um componente filho pode atualizar o state contextual no componente pai.

Teste de ponta a ponta: normalmente, é uma combinação de várias etapas, combinando testes unitários e testes de integração dentro de uma etapa maior, geralmente com pouco mock (simulação). Os testes são feitos em um navegador simulado e podem ocorrer ou não enquanto o teste de interface está rodando. Exemplo: testagem de um fluxo inteiro de autenticação.

Informações preliminares

react-testing-library: eu, pessoalmente, gosto de usar a biblioteca react-testing-library, mas, normalmente, usa-se a Enzyme. Mostrarei a você um exemplo com a Enzyme, pois é importante estar ciente do básico de Enzyme. Os outros exemplos serão com react-testing-library.

Perfil dos exemplos: nossos exemplos seguem um padrão. Eu, primeiramente, mostrarei o componente do React e, então, os testes para ele, com explicações detalhadas de cada um. Você também pode acompanhar através do repositório cujo link eu deixei no início deste artigo.

Configuração: eu também assumirei que você está usando o create-react-app com a configuração de teste padrão, com jest. Assim, eu vou pular as configurações manuais.

Sinon, mocha, chai: Muitas das configurações oferecidas pelo Sinon estão disponíveis por padrão com o Jest. Assim, você não precisa do Sinon. Mocha e Chai são uma substituição para o Jest. O Jest vem pré-configurado de início para trabalhar com sua aplicação. Desse modo, não faz sentido usar o Mocha ou o Chai.

Esquema de nomeação de componentes: meu esquema de nomeação para o componente é <TesteAlgo />, mas não significa que eles sejam componentes falsos. Eles são componentes do React normais. Esse é apenas o esquema de nomeação.

npm test e o modo jest watch: yarn test funcionou para mim. npm test não funcionou corretamente com o modo jest watch.

Teste com um único arquivo: yarn test nome_do_arquivo

Hooks x classes no React: eu uso componentes com hooks do React para a maioria dos exemplos, mas, devido ao poder da react-testing-library, todos esses testes funcionarão com componentes de classes também.

Com essas informações preliminares, podemos partir para a escrita do código.

Enzyme

Configurando o Enzyme

Nossas bibliotecas externas

npm install enzyme enzyme-to-json  enzyme-adapter-react-16

Primeiro, vamos começar fazendo as importações

import React from 'react';
import ReactDOM from 'react-dom';
import Basic from '../basic_test';

import Enzyme, { shallow, render, mount } from 'enzyme';
import toJson from 'enzyme-to-json';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() })

Vamos começar nossas importações básicas. As três primeiras são para o React e para o nosso componente.

Depois, importamos o Enzyme. Em seguida, importamos a função toJson da biblioteca 'enzyme-to-json'. Vamos precisar converter nosso componente para teste com shallow() em JSON, que poderá ser salvo no arquivo do snapshot.

Finalmente, importamos nosso Adapter para fazer o Enzyme funcionar com o React 16 e o inicializamos como é mostrado abaixo.

react-test-renderer

O React, de fato, vem com seu próprio renderizador de testes. Você pode usá-lo ao invés do Enzyme se quiser. Sua sintaxe se parece com a do exemplo abaixo:

// import TestRenderer from 'react-test-renderer';
// import ShallowRenderer from 'react-test-renderer/shallow';


// Teste básico com react-test-renderer
// it('renderiza corretamente o react-test-renderer', () => {
//   const renderer = new ShallowRenderer();
//   renderer.render(<Basic />);
//   const result = renderer.getRenderOutput();
//
//   expect(result).toMatchSnapshot();
// });

Porém, até mesmo a documentação do próprio react-test-render sugere usar o Enzyme devido à sua sintaxe um pouco melhor e por ele fazer a mesma coisa. É bom ter isso em mente.

Teste de snapshot

Agora o nosso primeiro teste, um teste de snapshot.

it('renderiza corretamente o Enzyme', () => {
  const wrapper = shallow(<Basic />)

  expect(toJson(wrapper)).toMatchSnapshot();
});

Se você nunca rodou esse comando antes, um diretório __snapshots__  e um arquivo test.js.snap serão criados para você automaticamente. Em cada teste subsequente, o novo arquivo de snapshot será comparado com o arquivo de snapshot já existente. O teste passará se o snapshot não tiver alterações e falhará se elas existirem.

Então, essencialmente, o teste de snapshot permite você ver como seu componente se alterou desde o último teste, linha por linha. As linhas de código que sofreram mudanças são conhecidas como diff, abreviação em inglês para diferenças.

Aqui está o componente básico em que realizamos o teste:

import React from 'react';


const Basic = () => {
  return (
    <div >
      <h1> Basic Test </h1>
         <p> This is a basic Test Component </p>
    </div>
  );
}

export default Basic;

Rodar o teste acima gerará um arquivo que contém um código parecido com o que é mostrado abaixo. Essa é, essencialmente, nossa árvore de nós do React DOM.

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

exports[`renderiza corretamente o enzyme 1`] = `
<div>
  <h1>
     Basic Test
  </h1>
  <p>
     This is a basic Test Component
  </p>
</div>
`;

Isso produzirá uma estrutura de diretórios como a mostrada abaixo:

Seu terminal gerará um resultado parecido com este:

Entretanto, o que acontece se mudarmos nosso componente básico para isso:

import React from 'react';


const Basic = () => {
  return (
    <div >
      <h1> Basic Test </h1>

    </div>
  );
}

export default Basic;

Nosso snapshot falhará.

Ele também nos mostrará a diferença.

Assim como no git, o sinal " - " antes de cada linha significa que ela foi removida.

Nós precisamos apenas apertar "w" para ativar o modo de observação (do inglês, watch) e, então, pressionar a tecla "u" (do inglês, update) para atualizar o snapshot.

Nosso arquivo de snapshot será atualizado automaticamente com o novo snapshot e passará nos testes.

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

exports[`renderiza corretamente o Enzyme 1`] = `
<div>
  <h1>
     Basic Test
  </h1>
</div>
`;

Isso é tudo que temos para os testes de snapshot, mas, se você ler a seção onde exponho minhas opiniões, perceberá que eu não faço o teste de snapshot. Eu o incluí aqui porque, assim como o Enzyme, eles são bem comuns e são algo que você deveria conhecer, mas explicarei abaixo por que eu não o uso.

Vamos olhar novamente o que é o teste de snapshot. Ele essencialmente permitirá que você veja como o seu componente mudou desde o último teste. Os benefícios disso são:

• É bem rápido e fácil de implementar e, algumas vezes, requer somente algumas linhas de código.
• Você pode ver se seu componente está renderizando corretamente e ver os nós do DOM claramente com a função .debug().

Desvantagens e argumentos contra os testes de snapshot:

• A única coisa que o teste de snapshot faz é dizer a você onde a sintaxe do seu código sofreu alterações desde o último teste.
• Então, isso é realmente um teste? Alguns diriam que não muito.
• Renderizar o app corretamente é um trabalho do React. Desse modo, você estaria indo um pouco na direção de testar uma biblioteca de terceiros.
• Comparar diffs é algo que pode ser feito com o controle de versões do git. Isso não deveria ser um trabalho do teste de snapshot.
• Um teste que falhou, aqui, não significa que sua aplicação não está funcionando como pretendido. Significa apenas que o seu código sofreu mudanças desde a última vez em que você rodou o teste. Isso poderia levar à vários falsos negativos e gerar uma falha na confiança na testagem. Isso também poderia levar pessoas a apenas atualizar os testes sem observá-los atentamente.
• Testes de snapshot também dizem se sua sintaxe do JSX está correta. Porém, novamente, isso pode ser feito facilmente em um ambiente de desenvolvimento. Rodar um teste de snapshot apenas para verificar erros de sintaxe não faz nenhum sentido.
• Pode ser bem difícil de se entender o que está acontecendo em um teste de snapshot, visto que a maioria das pessoas o usam com o teste com shallow(), que não renderiza componentes filhos. Então, ela não dá ao desenvolvedor nenhuma percepção do que está acontecendo realmente.

Veja a seção de leitura complementar para mais informações.

Detalhes de implementação de testes com Enzyme

Aqui eu vou dar a você um exemplo do motivo de não testar detalhes de implementação. Vamos dizer que temos um simples componente contador, como o que mostramos abaixo:

import React, { Component } from 'react';


class Counter extends Component {
  constructor(props) {
    super(props)

    this.state = {
      count: 0
    }
  }

  increment = () => {
    this.setState({count: this.state.count + 1})
  }

  // Este código incorreto ainda fará com que os testes passem
  // <button onClick={this.incremen}>
  //   Clicked: {this.state.count}
  // </button>

  render() {
    return (
      <div>
        <button className="counter-button" onClick={this.incremen}>
          Clicked: {this.state.count}
        </button>
      </div>
  )}
}

export default Counter;

Você notará que eu fiz um comentário sugerindo que um aplicativo não funcional, ainda assim, passaria nos testes. Como exemplo, podemos escrever incorretamente o nome da função no evento onClick.

Vamos ver abaixo nos testes por que isso acontece.

import React from 'react';
import ReactDOM from 'react-dom';
import Counter from '../counter';

import Enzyme, { shallow, render, mount } from 'enzyme';
import toJson from 'enzyme-to-json';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() })

// A atribuição de função incorreta no método onClick 
// ainda fará os testes passarem.

test('o método increment incrementa a contagem', () => {
  const wrapper = mount(<Counter />)

  expect(wrapper.instance().state.count).toBe(0)

  // wrapper.find('button.counter-button').simulate('click')
  // wrapper.setState({count: 1})
  wrapper.instance().increment()
  expect(wrapper.instance().state.count).toBe(1)
})

Rodar o código acima passará nos testes, assim como usar 0 wrapper.setState(). Então, temos testes passando em uma aplicação não funcional. Eu não sei você, mas isso não me transmite a confiança de que nossa aplicação funcionará como pretendido para os nossos usuários finais.

Simular a ação de clique no botão não passará nos testes, mas isso pode gerar um problema oposto: um falso negativo. Vamos dizer que nós queremos aplicar mudanças no estilo do botão, declarando uma nova classe CSS nele – uma situação bem comum. Nossos testes falharão, pois não conseguiremos mais achar o botão. Nossa aplicação, no entanto, continuará funcionando, o que nos dará um falso negativo. Isso também acontece sempre que mudarmos os nomes de nossas funções ou o estado das variáveis.

Sempre que nós quisermos mudar nossas funções e nomes das classes do CSS, teremos que reescrever nossos testes, um processo bem ineficiente e tedioso.

Então, o que podemos fazer para resolver?

react-testing-library

useState

Observando a documentação da biblioteca react-testing-library, podemos perceber que o princípio orientador mais importante é:

Quanto mais seus testes se assemelharem à maneira como seu software é usado, mais confiança você terá (de que sua aplicação funciona adequadamente).

Vamos manter esse princípio orientador em mente conforme seguimos com nossos testes.

Vamos começar com um componente básico de hooks do React e testar seu state e suas propriedades (do inglês, props).

import React, { useState } from 'react';


const TestHook = (props) => {
  const [state, setState] = useState("Initial State")

  const changeState = () => {
    setState("Initial State Changed")
  }

  const changeNameToSteve = () => {
    props.changeName()
  }

  return (
  <div>
    <button onClick={changeState}>
      State Change Button
    </button>
    <p>{state}</p>
    <button onClick={changeNameToSteve}>
       Change Name
    </button>
    <p>{props.name}</p>
  </div>
  )
}


export default TestHook;

Nossas props estão vindo do componente pai

  const App = () => {
      const [state, setState] = useState("Some Text")
      const [name, setName] = useState("Moe")
  ...
      const changeName = () => {
        setName("Steve")
      }

      return (
        <div className="App">
         <Basic />
        <h1> Counter </h1>
         <Counter />
        <h1> Basic Hook useState </h1>
         <TestHook name={name} changeName={changeName}/>
    ...     

Então, mantendo nosso princípio orientador em mente, como os nossos testes ficarão?

A maneira que nosso usuário final usará essa aplicação será: ver algum texto na UI, ver o texto no botão, clicar e finalmente ver um outro texto na UI.

É assim que nós escrevemos nossos testes usando a biblioteca de testes do React.

Use este comando para instalar a biblioteca react-testing-library:

npm install @testing-library/react

Não use este comando:

npm install react-testing-library

Agora, vamos aos testes.

import React from 'react';
import ReactDOM from 'react-dom';
import TestHook from '../test_hook.js';
import {render, fireEvent, cleanup} from '@testing-library/react';
import App from '../../../App'

afterEach(cleanup)

it('Texto no state se altera quando o botão é clicado', () => {
    const { getByText } = render(<TestHook />);

    expect(getByText(/inicial/i).textContent).toBe("State inicial")

    fireEvent.click(getByText("Botão de mudança do state"))

    expect(getByText(/inicial/i).textContent).toBe("State inicial alterado")
 })


it('clique do botão altera as props', () => {
  const { getByText } = render(<App>
                                <TestHook />
                               </App>)

  expect(getByText(/Moe/i).textContent).toBe("Moe")

  fireEvent.click(getByText("Mudar nome"))

  expect(getByText(/Steve/i).textContent).toBe("Steve")
})

Começamos com nossas importações usuais.

Depois, temos a função afterEach(cleanup). Como não estamos usando o teste com shallow(), temos que fazer a desmontagem (em inglês, unmount), ou a limpeza depois de cada teste. É exatamente esse o papel dessa função.

getByText é o método da query que obtivemos desestruturando o valor da função de renderização. Existem muitos mais métodos de query, mas esse você usará a maior parte do tempo.

Para testar nosso state, perceba que nós não estamos nenhum nome de função ou de variável. Estamos mantendo nosso princípio orientador ao não testar detalhes de implementação. Como o usuário final verá o texto no botão da interface, é assim que buscaremos os nós do DOM. Nós também buscaremos o botão dessa maneira e clicaremos nele. Finalmente, buscaremos o estado final, também com base no texto.

(/Inicial/i) é uma expressão regular (do inglês, regex expression) que retorna o primeiro nó que contenha pelo menos o texto "inicial".

Também podemos fazer exatamente a mesma coisa com as props. Se as props forem mudadas em App.js, precisaremos renderizá-las junto com nosso componente. Assim como no exemplo anterior, não estamos testando nomes de função ou variáveis, mas fazemos isso do mesmo jeito que nosso usuário faria ao usar nossa aplicação, ou seja, através do texto que ele vê na interface.

Espero que isso dê a você uma boa ideia de como testar com react-testing-library e seu princípio orientador. Você, geralmente, vai querer usar getByText na maior parte do tempo. Existem poucas exceções e nós as veremos conforme seguimos com a explicação.

useReducer

Agora, nós podemos testar um componente com o hook useReducer. Neste caso, precisaremos de ações e reducers para trabalhar com nosso componente. Então, vamos configurá-los:

Nosso reducer

import * as ACTIONS from './actions'

export const initialState = {
    stateprop1: false,
}

export const Reducer1 = (state = initialState, action) => {
  switch(action.type) {
    case "SUCCESS":
      return {
        ...state,
        stateprop1: true,
      }
    case "FAILURE":
      return {
        ...state,
        stateprop1: false,
      }
    default:
      return state
  }
}

E as ações:

export const SUCCESS = {
  type: 'SUCCESS'
}

export const FAILURE = {
  type: 'FAILURE'
}

Manteremos as coisas simples e usaremos ações ao invés de criadores de ação.

Por fim, o componente usará essas ações e reducers:

import React, { useReducer } from 'react';
import * as ACTIONS from '../store/actions'
import * as Reducer from '../store/reducer'


const TestHookReducer = () => {
  const [reducerState, dispatch] = useReducer(Reducer.Reducer1, Reducer.initialState)

  const dispatchActionSuccess = () => {
    dispatch(ACTIONS.SUCCESS)
  }

  const dispatchActionFailure = () => {
    dispatch(ACTIONS.FAILURE)
  }


  return (
    <div>
       <div>
        {reducerState.stateprop1
           ? <p>stateprop1 is true</p>
           : <p>stateprop1 is false</p>}
       </div>
       <button onClick={dispatchActionSuccess}>
         Dispatch Success
       </button>
    </div>
  )
}


export default TestHookReducer;

Esse é um simples componente que mudará o stateprop1 de falso para verdadeiro ao disparar uma ação de SUCCESS.

Agora, vamos ao nosso teste.

import React from 'react';
import ReactDOM from 'react-dom';
import TestHookReducer from '../test_hook_reducer.js';
import {render, fireEvent, cleanup} from '@testing-library/react';
import * as Reducer from '../../store/reducer';
import * as ACTIONS from '../../store/actions';


afterEach(cleanup)

describe('testar o reducer e as ações', () => {
  it('deve retornar ao state inicial', () => {
    expect(Reducer.initialState).toEqual({ stateprop1: false })
  })

  it('deve alterar stateprop1 de false para true', () => {
    expect(Reducer.Reducer1(Reducer.initialState, ACTIONS.SUCCESS ))
      .toEqual({ stateprop1: true  })
  })
})

it('O reducer altera stateprop1 de false para true', () => {
   const { container, getByText } = render(<TestHookReducer />);

   expect(getByText(/stateprop1 is/i).textContent).toBe("stateprop1 is false")

   fireEvent.click(getByText("Dispatch Success"))

   expect(getByText(/stateprop1 is/i).textContent).toBe("stateprop1 is true")
})

Primeiro, começamos testando nosso reducer e dividimos os testes para o reducer no bloco describe. Esses são testes bem básicos. Estamos usando esses testes para ter certeza de que o state inicial é o que queremos e que as ações produzem o resultado que queremos.

Você pode argumentar que a testagem do reducer é um teste de detalhe de implementação, mas o que eu encontrei na prática foi que a testagem das ações e dos reducers são testes unitários que são sempre necessários.

Esse é um exemplo simples. Então, ele não parece um grande desafio agora, mas, em grandes projetos e aplicações, não fazer a testagem de reducers e ações pode ter consequências desastrosas. Então, ações e reducers seriam uma exceção para a regra sobre não testar detalhes de implementação.

Agora, temos nossos testes para o componente em si. Observe, novamente, que, aqui, não estamos testando detalhes de implementação. Estamos usando o mesmo padrão do exemplo anterior useState, obtendo nossos nós do DOM por texto, além de encontrando e clicando no botão com o texto.

useContext

Agora vamos seguir em frente e testar se um componente filho pode atualizar o state do contexto em um componente pai. Isso pode parecer complexo, mas é bem simples e direto.

Primeiro, precisamos do nosso objeto de contexto, onde inicializaremos nosso próprio arquivo.

import React from 'react';

const Context = React.createContext()

export default Context

Também precisamos atualizar nosso componente app pai, que manterá o provedor (do inglês, provider) de Context. O valor passado para o Provider será o valor do state, além da função setState do componente App.js.

import React, { useState } from 'react';
import TestHookContext from './components/react-testing-lib/test_hook_context';


import Context from './components/store/context';


const App = () => {
  const [state, setState] = useState("Um texto")
  

  const changeText = () => {
    setState("Outro texto")
  }


  return (
    <div className="App">
    <h1> Basic Hook useContext</h1>
     <Context.Provider value={{changeTextProp: changeText,
                               stateProp: state
                                 }} >
        <TestHookContext />
     </Context.Provider>
    </div>
  );
}

export default App;

E para o nosso componente

import React, { useContext } from 'react';

import Context from '../store/context';

const TestHookContext = () => {
  const context = useContext(Context)

  return (
    <div>
    <button onClick={context.changeTextProp}>
        Alterar texto
    </button>
      <p>{context.stateProp}</p>
    </div>
  )
}


export default TestHookContext;

Temos um componente simples, que mostra o texto inicializado em App.js e passamos a função setState para o método onClick.

Observação: o state mudou, inicializado e contido em nosso componente App.js. Simplesmente passamos o valor do state e a função setState para nosso componente filho através do contexto, mas o state foi controlado no componente App.js. Isso será importante para entender nosso teste.

Aqui está o nosso teste:

import React from 'react';
import ReactDOM from 'react-dom';
import TestHookContext from '../test_hook_context.js';
import {act, render, fireEvent, cleanup} from '@testing-library/react';
import App from '../../../App'

import Context from '../../store/context';

afterEach(cleanup)

it('Context value is updated by child component', () => {

   const { container, getByText } = render(<App>
                                            <Context.Provider>
                                             <TestHookContext />
                                            </Context.Provider>
                                           </App>);

   expect(getByText(/Some/i).textContent).toBe("Um texto")

   fireEvent.click(getByText("Alterar texto"))

   expect(getByText(/Some/i).textContent).toBe("Outro texto")
})

Até para o nosso contexto, você pode perceber que não quebramos o nosso padrão de testes. Ainda encontramos e simulamos nossos eventos com os testes.

Fiz a inclusão do <Context.Provider/> e do componente <TestHookContext /> na função de renderização, pois faz com que o código fique mais legível, mas não precisamos deles necessariamente. Nosso teste funcionará se passarmos apenas o componente <App /> para a função de renderização.

const { container, getByText } = render(<App/>) 

Por que esse é o caso?

Vamos pensar de novo no que sabemos sobre o contexto. Todo o state do contexto é controlado em App.js. Por essa razão, é o nosso componente principal que estamos testando realmente, mesmo que pareça que estamos testando o componente filho que usa o hook useContext. Esse código também funciona por causa da criação/montagem do componente (em inglês, mount/render). Como sabemos, no teste com shallow(), os componentes filhos não são renderizados, somente na criação. Sabendo que <Context.Provider /> e <TestHookContext /> são ambos componentes filhos de <App />, eles serão renderizados automaticamente.

Componentes de formulários controlados

Um componente de formulário controlado basicamente significa que o formulário trabalhará através do state do React ao invés do formulário manter seu próprio state. Desse modo, o método onChange salvará o texto do input no React em cada toque no teclado.

Testar o formulário será um pouco diferente do que temos visto até agora, mas vamos tentar manter os nossos princípios guias em mente.

import React, { useState } from 'react';

const HooksForm1 = () => {
  const [valueChange, setValueChange] = useState('')
  const [valueSubmit, setValueSubmit] = useState('')

  const handleChange = (event) => (
    setValueChange(event.target.value)
  );

  const handleSubmit = (event) => {
    event.preventDefault();
    setValueSubmit(event.target.text1.value)
  };

    return (
      <div>
       <h1> Formulário de hooks do React </h1>
        <form data-testid="form" onSubmit={handleSubmit}>
          <label htmlFor="text1">Texto de entrada:</label>
          <input id="text1" onChange={handleChange} type="text" />
          <button type="submit">Enviar</button>
        </form>
        <h3>React State:</h3>
          <p>Alterar: {valueChange}</p>
          <p>Valor de envio: {valueSubmit}</p>
        <br />
      </div>
    )
}


export default HooksForm1;

Temos aqui um formulário básico. Vamos mostrar o valor da mudança e enviar o valor em nosso JSX. Temos o atributo data-testid="form", que usaremos no nosso teste da query para o formulário.

Nossos testes:

import React from 'react';
import ReactDOM from 'react-dom';
import HooksForm1 from '../test_hook_form.js';
import {render, fireEvent, cleanup} from '@testing-library/react';

afterEach(cleanup)

//Teste de um formulário de componente controlado.
it('Inserir texto atualiza o state', () => {
    const { getByText, getByLabelText } = render(<HooksForm1 />);

    expect(getByText(/Change/i).textContent).toBe("Alterar: ")

    fireEvent.change(getByLabelText("Texto de entrada:"), {target: {value: 'Text' } } )

    expect(getByText(/Change/i).textContent).not.toBe("Alterar: ")
 })


 it('O envio do formulário funciona corretamente', () => {
     const { getByTestId, getByText } = render(<HooksForm1 />);

     expect(getByText(/Submit Value/i).textContent).toBe("Valor de envio: ")

     fireEvent.submit(getByTestId("form"), {target: {text1: {value: 'Texto' } } })

     expect(getByText(/Submit Value/i).textContent).not.toBe("Valor de envio: ")
  })

Considerando que um elemento de input vazio não possui texto, usaremos a função getByLabelText() para obter o nó do input. Ainda manteremos nosso princípio guia, visto que o texto da label é o que o usuário lerá antes de digitar o texto.

Note que disparará o evento .change() ao invés do evento usual, .click(). Também passaremos um dado teste como exemplificado abaixo:

{ target: { value: "Texto" } }

Considerando que o valor do formulário será acessado na forma de event.target.value, é assim que simularemos o evento.

Geralmente, não sabemos qual texto o usuário enviará, então podemos simplesmente usar a palavra-chave .not para ter certeza de que o texto mudou ou renderizou o método.

Podemos testar o envio do formulário de modo similar. A única diferença é que usamos o evento .submit() e passamos dados de teste dessa maneira:

{ target: { text1: { value: 'Texto' } } }

É assim que acessamos dados do formulário através do evento sintético quando um usuário o submeter, onde text1 é o id de nosso elemento input. Temos que fugir um pouco do nosso padrão aqui e usar o atributo data-testid="form" para buscar o formulário, visto que não há outro modo de fazê-lo.

É isso que temos para o formulário. Não é tão diferente de outros exemplos já feitos por nós anteriormente. Se você achar que já entendeu tudo, podemos seguir para algo um pouco mais complexo.

useEffect e requisições a APIs com o axios

Agora, vamos ver como testaríamos o hook useEffect e as requisições a APIs. Isso será um pouco diferente do que temos visto até agora.

Digamos que temos um url passado de um componente pai para um filho.

...

     <TestAxios url='https://jsonplaceholder.typicode.com/posts/1' />
     
 ... 

O componente seria algo assim:

import React, { useState, useEffect } from 'react';
import axios from 'axios';


const TestAxios = (props) => {
  const [state, setState] = useState()

  useEffect(() => {
    axios.get(props.url)
      .then(res => setState(res.data))
  }, [])


  return (
    <div>
    <h1> Teste do axios </h1>
        {state
          ? <p data-testid="title">{state.title}</p>
          : <p>...Carregando</p>}
    </div>
  )
}


export default TestAxios;

Simplesmente fazemos uma requisição a uma API e salvamos os resultados em um state local. Também usamos uma expressão ternária no nosso método de renderização para esperar até que a requisição esteja completa. Assim, mostrarmos o título do json como placeholder.

Você notará que, novamente, por necessidade, teremos que usar o atributo data-testid. Novamente, é um detalhe de implementação, já que o usuário não verá nem vai interagir com esse atributo de nenhuma maneira, mas, aqui, é mais realista, uma vez que, geralmente, não saberemos o texto vindo da requisição de antemão.

Usaremos dados mockados (de simulação) nesse teste.

Um mock é uma maneira de simular um comportamento que não queremos que aconteça em nossos testes. Por exemplo, fazemos o mock das requisições à API porque não queremos fazer requisições reais em nossos testes.

Não queremos requisições reais em nossos testes por diversas razões: farão com que nossos testes fiquem mais lentos, podem nos dar um falso negativo, as requisições à API podem nos custar dinheiro ou podemos alterar nosso banco de dados com os testes.

import React from 'react';
import ReactDOM from 'react-dom';
import TestAxios from '../test_axios.js';
import {act, render, fireEvent, cleanup, waitForElement} from '@testing-library/react';

import axiosMock from "axios";

Temos nossas importações usuais, mas você notará algo específico. Estamos importando axiosMock da biblioteca axios. Não estamos importando um objeto axios da biblioteca axios. Na verdade, estamos mockando (simulando) a biblioteca axios em si.

Como?

Usando a funcionalidade de mocking oferecida pelo Jest.

Primeiro, vamos fazer um diretório __mocks__ adjacente para testar nosso diretório teste. Seria algo assim:

Dentro do diretório de mocks, temos um arquivo axios.js. Essa é a nossa biblioteca axios falsa. Dentro de nossa biblioteca axios falsa, temos nossa função de mock do jest.

Funções de mock nos permitem usá-las em nosso ambiente do Jest sem ter que realmente implementar sua lógica.

Então, basicamente, não vamos implementar a lógica através de uma requisição do axios. Usaremos a função mock em vez disso.

export default {
  get: jest.fn(() => Promise.resolve({ data: {} }) )
};

Aqui, temos nossa função falsa get. Ela é uma função simples que, na verdade, é um objeto em JS. get é nossa chave e o valor é a função mock. Como em uma requisição a APIs do axios, resolvemos uma promise (em português, promessa). Não passaremos nenhum dado aqui. Faremos isso em nossa configuração dos testes.

Segue aqui a nossa configuração de testes:

//importações
...

afterEach(cleanup)

it('A solicitação assíncrona do axios funciona', async () => {
  axiosMock.get.mockResolvedValue({data: { title: 'some title' } })

  const url = 'https://jsonplaceholder.typicode.com/posts/1'
  const { getByText, getByTestId, rerender } = render(<TestAxios url={url} />);

  expect(getByText(/...Loading/i).textContent).toBe("...Carregando")

  const resolvedEl = await waitForElement(() => getByTestId("title"));

  expect((resolvedEl).textContent).toBe("some title")

  expect(axiosMock.get).toHaveBeenCalledTimes(1);
  expect(axiosMock.get).toHaveBeenCalledWith(url);
 })

A primeira coisa que fazemos em nosso teste é chamar nossa requisição get do axios e fazer o mock do valor resolvido com a função, ironicamente chamada de mockResolvedValue, provida pelo Jest. Essa função faz exatamente o que seu nome diz, ela resolve uma promise com o dado que passamos nela, simulando o que o axios faz.

Essa função tem que ser chamada antes da nossa função render(). Caso contrário, nosso teste não funcionará. Lembre-se de que estamos mockando a biblioteca axios em si. Quando nosso componente rodar o comando import axios from 'axios'; estará importando nossa biblioteca falsa do axios ao invés da verdadeira e essa biblioteca falsa será substituída em nosso componente toda vez que usarmos o axios.

A seguir, temos o nosso nó de texto "...Carregando", visto que ele é mostrado antes de a promise ser resolvida. Depois disso, temos uma função que ainda não vimos até agora, a função waitForElement(), que esperará até que a promise seja resolvida antes de seguir para a próxima afirmação.

Também note que as palavras-chave await e async são usadas do mesmo jeito que são usadas fora do ambiente de teste.

Uma vez resolvida, o nó do DOM terá o texto "some title", que é o dado passado para nossa biblioteca falsa do axios.

A seguir, temos a certeza de que a requisição foi chamada apenas uma vez e com o url certo. Mesmo que estejamos testando o url, não fazemos uma requisição à API com esse url.

Ficamos por aqui com nossas requisições à API com axios. Na próxima sessão, exploraremos um pouco de testes com o Cypress.

Cypress

Agora, vamos explorar um pouco o Cypress, que eu acredito ser o melhor framework para rodar testes de ponta a ponta. Nos afastaremos um pouco do Jest agora. Vamos trabalhar unicamente com o Cypress, que possui seu próprio ambiente e sintaxe de testes.

O Cypress é incrível e poderoso. De fato, ele é tão incrível e poderoso que podemos rodar todos os testes que já vimos até agora em apenas um bloco de código de teste e observar o Cypress rodar esses testes em tempo real em um simulador de navegador.

Muito legal, não é?

Eu penso que sim. De qualquer forma, antes de fazermos tudo isso, precisamos configurar o Cypress. Surpreendentemente, o Cypress pode ser instalado como um módulo normal do npm.

npm install cypress

Para ter acesso ao Cypress, você precisa rodar este comando no seu terminal.

node_modules/.bin/cypress open

Se escrever esse comando toda vez parecer muito incômodo, você pode adicioná-lo no seu arquivo package.json.

...

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "cypress": "node_modules/.bin/cypress open", 
    
   ...

Isso permite, então, que você abra o Cypress apenas usando o seguinte comando: npm run cypress.

Ao abrir o Cypress, você encontrará uma interface gráfica (em inglês, GUI, ou Graphic User Interface), que pode ter a aparência seguinte:

Para rodar os testes no Cypress, sua aplicação deverá estar rodando ao mesmo tempo, o que veremos em um segundo.

Rodar o comando cypress open dará a você uma configuração básica do Cypress e criará alguns arquivos e diretórios para você automaticamente. Um diretório será criado na raiz do seu projeto. Escreveremos nosso código no diretório integration.

Começaremos excluindo o diretório examples. Diferentemente do Jest, arquivos do Cypress tem como extensão .spec.js.  Por ser um teste de ponta a ponta, rodaremos no nosso arquivo App.js. Sua estrutura de diretórios, agora, deve se parecer com a da imagem abaixo:

Também configuramos um url base no arquivo cypress.json, como no exemplo abaixo:

{ "baseUrl": "http://localhost:3000" }

Agora, vamos ao nosso longo teste monolítico

import React from 'react';

describe ('Teste completo de ponta a ponta', () => {
  it('teste completo de ponta a ponta', () => {
    cy.visit('/')
    //teste de contador
    cy.contains("Clicked: 0")
      .click()
    cy.contains("Clicked: 1")
    // teste básico de hooks
    cy.contains("State inicial")
    cy.contains("Botão de alteração do state")
      .click()
    cy.contains("State inicial alterado")
    cy.contains("Moe")
    cy.contains("Alterar nome")
      .click()
    cy.contains("Steve")
    //teste de useReducer
    cy.contains('stateprop1 is false')
    cy.contains('Dispatch Success')
      .click()
    cy.contains('stateprop1 is true')
    //teste de useContext
    cy.contains("Um texto")
    cy.contains('Alterar texto')
      .click()
    cy.contains("Outro texto")
    //teste do formulário
    cy.get('#text1')
      .type('Novo texto {enter}')
    cy.contains("Alterara: Novo texto")
    cy.contains("Enviar valor: Novo texto")
    //teste de axios
    cy.request('https://jsonplaceholder.typicode.com/posts/1')
      .should(res => {
          expect(res.body).not.to.be.null
          cy.contains(res.body.title)
        })
  });
});

Como mencionado antes, estamos rodando todos os testes que já passamos em apenas um bloco de código. Separei cada sessão com um comentário para que fique mais fácil a visualização.

Nosso teste pode ser um pouco intimidador a princípio, mas a maioria dos testes individuais seguirão o mesmo padrão arranjo-ação-declaração.

cy.contains(Algum texto de innerHTML do nó do DOM)

cy.contains (texto do botão)
.click()

cy.contains(Texto atualizado de innerHTML do nó do DOM)

Considerando que esse é um teste de ponta a ponta, você não encontrará qualquer tipo de mock. Nossa aplicação será rodada na sua versão de desenvolvimento completa em um simulador de navegador com uma interface. Essa é a maneira de testagem mais próxima da realidade que podemos ter.

Ao contrário dos testes unitários e de integração, não precisamos explicitamente declarar algumas coisas. Isso acontece porque o Cypress tem alguns comandos embutidos em algumas declarações por padrão. Declarações padrão são exatamente como o nome as descreve. Elas são declaradas por padrão. Então, não há a necessidade de adicionar um combinador.

Declarações padrão do Cypress (documentação do Cypress, em inglês)

Os comandos são encadeados uns nos outros. Então, ordená-los é bem importante. Cada comando esperará até que o comando anterior esteja completo antes de rodar.

Mesmo nas testagens com Cypress, ainda manteremos nossa filosofia de não testar detalhes de implementação. Na prática, isso quer dizer que não usaremos classes de html/css, ids ou propriedades como seletores se pudermos. A única vez em que precisaremos usar ids é para obter acesso ao elemento de input.

Faremos uso do comando cy.contains(), que retornará um nó do DOM com um texto correspondente. O que nosso usuário final fará será ver o texto na interface e interagir com ele. Então, testar dessa maneira será nossa linha com nossos princípios-guia.

Como não estamos mockando nada, você perceberá que nossos testes serão bem simples. Isso é bom. Já que essa é uma aplicação rodando, nossos testes não terão nenhum valor artificial.

Em nossos testes com axios, faremos uma requisição de http real para nosso endpoint. Fazer uma requisição em um teste de ponta a ponta é bem comum. Então, verificaremos se o valor não é nulo. Depois disso, nos certificaremos de que nosso dado aparece na interface.

Se for feito corretamente, você verá que o cypress rodou com sucesso os testes no Chromium.

Integração contínua

Rastrear e rodar todos esses testes manualmente pode se tornar uma tarefa um pouco tediosa. Para resolver isso, temos a integração contínua (em inglês, Continuous Integration, ou CI), que é uma maneira de automatizar nossos testes continuamente.

Travis CI

Para deixar as coisas mais simples, usaremos o Travis CI para nossa integração contínua. Você deve ter em mente, porém, que existem configurações muito mais complexas para a integração contínua usando o Docker e o Jenkins.

Você precisará estar conectado a uma conta do Travis e a uma do Github. Por sorte, ambas são gratuitas.

Eu sugiro que você selecione a opção "Entrar com Github" no Travis CI.

Ao sincronizar sua conta, você pode ir até o ícone que leva até o seu perfil e clicar no botão de ativar/desativar, correspondente ao repositório no qual você quer ativar a CI.

Aqui, o Travis CI sabe do que você precisa para configurar um arquivo .travis.yml na raiz do seu projeto.

language: node_js

node_js: 
  - stable
  
  
install:
  - npm install

script:
  - npm run test
  - npm run coveralls

Isso, essencialmente, diz ao Travis que estamos usando o node_js. Faça o download de uma versão estável, instale as dependências e rode os comandos npm run test e npm run coveralls.

É isso. Você pode ir ao painel de controle e começar a build. O Travis rodará os testes automaticamente e entregará a você um resultado como o que vemos abaixo. Se seus testes passarem, você pode seguir em frente. Se falharem, sua build falhará e você precisará consertar o seu código e reiniciar a build.

Testes de cobertura

Os testes de cobertura nos dão um relatório que, basicamente, nos diz o quanto de nosso código está sendo testado.

Você precisará se registrar e sincronizar com sua conta do GitHub. Do mesmo modo que fizemos com o Travis CI, é necessário apenas que você vá para a aba Add Repo (Adicionar repositórios, em português) e ative o repositório que você também ativou no Travis CI.

Agora, vá em seu arquivo package.json e adicione a linha de código de coveralls:

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --coverage",
    "eject": "react-scripts eject",
    "cypress": "node_modules/.bin/cypress open", 
    "coveralls": "cat ./coverage/lcov.info | node node_modules/.bin/coveralls"
  },

Certifique-se de que a flag --coverage esteja adicionada ao comando react-scripts test. Isso é o que vai gerar os dados necessários de que o teste de cobertura precisará para gerar o relatório final.

Você pode, de fato, ver esses dados de cobertura no Travis CI depois que seus testes terminarem de rodar.

Considerando que não estamos lidando com um repositório privado nem com o Travis CI Pro, não precisamos nos preocupar com nenhum tipo de chave.

Uma vez concluído, você poderá adicionar uma insígnia (em inglês, badge) ao seu README, copiando o link gerado no dashboard.

O resultado será mais ou menos assim:

Conclusão

Você pode se considerar nos melhores 20% em termos de desenvolvedores com relação à testagem em React caso tenha conseguido acompanhar o tutorial até aqui.

Obrigado pela leitura, pessoal.

Siga o autor no Twitter para ver mais tutoriais escritos por ele.

Leitura complementar

Publicações em blogs (em inglês)

https://djangostars.com/blog/what-and-how-to-test-with-enzyme-and-jest-full-instruction-on-react-component-testing/

https://engineering.ezcater.com/the-case-against-react-snapshot-testing

https://medium.com/@tomgold_48918/why-i-stopped-using-snapshot-testing-with-jest-3279fe41ffb2

https://circleci.com/blog/continuously-testing-react-applications-with-jest-and-enzyme/

https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

https://willowtreeapps.com/ideas/best-practices-for-unit-testing-with-a-react-redux-approach

https://blog.pragmatists.com/genuine-guide-to-testing-react-redux-applications-6f3265c11f63

https://hacks.mozilla.org/2018/04/testing-strategies-for-react-and-redux/

https://codeburst.io/deliberate-practice-what-i-learned-from-reading-redux-mock-store-8d2d79a4b24d

https://www.robinwieruch.de/react-testing-tutorial/

https://medium.com/@ryandrewjohnson/unit-testing-components-using-reacts-new-context-api-4a5219f4b3fe

Textos de Kent C. Dodds sobre testes (em inglês)

https://kentcdodds.com/blog/introducing-the-react-testing-library

https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests

https://kentcdodds.com/blog/why-i-never-use-shallow-rendering

https://kentcdodds.com/blog/demystifying-testing

https://kentcdodds.com/blog/effective-snapshot-testing

https://kentcdodds.com/blog/testing-implementation-details

https://kentcdodds.com/blog/common-testing-mistakes

https://kentcdodds.com/blog/ui-testing-myths

https://kentcdodds.com/blog/why-youve-been-bad-about-testing

https://kentcdodds.com/blog/the-merits-of-mocking

https://kentcdodds.com/blog/how-to-know-what-to-test

https://kentcdodds.com/blog/avoid-the-test-user

Atalhos úteis/threads do GitHub (em inglês)

https://devhints.io/enzyme

https://devhints.io/jest

https://github.com/ReactTraining/react-router/tree/master/packages/react-router/modules/__tests__

https://github.com/airbnb/enzyme/issues/1938

https://gist.github.com/fokusferit/e4558d384e4e9cab95d04e5f35d4f913

https://airbnb.io/enzyme/docs/api/selector.html

Documentação

https://docs.cypress.io

https://airbnb.io/enzyme/

https://github.com/dmitry-zaets/redux-mock-store

https://jestjs.io/docs/en

https://testing-library.com/docs/learning

https://sinonjs.org/releases/v7.3.2/

https://redux.js.org/recipes/writing-tests

https://jestjs.io/docs/en/using-matchers

https://jestjs.io/docs/en/api

Hash tables são estruturas de dados que vão permitir que você crie uma lista de valores pareados. Você pode, então, recuperar determinado valor usando a respectiva chave para aquele valor, que você coloca na tabela de antemão.

Uma hash table transforma uma chave em um número inteiro, que serve como índice, usando uma função hash. Esse índice decidirá onde armazenar na memória o par chave/valor:

Você normalmente usará uma hash table por suas rápidas operações de busca, inserção e remoção:

Retirado da Wikipédia

Esse tutorial ajudará você a entender implementações de hash tables no JavaScript e também mostrará como você pode construir suas próprias classes de hash table.

Primeiramente, vamos dar uma olhada nas classes do JavaScript Object e Map.

Como usar hash tables com as classes Object e Map em JavaScript

O exemplo mais comum de uma hash table em JavaScript é a estrutura de dados Object, onde você pode parear duas propriedades de chave e valor.

No exemplo a seguir, a chave Nathan está pareada com o numero de telefone de valor "555-0182" e a chave Jane está pareada com o valor "315-0322":

let obj = {
  Nathan: "555-0182",
  Jane: "315-0322"
}

Porém, a estrutura de dados do tipo Object em JavaScript é um tipo especial de implementação de uma hash table por duas razões:

• Ela tem propriedades adicionadas pela classe Object. Chaves que você insere podem entrar em conflito e sobrescrever propriedades padrão já herdadas da classe.
• O tamanho de uma hash table não é monitorado. Você precisa contar manualmente quantas propriedades são definidas pelo programador ao invés de herdar do prototype.

Por exemplo, o prototype de Object  tem o método hasOwnProperty(), que sempre permitirá a você checar se uma propriedade não é herdada:

const obj = {};
obj.name = "Nathan";

console.log(obj.hasOwnProperty("name")); // true

O JavaScript não impede você de tentar sobrescrever o método hasOwnProperty(), o que pode causar um erro deste tipo:

const obj = {};
obj.name = "Nathan";
obj.hasOwnProperty = true;

console.log(obj.hasOwnProperty("name")); 
// Error: obj.hasOwnProperty is not a function

Para lidar com essas deficiências, o JavaScript criou uma outra implementação de estrutura de dados hash table chamada Map

Assim como Object, Map permite a você guardar pares chave/valor dentro de uma estrutura de dados. Aqui está um exemplo de Map em ação:

const collection = new Map();

collection.set("Nathan", "555-0182");
collection.set("Jane", "555-0182");

console.log(collection.get("Nathan")); // 555-0182
console.log(collection.size); // 2

Ao contrário do tipo Object, Map requer que você use os métodos set() e get() para definir e buscar quaisquer valores de chave/valor que desejar adicionar à estrutura de dados.

Você também não consegue sobrescrever, em  Map, propriedades herdadas. Por exemplo, o código a seguir tentou sobrescrever o valor da propriedade size para  false:

const collection = new Map();

collection.set("Nathan", "555-0182");
collection["size"] = false;

console.log(collection.get("size")); // undefined
console.log(collection.size); // 1

Como você pode ver no código acima, você não pode adicionar uma nova entrada para o objeto Map sem usar o método set().

A estrutura de dados Map é iterável também, o que significa que você pode fazer um loop para percorrer os dados como no código a seguir:

const myMap = new Map();

myMap.set("Nathan", "555-0182");
myMap.set("Jane", "315-0322");

for (let [key, value] of myMap) {
  console.log(`${key} = ${value}`);
}

Agora que você aprendeu como JavaScript implementa hash tables nas estruturas de dados Object e Map, vamos ver como você pode criar sua própria implementação de uma hash table a seguir.

Como implementar uma estrutura de dados de hash table em JavaScript

Embora o JavaScript já tenha duas implementações de hash table, escrever sua própria implementação é uma dos exercícios mais comuns de entrevistas de  emprego que envolvem JavaScript.

Você pode implementar uma hash table em JavaScript em três passos:

• Criar uma classe HashTable com table e size como propriedades iniciais
• Adicionar uma função hash() para transformar chaves em índices, index em inglês
• Adicionar métodos set() e get() para inserir e obter pares de chave/valor da tabela.

Dito isso, começaremos  criando uma classe HashTable. O código abaixo criará uma table com 127 espaços para armazenamento:

class HashTable {
  constructor() {
    this.table = new Array(127);
    this.size = 0;
  }
}

Todos seus pares de chave/valor serão armazenados dentro da propriedade table.

Como escrever o método hash()

A seguir, você precisa criar o método hash() que aceitará um valor key e transformá-lo em um index.

Um jeito simples de criar a hash seria somar o código ASCII dos caracteres na chave usando o método charCodeAt() como é feito abaixo. Note que o método é nomeado usando _  para indicar que essa é uma classe privada:

_hash(key) {
  let hash = 0;
  for (let i = 0; i < key.length; i++) {
    hash += key.charCodeAt(i);
  }
  return hash;
}

Considerando, no entanto, que a classe HashTable tem apenas 127 espaços, o método _hash() deve retornar um número entre 0 e 127.

Para assegurar que o valor do hash não excederá o tamanho permitido, você precisa usar o operador módulo como é mostrado a seguir:

_hash(key) {
  let hash = 0;
  for (let i = 0; i < key.length; i++) {
    hash += key.charCodeAt(i);
  }
  return hash % this.table.length;
}

Agora que você tem o método _hash() completo, é hora de escrever os métodos set() e get().

Como criar o método set()

Para inserir os pares de chave/valor na sua hash table, você precisa escrever um método set() que aceita como parâmetros (chave, valor):

• O método set() chamará o método _hash() para obter o valor do index
• O par [chave, valor]  será atribuído na tabela noindex especificado
• Então, a propriedade size será incrementada uma vez

set(key, value) {
  const index = this._hash(key);
  this.table[index] = [key, value];
  this.size++;
}

Agora que o método set() está completo, vamos escrever o método get() para obter o valor por sua chave.

Como escrever o método get()

Para obter um certo valor da hash table, você precisa escrever um método get() que aceita um valor key como parâmetro:

• O método chamará o método _hash() novamente para obter na tabela o index
• Retorne o valor guardado em table[index]

get(key) {
  const index = this._hash(key);
  return this.table[index];
}

Desse modo, o método get() retornará o par chave/valor ou undefined quando não tiver nenhum par de chave/valor guardado no index especificado.

Tudo certo por enquanto. Vamos, a seguir, adicionar outro método para excluir um par de chave/valor da hash table.

Como escrever o método remove()

Para excluir um par de chave/valor da hash table, você precisa escrever um método remove(), que aceita um valor key como parâmetro:

• Obtenha o index certo usando o método _hash()
• Confira se table[index] tem um valor verdadeiro (truthy, em inglês) e se a propriedade length é maior que zero. Atribua o valor undefined para index e decremente a propriedade size se possível.
• Caso contrário, simplesmente retorne false

remove(key) {
  const index = this._hash(key);

  if (this.table[index] && this.table[index].length) {
    this.table[index] = undefined;
    this.size--;
    return true;
  } else {
    return false;
  }
}

Com isso, você agora tem um método remove() funcionando. Vamos ver se a classe HashTable funciona corretamente.

Como testar a implementação da hash table

É hora de testar a implementação da hash table. Aqui está, novamente, o código completo para a implementação da hash table:

class HashTable {
  constructor() {
    this.table = new Array(127);
    this.size = 0;
  }

  _hash(key) {
    let hash = 0;
    for (let i = 0; i < key.length; i++) {
      hash += key.charCodeAt(i);
    }
    return hash % this.table.length;
  }

  set(key, value) {
    const index = this._hash(key);
    this.table[index] = [key, value];
    this.size++;
  }

  get(key) {
    const target = this._hash(key);
    return this.table[target];
  }

  remove(key) {
    const index = this._hash(key);

    if (this.table[index] && this.table[index].length) {
      this.table[index] = [];
      this.size--;
      return true;
    } else {
      return false;
    }
  }
}

Para testar a classe HashTable, eu vou criar uma nova instância da classe e configurar alguns pares de chave e valor como mostrado abaixo. Os pares de chave/valor abaixo contém apenas valores arbitrários combinados sem nenhum significado especial:

const ht = new HashTable();
ht.set("Canada", 300);
ht.set("France", 100);
ht.set("Spain", 110);

Então, vamos tentar obtê-los usando o método get():

console.log(ht.get("Canada")); // [ 'Canada', 300 ]
console.log(ht.get("France")); // [ 'France', 100 ]
console.log(ht.get("Spain")); // [ 'Spain', 110 ]

Finalmente, vamos tentar excluir um desses valores com o método remove():

console.log(ht.remove("Spain")); // true
console.log(ht.get("Spain")); // undefined

Tudo bem, todos os métodos estão funcionando como esperado. Vamos tentar outra inserção com uma nova instância de HashTable e obter esses valores:

const ht = new HashTable();

ht.set("Spain", 110);
ht.set("ǻ", 192);

console.log(ht.get("Spain")); // [ 'ǻ', 192 ]
console.log(ht.get("ǻ")); // [ 'ǻ', 192 ]

Opa! Parece que nós temos um problema aqui. 😨

Como resolver os conflitos de index

Algumas vezes, a função hash em uma hash table pode retornar o mesmo index. No caso de teste acima, a string "Spain" e "ǻ" retornam o mesmo valor de hash, pois o número 507 é a soma de ambos os códigos ASCII.

O mesmo valor hash fará com que os índices entrem em conflito, sobrescrevendo o anterior com o novo valor configurado.

Até agora, o dado guardado em nossa implementação de hash table tem essa aparência:

[
    [ "Spain", 110],
    [ "France", 100]
]

Para resolver o conflito de index, você precisa guardar o par de chave/valor em um array secundário de modo que o resultado final seja algo assim:

[
    [
        [ "Spain", 110 ],
        [ "ǻ", 192 ]
    ],
    [
        ["France", 100]
    ],
]

Para criar o segundo array, você precisa atualizar o método set() para que ele:

• Procure o table[index] e itere sobre seus valores.
• Se a chave em um dos arrays for igual ao parâmetro key passado ao método, repita o valor no index 1 e pare quaisquer execuções futuras declarando um return.
• Se não encontrar nenhuma key igual, crie um novo array de chave e valor para o segundo array.
• Então, inicialize um novo array e coloque o par de chave/valor no index especificado.
• Sempre que um método push() for chamado, incremente a propriedade size em uma unidade.

O código do método set() completo está abaixo:

set(key, value) {
  const index = this._hash(key);
  if (this.table[index]) {
    for (let i = 0; i < this.table[index].length; i++) {
      //Encontre o par chave/valor na cadeia
      if (this.table[index][i][0] === key) {
        this.table[index][i][1] = value;
        return;
      }
    }
    //Se não for encontrado, crie um novo par de chave/valor
    this.table[index].push([key, value]);
  } else {
    this.table[index] = [];
    this.table[index].push([key, value]);
  }
  this.size++;
}

A seguir, atualize o método get() de maneira que ele também confira o array de segundo nível com um laço for e retorne o par correto de chave/valor:

get(key) {
  const target = this._hash(key);
  if (this.table[target]) {
    for (let i = 0; i < this.table.length; i++) {
      if (this.table[target][i][0] === key) {
        return this.table[target][i][1];
      }
    }
  }
  return undefined;
}

Finalmente, você precisa atualizar o método remove() para que ele faça um laço para iterar sobre o array de segundo nível e remova o array com o valor da key correta usando o método splice():

remove(key) {
  const index = this._hash(key);

  if (this.table[index] && this.table[index].length) {
    for (let i = 0; i < this.table.length; i++) {
      if (this.table[index][i][0] === key) {
        this.table[index].splice(i, 1);
        this.size--;
        return true;
      }
    }
  } else {
    return false;
  }
}

Com isso, sua classe HashTable será capaz de evitar quaisquer conflitos de index eventuais e guardará o par de chave/valor dentro do array de segundo nível.

Como bônus, vamos adicionar um método display() que mostrará todos os pares de chave/valor guardados na Hash Table. Você só precisa usar o método forEach() para iterar sobre a tabela e usar map() para mapear os valores para uma string assim como no exemplo a seguir:

display() {
  this.table.forEach((values, index) => {
    const chainedValues = values.map(
      ([key, value]) => `[ ${key}: ${value} ]`
    );
    console.log(`${index}: ${chainedValues}`);
  });
}

Aqui está o código da classe HashTable completo novamente com a aplicação correta para a resolução do conflito de índices, para sua referência:

class HashTable {
  constructor() {
    this.table = new Array(127);
    this.size = 0;
  }

  _hash(key) {
    let hash = 0;
    for (let i = 0; i < key.length; i++) {
      hash += key.charCodeAt(i);
    }
    return hash % this.table.length;
  }

  set(key, value) {
    const index = this._hash(key);
    if (this.table[index]) {
      for (let i = 0; i < this.table[index].length; i++) {
        if (this.table[index][i][0] === key) {
          this.table[index][i][1] = value;
          return;
        }
      }
      this.table[index].push([key, value]);
    } else {
      this.table[index] = [];
      this.table[index].push([key, value]);
    }
    this.size++;
  }

  get(key) {
    const index = this._hash(key);
    if (this.table[index]) {
      for (let i = 0; i < this.table.length; i++) {
        if (this.table[index][i][0] === key) {
          return this.table[index][i][1];
        }
      }
    }
    return undefined;
  }

  remove(key) {
    const index = this._hash(key);

    if (this.table[index] && this.table[index].length) {
      for (let i = 0; i < this.table.length; i++) {
        if (this.table[index][i][0] === key) {
          this.table[index].splice(i, 1);
          this.size--;
          return true;
        }
      }
    } else {
      return false;
    }
  }

  display() {
    this.table.forEach((values, index) => {
      const chainedValues = values.map(
        ([key, value]) => `[ ${key}: ${value} ]`
      );
      console.log(`${index}: ${chainedValues}`);
    });
  }
}

Você pode testar a implementação criando uma nova instância de HashTable e fazer algumas inserções e remoções:

const ht = new HashTable();

ht.set("France", 111);
ht.set("Spain", 150);
ht.set("ǻ", 192);

ht.display();
// 83: [ France: 111 ]
// 126: [ Spain: 150 ],[ ǻ: 192 ]

console.log(ht.size); // 3
ht.remove("Spain");
ht.display();
// 83: [ France: 111 ]
// 126: [ ǻ: 192 ]

Aqui, não houve conflitos dentro da instância da HashTable. Ótimo trabalho!

Conclusão

Nesse tutorial, você aprendeu o que é uma hash table e como o JavaScript a usa para criar as estruturas de dados Object e Map.

Você também aprendeu como implementar sua própria classe HashTable e como evitar o conflito de índices na hash table usando a técnica de encadeamento.

Ao usar a estrutura de dados hash table, você será capaz de criar um array associativo com operações rápidas de busca, inserção e remoção. 😉

Obrigado por ler esse tutorial

Se você quiser ler mais sobre JavaScript, pode dar uma olhada no meu site pessoal, sebhastian.com, onde eu tenho publicados mais de 100 tutoriais sobre programação em JavaScript, todos eles usando explicações bem fáceis de entender e exemplos de código.

Os tutoriais incluem manipulação de strings, manipulação de datas, métodos de arrays e de objetos, soluções de algoritmos em JavaScript e muito mais.

Existem muitas ferramentas para automatizar nossos processos de codificação. Nós podemos procurar por erros de sintaxe com ESLint e formatar nosso código com Prettier.

Nem todo mundo na sua equipe se lembrará de rodar todos os comandos toda vez que for feito um commit. Como nós podemos usar o Husky para adicionar hooks do Git e fazer com que eles executem esses comandos para nós?

• O que são os hooks do Git?
• O que é Husky?
• O que nós vamos construir?
• Passo 0: como configurar um novo projeto
• Passo 1: como instalar o Husky em um projeto
• Passo 2: como configurar o Husky para rodar os hooks do Git
• Passo 3: como usar o Husky para formar o código com Prettier

O que são os hooks do Git?

Os Git hooks (ou hooks do Git) são scripts que você pode configurar para rodar em certos eventos no ciclo de vida do Git. Esses eventos incluem diferentes estágios do commit, como antes de um commit (pré-commit) e depois de um commit (pós-commit).

Eles são muito úteis, pois permitem que desenvolvedores rodem processos de código automatizados ou até forcem padrões ao automatizar outros scripts para rodar esses processos.

O que é o Husky?

O Husky é uma ferramenta que nos permite facilmente configurar hooks do Git e executar scripts que queremos em certos estágios.

Ele inclui um objeto dentro do nosso arquivo package.json  que rodará o Husky nos scripts que nós especificarmos. Depois disso, o Husky gerencia os pontos do ciclo de vida do Git em que nossos scripts rodarão.

O que nós vamos construir?

Vamos configurar um projeto simples onde poderemos testar os hooks do Git.

Você pode acompanhar o artigo com qualquer projeto em que você estiver trabalhando. Usarei o Next.js como ponto inicial, simplesmente pelo fato de que precisamos rodar apenas um comando para ter o projeto iniciado.

Uma consideração é que, ao acompanhar com esse projeto, saiba que estaremos usando o Prettier como um exemplo do que você pode fazer com hooks do Git.

O Prettier é uma ferramenta que automaticamente formatará nosso código sem que tenhamos que fazê-lo, o que, se você não estiver se preparando para fazer, pode causar muita tensão. Acompanhar comigo usando o projeto com Next.js vai permitir que você faça testes sem mudanças não intencionais.

Quanto ao teste dos hooks do Git, começaremos adicionando uma instrução simples na linha de comando para ver o Husky funcionando e nós também testaremos a adição do Prettier, que formatará o nosso código automaticamente.

Por fim, enquanto escrevo esse artigo, soube que o Husky lançou uma versão Alpha v7. Considerando que é apenas uma versão Alpha, seguiremos com a v4, que nos permite instalar facilmente o Husky com o npm.

Passo 0: como configurar um novo projeto

Como eu mencionei, você pode seguir os mesmos passos com qualquer projeto gerenciado com um arquivo package.json.

O Next.js é absolutamente algo além do necessário para um passo a passo básico. Porém, o objetivo é minimizar os passos de configuração para focar no trabalho com o Husky.

Para começar com o Next.js, vá até o diretório em que você deseja começar seu projeto e rode o seguinte comando:

yarn create-next-app meu-projeto-com-husky
# ou
npx create-next-app meu-projeto-com-husky

Nota: sinta-se livre para substituir meu-projeto-com-husky pelo nome que você quiser que o seu diretório tenha.

Isso criará uma nova pasta, um novo projeto Next.js, e instalará todas as dependências.

Ao terminar, navegue até aquela nova pasta e podemos seguir em frente!

Acompanhe aqui com o commit.

Passo1: como instalar o Husky em um projeto

Para instalar o Husky, podemos utilizar o yarn ou o npm.

yarn add husky
# ou
npm install husky

Nota: se, ao instalar o Husky nesse momento, a versão instalada for a v7, isso significa que a v7 foi oficialmente lançada. Confira a documentação atualizada do Husky (em inglês) ou instale a última versão da v4 especificando husky@4.3.0 (ou seja qual for a versão mais recente) ao instalar.

Quando o pacote terminar de instalar, podemos seguir com o Husky.

Acompanhe aqui com o commit.

Passo 2: como configurar o Husky para rodar os hooks do Git

Agora, vamos configurar o Husky para conseguir usar nossos hooks do Git.

Dentro do nosso arquivo package.json, crie uma nova propriedade chamada husky com um objeto vazio.

"husky": {},

Você pode, de fato, adicionar essa propriedade onde você quiser no arquivo package.json. Eu, no entanto, a adicionarei logo após a propriedade scripts  para conseguir gerenciá-las juntas mais facilmente.

Dentro da propriedade Husky, adicionaremos outra propriedade chamada hooks, que também contém um objeto vazio:

"husky": {
  "hooks": {}
},

Aqui é onde adicionaremos nossos hooks do Git. O Husky suporta basicamente todos os hooks do Git definidos pelo próprio Git. Então, podemos ser tão flexíveis quanto quisermos dentro do nosso fluxo de eventos do Git.

Para fins de teste, eu criei uma nova branch onde eu literalmente adicionei todos os hooks do Git daquela página, incluindo um script que simplesmente escreve no terminal [Husky] nome do evento.

Nota: você não precisa fazer isso a não ser que esteja curioso. O objetivo é ser capaz de demonstrar a você, com meu exemplo, como funciona.

“husky”: {
  “hooks”: {
    “applypatch-msg”: “echo \”[Husky] applypatch-msg\””,
    “pre-applypatch”: “echo \”[Husky] pre-applypatch\””,
    “post-applypatch”: “echo \”[Husky] post-applypatch\””,
    “pre-commit”: “echo \”[Husky] pre-commit\””,
	}
}

O que isso fará é dizer ao Husky que, em cada etapa na qual temos permissão para nos conectar ao Git, diremos a ele a ação desejada!

Quando eu fizer os commits dessas mudanças, nós poderemos imediatamente ver o Husky disparar alguns de nossos scripts.

Esses são todos eventos aos quais o Git permite que nos conectemos e que acontecem durante o processo de commit.

Do mesmo modo, se eu der um push nessas mudanças para o Github, poderei ver que o processo de push roda o hook pre-push!

Pode ser que nunca usemos a maioria dos hooks que o Husky e o Git proporcionam (vimos apenas alguns deles).

Porém, é realmente incrível ver como isso pode ser poderoso, seja rodando códigos que formatarão o nosso código, evitando que se faça o commit de chaves de acesso secretas sejam commitadas, ou qualquer coisa que possa ajudar a automatizar tarefas importantes do nosso fluxo de trabalho.

Conseguimos ver, agora, que configuramos o Husky ao especificar a configuração e os hooks dentro do nosso package.json.

Acompanhe aqui com o commit.

Nota: se quiser conferir minha branch que inclui todos os testes com hooks do Git, você pode encontrá-la no Github.

Passo 3: como usar o Husky para formatar seu código com Prettier

Finalmente, em um caso mais próximo à realidade, testaremos o Prettier e formataremos nosso código automaticamente.

O Prettier é uma ferramenta de formatação de código que permite limpar o código facilmente, fazendo parecer como se uma única pessoa o tivesse escrito.

Por que ferramentas como o Prettier são importantes? Quando estamos programando, especialmente em equipe, é importante manter a consistência para que todo mundo saiba o que esperar. Isso evitará discussões sobre um ponto e vírgula em uma code review, mas também ajudará a identificar erros de sintaxe e a prevenir bugs.

Atenção: rodar o Prettier formatará automaticamente todo o código. Por enquanto, estamos testando isso antes de fazer o commit das mudanças. Assim que você aplicar isso a um Git Hook, ele automatizará esse processo.

Para começar, vamos instalar o Prettier com nosso gerenciador de pacotes:

yarn add prettier -D
# ou
npm install prettier --save-dev

Nota: estamos instalando o Prettier como uma devDependency, já que sua aplicação não precisa disso para rodar.

Depois, podemos adicionar um novo script ao nosso package.json que facilitará rodar o Prettier para fazer os testes.

Dentro da propriedade scripts, adicione:

"lint": "prettier --check ."

Para começar, rodaremos o primeiro teste na modalidade "check", o que nos permite ver quais arquivos seriam alterados.

Execute o seguinte comando:

yarn lint
# ou 
npm run lint

Assim que o fizermos, poderemos perceber que o Prettier nos dirá quais dos arquivos listados serão alterados.

Nesse ponto, nosso código se manterá inalterado. Se quisermos que mudanças reais sejam feitas, primeiros temos que incluir um script adicional:

"format": "prettier --write ."

Se rodarmos esse script, ele atualizará todos aqueles arquivos mencionados de acordo com a especificação do Prettier.

Atenção: executar o Prettier para realizar as mudanças fará alterações em seus arquivos. Todas essas alterações são apenas para fins de adequação de estilo e não deveriam impactar o modo como seu código é executado, apenas a aparência dele. Antes de formatar, é prudente salvar todas as suas mudanças através de um commit no Git, de maneira a poder reverter facilmente essas mudanças caso não esteja feliz com elas.

Você agora pode rodar o script com:

yarn format

E podemos ver que o Prettier atualizou seus arquivos!

Agora, a parte que é relevante nessa jornada: podemos adicionar isso como um hook do Git. Dessa maneira, quando alguém tentar realizar um commit em um código, o Prettier executará antes de o código ser salvo. Isso significa que sempre manteremos um código consistente, com o Prettier formatando o estilo.

Dentro de nossa configuração dos hooks no Husky, vamos adicionar:

"husky": {
  "hooks": {
    "pre-commit": "prettier --write . && git add -A ."
  }
},

Como você pode perceber, no nosso hook pré-commit, também estamos adicionando git add -A ..

Quando o Husky for executado, ele simplesmente executará o script fornecido. Ao rodar o comando do Prettier, estamos apenas formatando o código, mas ainda faltaria salvar essas mudanças como parte do processo. Por isso, usaremos git add para guardar todas essas mudanças e incluí-las no commit.

Para fins de teste, eu reverti as mudanças de todos os arquivos formatados antes. Se você estiver acompanhando com o mesmo projeto, você pode executar o seguinte comando:

git checkout pages

Essa ação apagará todas as mudanças em pages para o último commit.

Agora, vamos testar adicionar todos os nossos arquivos com Git e fazer o commit dessas mudanças.

Tendo executado o comando de commit, podemos ver que o hook pré-commit do Husky já fez seu trabalho e formatou nosso código.

Acompanhe aqui com o commit.

O que eu posso fazer depois?

Use lint-staged para formatar somente os arquivos modificados

Estamos usando o Prettier no nosso hook pré-commit e especificando ., o que significa rodar em todos os arquivos todas as vezes.

Podemos usar uma ferramenta chamada lint-staged, que ainda nos permite rodar nossos hooks do Git com o Husky, executando-o apenas naqueles arquivos que estão em stage no Git.

Por exemplo, se quiséssemos fazer isso com o Husky e o Prettier, nossa configuração se pareceria com algo do tipo:

"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "*": "prettier --write"
},

Como parte de como lint-staged é executado, ele anexará as mudanças dos arquivos alterados ao final de nossa instrução para o Prettier automaticamente.

Você também perceberá que não incluímos git add. O lint-staged também adicionará quaisquer mudanças ao Git instantaneamente para nós.

Personalize a configuração do Prettier para formatar as regras

O Prettier é bem opinativo. Há algumas coisas das quais eu, pessoalmente, não gosto e talvez você concorde comigo.

Felizmente, o Prettier permite a você configurar um arquivo que pode sobrescrever algumas regras para fazer com que seu código seja do jeito que você e seu time queiram.

Diga ao Prettier para ignorar arquivos com .prettierignore

Você provavelmente não quer o Prettier rodando em "tudo" (bem, talvez sim).

O Prettier permite que você configure um arquivo .prettierignore  dentro da raiz do seu projeto, próximo ao package.json, de modo similar ao .gitignore, que possibilita a você dizer ao Prettier quais arquivos ele não deve monitorar.

• Siga o autor no Twitter
• Inscreva-se no canal do YouTube do autor
• Inscreva-se para receber a newsletter do autor
• Patrocine o autor