Forem: Charles Assunção

Estruturas de dados como Hooks, um guia: Linked List

Charles Assunção — Wed, 29 Sep 2021 02:39:31 +0000

“Programadores medianos se preocupam meramente com o código. Programadores excelentes se preocupam com estruturas de dados e suas relações.” — Linus Torvalds

Eu amo algoritmos e estruturas de dados, quando estava na faculdade eu fui monitor de estruturas de dados ( basicamente ajudava alunos novos a entender o assunto e o professor a corrigir exercícios ). Se quiser saber mais sobre minha história você pode conferir meu post fazendo um review dos últimos anos. Eu também costumo passar algumas horas do meu tempo livre brincando com os amigos no clash of code.

É, eu sei, bem nerd 🤓. Então como uma forma de ressuscitar esse meu antigo prazer, eu decidi criar uma série de posts implementando estruturas de dados em javascript e para fazer isso ficar mais divertido e no hype vamos fazer isso tudo como react hooks

Vamos ver várias estruturas de dados aqui, mas quis começar com uma das mais simples e comuns Linked List ( lista encadeada ).

Para quem ainda não sabe muito bem como funciona a lista encadeada confere aqui o que o Wikipedia diz sobre:

Em ciência da computação, a lista ou sequência é uma abstração de tipo de dado que representa um número mensurável de valores ordenados.

Se isso não ajudou muito, você pode apenas imaginar uma sequência de dados onde um dado está conectado com o próximo, pro exemplo:

1 -> 2 -> 3 -> 4 -> 5 -> null

Considerando uma lista como essa, podemos chamar cada número de node ( nó ) e dar um nome especial para o primeiro e último, respectivamente head and tail ( cabeça e cauda ).

Todo o código que vamos ver aqui está disponível nesse CodeSandbox. Junto com uma pequena aplicação para visualizar nosso trabalho.

Chega de teoria, vamos botar a mão na massa...

DISCLAIMER: O objetivo aqui é ser o mais didático possível para iniciantes, então estou bem ciente que o código aqui pode não ser padrão de qualidade de produção. Também estou tentando evitar algumas mágicas do JS e coisas mais complexas como recursão para manter o mais simples possível. ;)

API

No final, o que queremos é atingir um contrato ( API ) parecido com o código a seguir:

const { 
    list,
    tail,
    size,
    add,
    remove,
    removeAt,
    indexOf,
    dataAt, 
} = useList();

Nossa lista é apenas uma sequência de nodes então precisamos representar isso. Vamos dizer que queremos poder usar um node da seguinte forma:

const node = new Node(1); // 1 ou qualquer outro tipo de data que você queira manter na sua lista

Partes fundamentais

Node

Nossa lista vai ser construída com nodes e nos vamos fazer operar funções nos nodes então faz todo sentido que criar nossa representação de Node seja a primeira coisa a se fazer...

function Node(data) {
  this.data = data;
  this.next = null;
}

// 1,2,3 Testando...

const node = new Node(1);
console.log(node); // { data: 1, next: null }

Ações

Vamos usar um reducer simples nativo do React para manipular nossa list e para isso funcionar precisamos ter uma ideia clara do que pode ser executado, então vamos definir as possíveis ações que podem acontecer na nossa list:

const actions = {
  ADD: "[LIST] - ADD",
  REMOVE: "[LIST] - REMOVE",
  REMOVE_AT_INDEX: "[LIST] - REMOVE_AT_INDEX",
  REVERT: "[LIST] - REVERT"
}

O hook

Nosso hook é uma função bem simples que apenas mantem o estado usando useState e expõem algumas funções para permitir manipular o estado, então a gente vai começar com algo parecido com o seguinte:


export function useList() {
    const [{ list, tail, size }, dispatch] = useReducer(listReducer, {
         tail: null,
         list: null,
         size: 0
    });

    const add = (data) => {
        dispatch({ type: actions.ADD, data });
    }

    ...

    return { add, ..., list, tail, size }
}

Reducer

Precisamos definir nosso reducer, o que vai ser bem simples, basicamente contendo manipulação do estado baseado nas ações que definimos anteriormente.

const listReducer = (state, action) => {
    switch (action.type) {
        ...
        default:
            return state;
    }
};

Métodos base

Precisaremos de algumas funções para poder executar algumas operaçÕes na list, então vamos começar construindo-as:

`add`

Temos que poder adicionar novos nodes na list e, como disse anteriormente, manter a referência da tail para que nossa operação de add seja O(1) 🤟🏻. Nossa função vai receber o dado para ser adicionado, a list atual e nossa tail.

const add = (data, { list, tail, size }) => { ... }

Vamos conferir se já existe o primeiro node na nossa list ou se vamos ter que criar o primeiro. Se é o primeiro elemento da list apenas vamos criar um Node e fazer com que nossa list seja aquele node. Nossa condição vai ser algo semelhante à:

if (!list) {
    let newList = new Node(data);
    let newTail = newList;
    return { list: newList, tail: newTail };
}

Se já tivermos algo na list, significa apenas que devemos adicionar algo depois da tail ( que é sempre nosso último elemento ) e então fazer com que o próximo elemento depois da nossa tail atual passe a ser a nova tail. Colocando tudo isso em código vai ficar mais ou menos assim:

const add = (data, { list, tail, size }) => {
    if (!list) {
        let newList = new Node(data);
        let newTail = newList;
    return { list: newList, tail: newTail, size: size + 1 };
    } else {
        tail.next = new Node(data);
        tail = tail.next;
        return { list, tail, size: size + 1 };
    }
};

E agora a gente tem que adicionar o que fizemos no reducer.

case actions.ADD:
    return { ...state, ...add(action.data, state) };

`remove`

Esse vai parecer um pouco mais complicado, mas não se preocupe, é apenas umas linhas a mais de código e a gente vai dar conta 😉.

A gente só pode remover um node se a nossa list não está vazia, então vamos colocar todo nosso código dentro dessa condição:

const remove = (data, { list, tail, size }) => {
    if (list) {
        ....
    }
}

Se estamos tentando remover o primeiro node tudo que precisamos fazer é com que o começo da nossa list passe a ser o atual segundo elemento e se o próximo item não existia vamos ter que "limpar" nossa tail também.

if (list.data === data) {
    const newList = list.next;
    return { list: list.next, tail: !newList ? null : tail, size: size - 1 };
}

Se esse não era o caso, vamos ter que "andar" na nossa lista até encontrarmos o node que queremos remover. Vamos dizer que queremos remover o node X, começamos olhando o início da lista pulando para o próximo até chegar em X e quando isso acontecer fazemos com que o node anterior de X agora aponte para o node depois de X o que seria X.next e assim cortando o X da list

    // Vamos usar esse para percorrer na list 
    let currentNode = list;
    // Vamos sempre manter uma referência do no anterior
    // Para que possamos mudar para onde ele vai apontar
    // Quando encontrarmos o node que queremos remover.
    let prev = null;
    // vamos caminhar na lista até encontrar o que queremos
    // ou até chegarmos no fim
    while (currentNode.data !== data && currentNode.next) {
        prev = currentNode;
        currentNode = currentNode.next;
    }
    // Se o node atual é o node que queremos remover...
    if (currentNode.data === data) {
        // Vamos primeiro verificar se estamos tentando 
        // remover nossa tail atual e se sim nossa tail
        // vai se tornar no node anterior
        if (currentNode === tail) {
            prev.next = null;
            tail = prev;
        } else { 
            // Se não, apenas fazemos nosso node anterior
            // apontar para o próximo
            prev.next = currentNode.next;
        }
        return { list, tail, size: size - 1 };
    }

No final, nosso método remove vai ficar assim:

const remove = (data, { list, tail, size }) => {
    if (list) {
        if (list.data === data) {
            const newList = list.next;
            return { list: list.next, tail: !newList ? null : tail, size: size - 1 };
    } else {
        let currentNode = list;
        let prev = null;
        while (currentNode.data !== data && currentNode.next) {
                prev = currentNode;
        currentNode = currentNode.next;
        }
        if (currentNode.data === data) {
            if (currentNode === tail) {
            prev.next = null;
            tail = prev;
        } else {
            prev.next = currentNode.next;
        }
        return { list, tail, size: size - 1 };
        }
    }
    }
};

É um pouco mais complicado porque estamos mantendo referência da tail mas é um preço que vale a pena pagar. No pior cenário esse método vai passar por todos os possíveis nodes da nossa list então podemos dizer que ele é O(N) 🤷🏻‍♂️.

Agora vamos apenas adicionar nosso método no nosso reducer:

    case actions.REMOVE:
        return { ...state, ...remove(action.data, state) };

`indexOf`

Algumas vezes vamos querer saber em qual posição específica um dado se encontra, para isso vamos utilizar o método indexOf. Nossa list vai ser baseada em index 0, basicamente como um array. O que precisamos fazer é percorrer a list até encontrarmos nosso dado procurado e se chegarmos ao final e não encontrarmos vamos retornar -1. O método vai ser bem simples de entender e não precisamos adicionar ele no reducer já que ele não vai alterar nosso estado.

    const indexOf = (data) => {
        // Começamos sempre do index 0
        let currentIndex = 0;
        let currentNode = list;
        // Enquanto existir um node para percorrer e
        // ainda não encontramos nosso dado
        // vamos aumentar nosso currentIndex e ir para o
        // próximo node
        while (currentNode && currentNode.data !== data) {
            currentNode = currentNode.next;
            currentIndex++;
        }
        // Encontramos o dado? Se sim, retorne o index
        // se não, retorne `-1`
        return currentNode?.data === data ? currentIndex : -1;
    };

Apenas um detalhe final sobre esse método: para podermos encontrar um dado é possível que tenhamos que olhar todos os nodes até o final o que faz o indexOf ser O(N).

`revert`

Esse é bem comum de ser perguntando em uma entrevista de emprego. É bem legal de resolver usando recursão, mas vamos manter o simples e fazer iterativo. Vamos ter que passar por cada node e mudar seu próximo, isso faz do nosso método O(N). O objetivo aqui é se tivermos uma list como:

1 -> 2 -> 3 -> null

Depois de usar o revert esperamos ter:

3 -> 2 -> 1 -> null

Então a primeira coisa como no método anterior é conferir se a list não está vazia e se não estiver vamos manter referência para o node atual e o anterior. Enquanto existir nodes para percorrer vamos trocar o anterior com o atual, parece confuso? Vamos ver o código:

const revertList = (list) => {
    if (list) {
        let prev = null;
        let currentNode = list;
        // Vamos lembrar que temos que prestar atenção 
        // com a tail
        let tail = null;
        while (currentNode) {
            // Salve o restante da list por enquanto
            let restList = currentNode.next;
            // faça o node atual apontar para o anterior
            currentNode.next = prev;
            // substitua o anterior pelo atual
            prev = currentNode;
            // e se o nosso anterior agora aponta
            // para o fim ( null ) 
            // significa que ele é nossa nova tail 
            if (prev.next === null) {
                tail = prev;
            }
            // pegue o resto da list e continue fazendo 
            // o mesmo processo
            currentNode = restList;
    }
        return { list: prev, tail };
    }
};

Agora vamos apenas adicionar o método no nosso reducer:

    case actions.REVERT:
        return { ...state, ...revertList(state.list) };

`stringify`

E por último, temos que ter alguma forma de visualizar nossa list não é? Vamos criar um método bem simples que vai percorrer a lista e combinar o poder dos arrays para não ter que ficar conferindo se temos um próximo elemento ou não.

    const listDataArray = [];
    let currentNode = list;
    while (currentNode) {
        listDataArray.push(currentNode.data);
        currentNode = currentNode.next;
    }
    return listDataArray.join(' -> ');

Isso é tudo pessoal, com certeza podemos nos divertir um pouco mais com a estrutura de dados list e implementar outros métodos ( eu até implementei alguns outros no CodeSandbox ) mas esse tutorial ficou grande de mais já e imagino que agora você já tem uma ideia básica de como a Linked List funciona correto?

Se curtiu, ficou com qualquer dúvida ou quer dar uma sugestão de qual pode ser nossa próxima estrutura de dado pode ficar a vontade para falar comigo no meu instagram onde eu também compartilho mais dicas de programação.

Async/await ainda pode te surpreender... MUITO!

Charles Assunção — Fri, 10 Sep 2021 13:21:56 +0000

Eu amo tecnologia ❤, e o fato de que não importa o quanto você saiba ainda vai existir algo para te supreender. Algum tempo atras, um amigo meu (@Rafael_Toscano) me mostrou algo e minha reação automática foi mais ou menos assim:

Ele compartilhou comigo um artigo do blog da V8 sobre "Faster async functions and promises." e entre várias coisas interessantes, uma particular capturou minha atenção de uma forma que na hora eu pensei "Isso não pode ser real, vou ter que testar."

Era sobre o comportamento do async/await e como podem ser usados com qualquer função que seja considerada "thenable". O que isso significa? Qualquer objeto que tenha um método then() pode ser usado com async/await

No artigo ele da o seguinte exemplo:

class Sleep {
  constructor(timeout) {
    this.timeout = timeout;
  }
  then(resolve, reject) {
    const startTime = Date.now();
    setTimeout(() => resolve(Date.now() - startTime),
               this.timeout);
  }
}

(async () => {
  const actualTime = await new Sleep(1000);
  console.log(actualTime);
})();

Yeaaah, por favor me diz que não fui só eu que ficou tão surpreso.

Acho que ajuda a gente a entender um pouco mais sobre como async/await funciona e as possibilidades das coisas que podemos fazer fazer. Mas como diria tio Ben, isso tudo vem com grandes responsabilidades também, não vai sair colocando objetos com then no projeto só para parecer fodão 💣

Você provavelmente nunca vai precisar de usar async/await dessa forma direta e se você encontrar um caso de uso para isso por favor compartilha com a gente. Um caso que eu considerei foi para implementar algo chamado "retry strategy", segue o exemplo:

const ServerMock = {
  count: 0,
  getData() {
    if (this.count === 2) {
      return Promise.resolve([{ name: "SomeName" }]);
    } else {
      this.count++;
      return Promise.reject("Error");
    }
  }
};

function fetchData(limit, time) {
  return {
    then(resolve, reject) {
      const retry = setInterval(async () => {
        limit--;
        try {
          console.log("Trying....");
          const data = await ServerMock.getData();
          if (data) {
            console.log("Resolve");
            clearInterval(retry);
            resolve(data);
          }
        } catch {
          if (limit === 0) {
            clearInterval(retry);
            reject("Limit Reached");
          }
        }
      }, time);
    }
  };
}

(async () => {
  try {
    const result = await fetchData(3, 1000);
    console.log(result);
  } catch (err) {
    console.log(err);
  }
})();

Me diz o que você achou sobre essa nova descoberta nos comentários...

Um review de quase 10 anos como Dev

Charles Assunção — Tue, 07 Sep 2021 14:52:20 +0000

Recentemente eu visitei minha cidade natal e tive a oportunidade de dar um palestra sobre minha carreira e sobre as experiências que tive em meus poucos anos em TI. Inspirado pelo artigo Dan Abramov's Decade Review eu decide fazer o meu próprio review dos últimos anos, meus últimos 8 anos para ser mais preciso, até porque eu nunca tinha visto uma linha de código antes de 2013. Então vamos começar por lá...

Junho, 2013

Eu já tinha acabado o ensino médio há um ano e agora tinha 19 anos. Como qualquer jovem eu sofria um pouco de pressão da família para cursar uma faculdade e encontrar minha carreira. O único problema foi que eu não tinha a menor ideia do que eu queria, vindo de uma familia de policiais e pessoas da área de humanas eu até tive interesse em direito mas não chegava nem perto de imaginar como profissão.

Em Junho de 2013 acontecia na minha cidade um evento chamado AppWeem, tinha uma proposta engraçada: Reunir desenvolvedores usando fantasias de meia noite a 6 da manhã para criar aplicativos para Windows 8. Eu sempre tive interesse por computador e tecnologia, tentava consertar as coisas sozinho e vivia montando e desmontado meu PC, mas eu nunca tive contato com código, se alguém me perguntasse sobre naquela época eu provavelmente diria que era algo só para super gênios da matemática, mas mesmo assim eu decidi ir naquele evento.

Eu entrei em contato com o Microsoft Student Partner que organizava o evento e expliquei que eu não conhecia nada de código mas se ainda assim poderia ir. Ele deu todo apoio e graças a Deus eu decidi ir mesmo com todas dúvidas. Foi uma experiência incrível e eu conheci muita gente legal que cursava TI que compartilharam suas experiências da faculdade comigo e responderam todas minhas dúvidas sobre mercado. Eu fiz alguns amigos aquele dia, bebi muito Red Bull e até dancei Harlem Shake.

Alguns dias depois eu me cadastrei no vestibular da faculdade que ainda dava tempo para começar em agosto de 2013. De junho à agosto eu estudei todos materiais que o pessoal havia me recomendado no evento para que eu soubesse pelo menos o básico do básico quando a faculdade começasse. Tem muita discussão se faculdade é realmente necessária ou não para um desenvolvedor, eu não vou entrar nesse mérito aqui mas particularmente me sinto em dívida com alguns professores sensacionais que tive e somente aprendi realmente a codar depois de entrar na faculdade.

Depois de 3 meses estudando eu comecei a procurar algum estágio, tentando procurar algo que eu pudesse colocar as mãos na massa e tenho que admitir que fui muito abençoado por Deus, mesmo estando bem no início eu passei no processo de estágio no MIC (Microsoft Innovation Center) que ficava em outra unidade da minha faculdade. Era um programa remunerado para desenvolver novas ideias por 3 meses com orientação de desenvolvedores senior e pesquisadores experientes, lá eu tive o primeiro contato com tecnologias WEB (ASP.net e JQuery).

2014

Eu tinha completado meus 3 meses no MIC e estava começando o meu segundo semestre na faculdade. Bem no início de 2014 o coordenador do meu curso me recomendou para um estágio em uma empresa chamada TecMidia, eles faziam software para empresas de jornais, eu comecei a trabalhar lá com C# e aprendi muita coisa, tudo era novo para mime por vários momentos pensei que eu não era bom suficiente (Ei síndrome do impostor), mas a animação por estar trabalhando como desenvolvedor era maior. Não foi muito fácil sincronizar minha vida de estudante com o estágio, eu morava 25 km da empresa, mas definitivamente valeu a pena.

Ainda no começo do meu segundo semestre eu fui selecionado para a posição de Monitor de Algoritmos por causa da minha boa nota no primeiro semestre. Basicamente o que eu tinha que fazer era chegar 1 hora antes na faculdade para ficar a disposição dos alunos novos que quisessem tirar dúvidas e também ajudar o professor eventualmente a corrigir os exercícios. Pelos próximos 4 semestre eu tive a honra de continuar como monitor e ajudar o professor, foi um jeito muito legal para manter toda teoria do início fresca na minha mente.

2015

Esse foi um ano sensacional para mim, eu ainda era monitor na faculdade e estagiário na TecMidia... Lembra que eu disse que eu participei de um evento em 2013? Então, o organizador daquele evento agora era Microsoft Student Partner Lead responsável pelo meu estado (MG), a gente tinha mantido contado depois do evento até então. Em 2015 ele me recomendou para o programa Microsoft Student Partner, quando eu fui aceito foi uma das melhores sensações que já senti, juntos a gente iria compartilhar conhecimento e nossas experiências dando palestras em diversas cidades, participando de eventos e organizando hackathons. Conhecemos tantas pessoas sensacionais nessa jornada.

2016

Acredito que foi o ano que mais viajamos para eventos como MSP, perdi a conta de quantas cidades diferente fomos.

No fim do ano eu fui convidado, junto com outros MSP selecionados, para ir na sede da Microsoft em São Paulo e assistir um evento sobre a Imagine Cup onde o próprio Satya Nadella estaria. Nem preciso dizer o quanto essa experiência foi sensacional né?

2017

Agora eu era desenvolvedor JR na TecMidia por quase um ano e já tinha percebido que eu realmente gostava de tecnologias WEB e estava focando somente nisso, foi então que recebi a oferta de uma Fintech nova na minha cidade que tinha uma proposta muito interessante: Fazer o mercado financeiro acessível para todos. Fui oferecido a posição de front-end e então eu era o terceiro membro do recém criado time de front da Toro Investimentos.

🏳 Almoço é zona neutra, designers e devs almoçando juntos em paz :D

Eu tinha acabado de iniciar uma das experiências mais ricas que já tive, eu teria que escrever um artigo somente para descrever tudo que aprendi e vivi na Toro, foi literalmente minha primeira experiência como front, trabalhando com designers em um time usando scrum e com uma missão que eu conseguia sentir orgulho de fazer parte. Eu aprendi muito sobre a parte técnica ( hard skills ) e muito sobre trabalho em equipe. Sou eternamente grato por pessoas sensacionais que me ajudaram a me tornar um profissional melhor. ( Obrigado Helena e Fabricio por toda a paciência que tiveram comigo 😁 )

Eu estava lá bem no início, escrevendo o primeiro ng new do que se transformaria na Toro Investimentos, então você pode entender o orgulho que ainda tenho de ter contribuído, hoje vendo as notícias sobre a empresa.

2018

Foi definitivamente o ano com mais mudanças na minha vida, até esse ponto na minha vida eu nunca tinha saído do Brasil, nem ao menos tinha um passaporte e alguns poucos meses que 2018 começou eu passei em um processo para uma empresa em Varsóvia, Polônia. Eu mal podia acreditar nisso, mesmo com meu inglês meia boca eu consegui passar no processo, não foi nada fácil, mas eu consegui. 🎉

Eu estava indo trabalhar no Credit Suisse sendo terceirizado pela SII Poland, empresa gigante, novo país, nova cultura, novos desafios, novos amigos... Longe da família, dos velhos amigos... Não foi fácil adaptar.

Graças a Deus eu fiz verdadeiros bons amigos, com pouco tempo eu já estava viajando pela Europa com o Pawel, Karol e Rafael. Eu até convenci o karol, que era meu gerente, a visitar o Brasil com sua namorada. Rafael e eu tínhamos o hábito tomar café frequentemente e visitar alguma Starbucks aleatória pela cidade para sentar e ficar estudando ou desenvolvendo. A vida lá ficou mais fácil com esses amigos, o tempo passou rápido.

2019

Bem no início de 2019 eu fui contratado como funcionário do Credit Suisse ( Não mais terceirizado agora ). Agora eu tinha o título de Senior Software Engineer e trabalhei em vários projetos diferentes. No começo de 2019 eu comecei a trabalhar em um projeto em conjunto com um time de Nova York, o que foi uma experiência bem interessante tentar manter uma comunicação estando em horário bem diferentes.

Enquanto isso eu estava indo quase todos os dias para cafeterias com o Rafael para estudar Algoritmos e Estruturas de dados, foi um período incrível das nossas vidas, a gente desafiava um ao outro constantemente.

O momento mais marcante de 2019 foi em Julho, quando eu decidi fazer um movimento ousado, mesmo não me considerando bom o suficiente (olá de novo síndrome do impostor), eu me candidatei em uma posição na empresa que sempre sonhei trabalhar.

Você pode notar que desde o início da minha carreira eu sempre tive uma influência muito forte da Microsoft ( MIC, MSP... ), então foi completamente natural desenvolver o sonho de trabalhar lá um dia. Eu passei no processo e no final de 2019, eu recebi a oferta. Foi definitivamente um dos momentos mais felizes da minha vida, eu não sabia nem o que fazer de tanta felicidade.

2020, 2021

Novamente anos de muitas mudanças, me mudei para Praga, comecei a trabalhar na Microsoft no time do FluentUI, fiz muitas contribuições open source, aprendi muito mas muito mesmo com o time incrível no qual eu fui colocado, pandemia veio e pedi transferência para o Brazil até a pandemia oficialmente acabar... Eu acredito que vou precisar de um artigo separado para compartilhar essas experiência sensacional de trabalhar em uma big tech com pessoas incríveis e com a sensação de aprendizado diária. Isso vai ficar para próxima então, mas você pode me acompanhar e ver minha jornada me segundo no Instagram, Github

Building and publishing your first NPM package

Charles Assunção — Fri, 18 Sep 2020 13:46:14 +0000

You have created a new reusable piece of code and want to share it with everyone or maybe you just have an idea that can be useful in different projects. But you are completely lost about how to start to code and create a npm package or even how to publish the code you already have.

I've been there, I created some small packages such as ICollections, Ngx-indexed-db, React-indexed-db and now I want to help you to create and publish your first package. This tutorial will be exclusively focused how to create a simple package, I will not be covering several things a project can benefit from, such as use of TypeScript, semantic-release, CI, and etc.

We will build together a custom hook for React that can be very useful in daily basis, a simple toggle state. If you are not familiar with React Hooks, check this link: React Hooks Docs.

The idea is to be able to install the package via NPM running

npm install useToggle

And then use it in any project as in the code bellow:

import React from 'react';
import useToggle from 'useToggle';

const App = () => {
  const [isLoading, toggleLoading] = useToggle(true);
  return (
    <div>
      <button onClick={toggleLoading}>Toggle</button>
      {isLoading ? <div>loading...</div> : <div>Content</div>}
    </div>
  );
};

export default App;

Let’s start creating a folder I will name useToggle, navigating to inside the folder and initializing it as a npm package.

Run the following commands in your console:

mkdir useToggle // to create the folder
cd useToggle // to navigate inside the folder
npm init // to initialize the the npm inside the folder

When we run npm init we have to answer some questions that should be straightforward. Here is my final result for this last command:

{
  "name": "usetoggle",
  "version": "1.0.0",
  "description": "React hook to facilitate the state toggle",
  "main": "lib/index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [
    "react",
    "hooks",
    "toggle"
  ],
  "author": "Charles Assuncao",
  "license": "ISC"
}

Installing the dependencies

We are going to need some things to create the project, let’s install it via npm:

We are going to need useState from react for the package to work, so let’s install it as normal dependency

npm install react

We are going to use babel here to transpile and minify the final code:

npm install --save-dev @babel/core  @babel/cli  @babel/preset-env babel-preset-minify

Notice that this time we passed the flag --save-dev to signalize that this dependency are only needed to develop our code but it’s not a dependency to the package to work.

We want to test our code and be sure everything works as expected, remember: not tested code is broken code! Since we are creating a custom hook we will need React Hooks Testing Library

npm install --save-dev jest @testing-library/react-hooks react-test-renderer

Hands-on, Let’s code!

Writing tests

Let’s start writing tests and caring more how we expect our code works. Test Driven Development has several advantages and I definitely recommend a deeper reading about it.

Create the folder where we are going to keep our code:

mkdir src

Create three new files inside this folder:

index.js

useToggle.js

useToggle.spec.js

Our project now looks basically like this:

├── package-lock.json
├── package.json
├── node_modules
├── src
│   ├── index.js
│   ├── useToggle.js
│   ├── useToggle.spec.js

Since we installed jest to run our tests we need now to create a test script in our package.json

"scripts": {
    "test": "jest"
}

I love this simplicity of jest, needless configuration. Now we are able to run npm run test to execute our specs files. Let’s create our first test then:

//useToggle.spec.js

import { renderHook } from '@testing-library/react-hooks';
import useToggle from './useToggle';

describe('useToggle Hook', () => {
  test('Should initiate with false as default', () => {
    const { result } = renderHook(() => useToggle());
    expect(result.current[0]).toBe(false);
  });
});

What is happening here?

We create a test suit for our Hook ‘useToggle Hook’ and our first test is to check the default value initialized in our hook. renderHook execute our hook and return an object that contains the hooks returned value inside of result.current. In our case our hook will return an array with the state value and a function to mutate the state. So basically:

result.current[0] // is our state, by default false
result.current[1] // is the toggleState function

If we run npm run test now our tests will be red. Because we don’t have anything inside the useToggle.js file. So let’s create a simple function that will make our test turn green:

//useToggle.js

export default function useToggle(initialState = false) {
  return [initialState];
}

Run the tests now and see it green as the happiness 

Our function is already returning array having the default initial value as false. Let’s think and create some more tests of how we expect our hook to work:

//useToggle.spec.js
import { renderHook, act } from '@testing-library/react-hooks';
import useToggle from './useToggle';

describe('useToggle Hook', () => {
  test('Should initiate with false as default', () => {
    const { result } = renderHook(() => useToggle());
    expect(result.current[0]).toBe(false);
  });

  test('Should initiate with the provided value', () => {
    const { result } = renderHook(() => useToggle(true));
    expect(result.current[0]).toBe(true);
  });

  test('Should toggle the value from false to true', () => {
    const { result } = renderHook(() => useToggle());
    act(() => {
      result.current[1]();
    });
    expect(result.current[0]).toBe(true);
  });
});

The first two tests will pass, our useToggle function is returning an mock of the state that fulfill the requirements for the two initial tests. But our hook doesn’t make anything happen actually. So let’s change this and make our tests run green again.

import { useState } from 'react';

export default function useToggle(initialState = false) {
  const [state, setState] = useState(initialState);

  function toggleState() {
    setState(!state);
  }

  return [state, toggleState];
}

We imported useState from react and we are using it to hold our initial value and to change it through the function setState but instead of returning the setState function we create a closure that toggles the state value behaving as we expected.

Run the tests now and see your console sparkling joy with all tests passing. But, let’s create some more tests just for fun. The final test file will be something like this:

import { renderHook, act } from '@testing-library/react-hooks';
import useToggle from './useToggle';

describe('useToggle Hook', () => {
  test('Should initiate with false as default', () => {
    const { result } = renderHook(() => useToggle());
    expect(result.current[0]).toBe(false);
  });

  test('Should initiate with the provided value', () => {
    const { result } = renderHook(() => useToggle(true));
    expect(result.current[0]).toBe(true);
  });

  test('Should toggle the value from false to true', () => {
    const { result } = renderHook(() => useToggle());
    act(() => {
      result.current[1]();
    });
    expect(result.current[0]).toBe(true);
  });

  test('Should toggle the value from true to false', () => {
    const { result } = renderHook(() => useToggle(true));
    act(() => {
      result.current[1]();
    });
    expect(result.current[0]).toBe(false);
  });

  test('Should execute multiple toggles', () => {
    const { result } = renderHook(() => useToggle()); //init false
    // false -> true
    act(() => {
      result.current[1]();
    });
    // true -> false
    act(() => {
      result.current[1]();
    });
    // false -> true
    act(() => {
      result.current[1]();
    });
    // true -> false
    act(() => {
      result.current[1]();
    });
    expect(result.current[0]).toBe(false);
  });
});

Last but not least, we should export our hook from our entry point index.js. Only one line will do the job:

// index.js

export { default } from './useToggle';

Building

Let’s configure the build script, we are going to need babel for that. So let’s create a babel configuration file (babel.config.js). Our configuration should be damn simple:

//babel.config.js

module.exports = {
  presets: ['@babel/preset-env', 'minify'],
};

And create a build a build script inside our package.json:

"scripts": {
    "test": "jest",
    "build": "babel src --out-dir lib"
}

Now we can run npm run build and it will generate the lib/index.js file.

Publish

We need to make small changes in our package.json in order to publish it. Let’s configure the files that should be included in the package and a special script that will run every time when we try to publish the package. Also, we are going to change the react dependency to be a peerDependency, since we are expecting the project using our package already has its own react version:

"files": [
    "lib"
  ],
  "scripts": {
    ...
    "prepublish": "npm run build"
  }, 
  . . .
  "peerDependencies": {
    "react": "^16.9.0"
  },

Run npm login and use the credentials that we created in the npm site previously. After successfully login you can run now npm publish. Now your package lives in the wild world of npm packages and can be used for anyone only running npm install useToggle

The code review we deserve

Charles Assunção — Fri, 11 Sep 2020 07:23:01 +0000

Code review is the process of evaluating a team member's code, usually done in the form of a pull request before the code get merged into the main project branch, or by going directly to the codebase. It's one of the tasks which requires more of a balance between soft skills and coding skills. Code review brings us a lot of benefits and a result better final product. When doing code review, we usually aim to:

Ensure readability

How can I know if my code is readable? The answer is quite obvious, show your code to someone else and ask if this person can understand what is happening and if everything is crystal clear. It’s important to remember that we write code for other people to read, maintain, and use.

Ensure a good architecture

Projects should have standards regarding code styles, formatting, name conventions, and several patterns. While doing the code review, one crucial aspect is to be sure if the patterns were respected, and the code is consistent with the application.

Share knowledge

It's one of the most significant advantages of code review. During the code review, people have an excellent opportunity to learn and share what they know. It's a perfect moment to initiate a conversation about points in the code you haven't clearly understand. It doesn't matter if you are doing the code review or your code is passing for a review; it's a great learning moment.

Avoid bugs

Usually, the code review's primary goal is to ensure the development of a bug-free application. The only consideration here is not to make this the only thing in the checklist while doing a review.

Code review brings a significant improvement to the code quality and the team's growth. However, it's not always so simple, and discussions can get so intense that might seem like a civil war from the comics.

How can we make the code review more enjoyable, create the mindset to take advantage of it and avoid a drama novel in the team?

Developers want to be proud of their code; after all, it's a creative work, it's our art. To accept criticism and consider that we may have to rewrite 10 lines of code, because someone else found a better way or it makes more sense inside the application architecture, can hurt our pride. So this is the reason why it's so vital for us to try to have the skill known as "Egoless Programming.". Be able to code, leaving your ego aside is one of the most important things you can do.

Jerry Weinberg described "The 10 commandments of egoless programming" in his book The Psychology of Computer Programming. Although it is an old book, it's as contemporaneous as any JS Lib just created.

The 10 commandments of egoless programming:

Understand that you will make mistakes. The goal is to identify potential problems before it has a chance to break your production app. Except by the ones who write code to rockets or cars, mistakes are rarely fatal in programming, so we can and we should, always learn, laugh, and move on after fixing the problem.
You are not your code. Remind yourself that one of the goals of the review is to identify bugs or pitfalls, and they will be found. Don’t make it personal if someone points a mistake in your logic.
Doesn’t matter how much “karate” you know, there is always someone who knows more. So if you are humble enough to ask, this person can teach you some cool techniques. Try to understand and to get new ideas from your colleagues, especially when you have no idea how to solve something.
Don’t rewrite someone else's code without talking with him before. There's a fine line between fixing something and rewrite the entire code. Know the difference and try to understand what the person thought when writing the code, don't play the lonely sniper who tries to save everyone from a far distance.
Treat the people who don't have the same knowledge that you do with patience and respect. It's common knowledge that developers are at the best egocentric; Being harsher, people believe we feel like we are a kind of superior race with a better understanding of everything. Do not contribute to this stereotype with angry behavior and lacking patience.
Change is the only constant. Accept the change with a big smile on your face. Face requirement changes or design challenges as an opportunity to improve and do things better, and enjoy the process.
Knowledge should be the authority, not someone title. Knowledge is what gives someone authority and builds respect. If you want to be respected, use your knowledge in your argument, not your Senior title.
Fight for what you think it’s right, but accept the occasional defeat. Understand that sometimes, even if your idea is the best it might get rejected. When this happens, and in the further, the team realizes that, don't be the guy saying: "Aha, I told you from the beginning."
Don’t be the “guy in the room.” Don't be that isolated guy in the darkroom that only goes out to grab a coffee — the untouchable guy, with headphones that comes and goes like a spy.
Critique the code, not the person — Be gentle with the person, not with the code. Try your best always to make valuable and helpful comments contributing to others improvement and aiming to make together a better product. Connect your comments with some pattern mismatch, erroneous requirements, or performance issues.

Knowing these 10 commandments, I want to add some personal tips I learned in my last years working with international teams and being responsible for code reviews.

From the moment you do a code review, you are also becoming that code's owner.

You become forever responsible for the code you review, as much as the code written by yourself.

If a bug is unnoticed by you, you can't point fingers saying: "That person screwed up." It's your mistake as well.
When making comments, try to replace:

Shouldn’t you use the X function in this case?

For:

Shouldn’t WE use the X function in this case?

When requesting for changes in someone code, question the person her thoughts regarding the proposed change. Allow the code's author to explain their reasons behind that code.
Don't jump into conclusions, an indentation that's not following the standard is most like to be a non-intentional mistake. So, kindly remind the person, and don't point fingers saying he is trying to adopt something different.
Make use of examples. You can write code in a comment, did you know? :).
Code example makes it easier to understand rather than arguing about why it should be an array.map and not an array.forEach.
When requesting someone to review your Pull Request, make sure it's not the entire feature you have been working the last 2 weeks and now has 129308 files changed.
Say "thanks" when something is improved, recognize it, and incentivize when someone is doing something neat. ( USE GIFS IF POSSIBLE :D )

I believe these ideas can contribute to a better team, which is beneficial for the entire company. The intention is to create a team working as a unit and having a process that can make people grow naturally in your company. Last but not least, I want to point out some hand-on ideas that can help you make all the development process more efficient:

Automate everything! Tasks like lint, formatting, or code style checking. I work with TypeScript using TSLint with prettier running pre-push hook to check all the changed code and be sure everything is still ok.
Everyone in the team should be part of the code review. Remember, the goal is to make the team grow. Don't nominate 2 or 3 seniors as the "king of review."
If there's no agreement regarding a feature implementation, involve a new person in the discussion in the form of a "judge." Accept the decision of this new person and move on.
Don't just look at the Pull Request! Checkout to the branch, use it, test it, see the code working. Be sure there are no runtime errors and all behaviors are working as expected. You can maybe understand new code, but you can only be sure there are no bugs if you test it. Remind yourself: The code is your responsibility as well.

That's all folks, a small part of what I have learned in my last years.

Data Structures as Hooks, a guide: Linked List

Charles Assunção — Sun, 06 Sep 2020 15:00:50 +0000

“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” — Linus Torvalds

I love algorithms and data structures, back in the days, during college, I used to be an assistant teacher of data structure subject that basically required from me to help new students to understand the material given by the professor and also assist the professor on correcting students exercises ( If you want to know more about my background you can check the post about my decade review ). I also used to enjoy spending my free time playing with friends on clash of code.

I know, quite a nerd 🤓. So in a way to revive this old pleasure, I decided to create a series of posts implementing data structures in Javascript and to make it more fun and more in the hype let's do it in a form of Hooks for React 😎

We gonna cover a lot of different data structures but I wanted to start with one of the most common: Linked List.

Linked List

For the ones not familiar with what is a list let's check what Wikipedia says:

In computer science, a list or sequence is an abstract data type that represents a countable number of ordered values

If that doesn't help, you can just imagine a sequence of data that is linked from previously to the next one, for example, imagine a list of numbers:

1 -> 2 -> 3 -> 4 -> 5 -> null

We gonna call each number in the list node, and give special name for the last one that we will call it tail.

All the code that we will go through here is available in this CodeSandbox. Together with one small application to play and visualize our work.

Enough theory, let's do some work...

DISCLAIMER: The goal here is to be more instructive aiming beginners, so I am aware the code is not production quality. I am avoiding some javascript magic and things like recursion to keep it as simple as possible ;)

API

We want to achieve an API close to the following code example:

const { 
    list,
    tail,
    size,
    add,
    remove,
    removeAt,
    indexOf,
    dataAt, 
} = useList();

And our list is just a sequence of nodes so we need something to represent it. Let's define it to be used like this:

const node = new Node(1); // 1 or any other data type that will be kept in your list

Building blocks

Node

Our list will be built with nodes and we gonna be operating our functions on nodes so makes sense for us to build Node representation as to the first thing...

function Node(data) {
  this.data = data;
  this.next = null;
}

// Let's test it 

const node = new Node(1);
console.log(node); // { data: 1, next: null }

Actions

We are going to be using a simple reducer with React.useReducer to manipulate the list and for that to work the best we should have a clear idea of which actions should be possible to be dispatched, so let's define them:

const actions = {
    ADD: '[LIST] - ADD',
    REMOVE: '[LIST] - REMOVE',
    ...
}

The hook

Our hook is a pretty simple function that keeps the state using the React.useReducer and expose some functions to manipulate, so we gonna start with something close to:


export function useList() {
    const [{ list, tail, size }, dispatch] = useReducer(listReducer, {
         tail: null,
         list: null,
         size: 0
    });

    const add = (data) => {
        dispatch({ type: actions.ADD, data });
    }

    ...

    return { add, ..., list, tail, size }
}

Reducer

We need to define our reducer, it will be fairly simple basically containing the state manipulation for the actions we defined previously.

const listReducer = (state, action) => {
    switch (action.type) {
        ...
        default:
            return state;
    }
};

Base methods

We are going to need some functions to be able to execute operations on the list, so let's start constructing some of them:

`add`

We want to be able to add new nodes in the list and has I said before we are will keep the reference of the tail this makes the add operation pretty fast being O(1) 🤟🏻. Our function is going to receive the data to be added, the current list and our current tail.

const add = (data, { list, tail, size }) => { ... }

We want to check first if we already have something in the list or if we are adding the first. If it's the first element we should make our list to be the new node and in this case our tail will also be pointing to the first node. So our condition will be like:

if (!list) {
    let newList = new Node(data);
    let newTail = newList;
    return { list: newList, tail: newTail };
}

If we already have something in the list, means that we should add something after the tail ( that is always pointing to the last element ) and then make the next element after the tail my new tail. Putting all this together our add function will be looking like:

const add = (data, { list, tail, size }) => {
    if (!list) {
        let newList = new Node(data);
        let newTail = newList;
    return { list: newList, tail: newTail, size: size + 1 };
    } else {
        tail.next = new Node(data);
        tail = tail.next;
        return { list, tail, size: size + 1 };
    }
};

We need to add our work now to the reducer.

case actions.ADD:
    return { ...state, ...add(action.data, state) };

`remove`

This one will seem like a bit more complicated but don't worry, it's just a few lines more of code and we can handle it. So buckle up and let's think about what should happen...
We can only remove a node if our list is not empty so all our work will be inside this condition:

const remove = (data, { list, tail, size }) => {
    if (list) {
        ....
    }
}

If we are trying to remove the first node we just make our list to start from the next one and if now our list is empty we should care about cleaning our tail as well.

if (list.data === data) {
    const newList = list.next;
    return { list: list.next, tail: !newList ? null : tail, size: size - 1 };
}

If that wasn't the case we should iterate through our list and find the node we want to remove. Let's say we want to remove node X, we start to look into the list and once we find it we need to make the previous node to point to X.next and not to X anymore. Let's look into the code:

    // We are going to use this to iterate through the list
    let currentNode = list;
    // Let's keep a reference to the previous node
    // So we can change to where it's pointing when we find
    // our node
    let prev = null;
    // Let's "walk" through the list until we find the 
    // node to be removed or we reach the end
    while (currentNode.data !== data && currentNode.next) {
        prev = currentNode;
        currentNode = currentNode.next;
    }
    // if the current node is the node we want to remove...
    if (currentNode.data === data) {
        // Let's first consider if we are trying to remove 
        // our current tail and if so our tail will be our 
        // previously node
        if (currentNode === tail) {
            prev.next = null;
            tail = prev;
        } else { 
            // else we just make our prev node point to
            // the next after our current
            prev.next = currentNode.next;
        }
        return { list, tail, size: size - 1 };
    }

In the end this is our remove method:

const remove = (data, { list, tail, size }) => {
    if (list) {
        if (list.data === data) {
            const newList = list.next;
            return { list: list.next, tail: !newList ? null : tail, size: size - 1 };
    } else {
        let currentNode = list;
        let prev = null;
        while (currentNode.data !== data && currentNode.next) {
                prev = currentNode;
        currentNode = currentNode.next;
        }
        if (currentNode.data === data) {
            if (currentNode === tail) {
            prev.next = null;
            tail = prev;
        } else {
            prev.next = currentNode.next;
        }
        return { list, tail, size: size - 1 };
        }
    }
    }
};

It's a bit more complicated because we are keeping track of the tail but it's a price worth paying :). In our worst-case in this method we will be looking into all nodes of the list to find or not the node we want to exclude so our method is O(N) 🤷🏻‍♂️.

Let's just add our method to our reducer and we are done here:

    case actions.REMOVE:
        return { ...state, ...remove(action.data, state) };

`indexOf`

We want sometimes to find out if a specific data is present in our list and if so retrieve its index, for that let's implement indexOf method. Our list will be 0 index based ( like an array ). What we need to do is to "walk" through the list till we find our node and return it's index if we don't find we return -1. The entire method will be pretty straightforward and we don't need to add it to the reduce since we are not mutating any state. So let's check it:

    const indexOf = (data) => {
        // We gonna start from index 0
        let currentIndex = 0;
        let currentNode = list;
        // While we still have a node to navigate and 
        // we haven't find our node yet keep looking
        // and incrementing the currentIndex
        while (currentNode && currentNode.data !== data) {
            currentNode = currentNode.next;
            currentIndex++;
        }
        // Did we find the data? If yes, return the index
        // if no return `-1`
        return currentNode?.data === data ? currentIndex : -1;
    };

Just one last note about this: In order to find our data we might have to look into all nodes so this makes our indexOf O(N)

`revert`

This is a common and nice interview question, it's very nice to solve it using recursion but let's keep it simple and do it iteratively. We will have to touch each node changing it's next property, this makes this method also O(N) The goal here is to revert the list so if we had:

1 -> 2 -> 3 -> null

after reverting we should have:

3 -> 2 -> 1 -> null

So the first thing as in some previously methods is to check we do have a list to work on and if so we gonna keep track of the current node and the previously node. While we have nodes to go we keep swapping our previously with our current. So let's see how it looks like:

const revertList = (list) => {
    if (list) {
        let prev = null;
        let currentNode = list;
        // Let's not forget we should be careful 
        // with the tail
        let tail = null;
        while (currentNode) {
            // Save the rest of the list for now
            let restList = currentNode.next;
            // make our current node point to what was prev
            currentNode.next = prev;
            // replace our prev with the current
            prev = currentNode;
            // and if our prev is pointing to null 
            // it means it's our new tail
            if (prev.next === null) {
                tail = prev;
            }
            // grab the rest of the list to continue doing
            // the same process
            currentNode = restList;
    }
        return { list: prev, tail };
    }
};

We just need to add it now in our reducer:

    case actions.REVERT:
        return { ...state, ...revertList(state.list) };

`stringify`

Last but not least, we want to be able to visualize our own list right? Let's create a very simple method that will iterate through the list and combine with the power of the arrays to not have to care about when applying the "next" indicator or not.

    const listDataArray = [];
    let currentNode = list;
    while (currentNode) {
        listDataArray.push(currentNode.data);
        currentNode = currentNode.next;
    }
    return listDataArray.join(' -> ');

That is it, folks, we sure can have more fun with the list data structure and implement many other methods to play with it ( I even implement some more in the CodeSandbox ) but I think this is long enough already and we already have some good idea how it works right?

So let me know in the comments if you still have any doubts if something wasn't clear for you and tell me which data structure you would like to see in the next post 😁

Powerful unknown web APIs

Charles Assunção — Sun, 30 Aug 2020 13:13:38 +0000

We are constantly manipulating the DOM and working with it as front-end developers, the thing is we know many of the common methods available but there are so many web apis out there that are powerful but barely known by everyone, so let me share a few of them with you :)

`nodeA.compareDocumentPosition(nodeB)`

This is a very cool method that allows you to understand better the current structure of your DOM. Sometimes you need to know where the node you are working with is placed in the DOM or you need to have more control how you apply changes to specific node, using this method you can do it with some sort of safety.
This method will return a bitmask informing you the position of the nodeA compared to nodeB, the possible values are:

Name	Value
DOCUMENT_POSITION_DISCONNECTED	1
DOCUMENT_POSITION_PRECEDING	2
DOCUMENT_POSITION_FOLLOWING	4
DOCUMENT_POSITION_CONTAINS	8
DOCUMENT_POSITION_CONTAINED_BY	16
DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC	32

You can see some quick usage and try to understand it a little better having a look into this small CodesandBox

One last great thing about this one is that has a excellent cross browser support. 🥳

`node.contains(anotherNode)`

following the previously method, one of the most common comparison is if a certain node is inside another. So imagine the following HTML:

<div id="container">
    <div>
        <span id="user-name" />
    </div>
</div>

And you want to make sure that <span id="user-name /> is inside the container div. Using the previously method you could do something like:

const container = document.querySelector('#container');
const userName  = document.querySelector('#user-name')
if(container.compareDocumentPosition(userName) & Node.DOCUMENT_POSITION_CONTAINS){ 
 console.log(`container contains userName`);
}

But this is so common need that we got a easier way to achieve the same by using:

const container = document.querySelector('#container');
const userName  = document.querySelector('#user-name')
if(container.contains(userName)){ 
 console.log(`container contains userName`);
}

`node.isEqualNode(nodeB)`

This one is very straightforward by its name, you can compare if 2 node are equivalent, not necessary if the are the same. So if we have the following HTML:

<h1>Hello World!</h1>
<div>
  <div>
    <h1>Hello World!</h1>
  </div>
</div>

And if we compare like this:

const nodes = document.querySelectorAll("h1");
console.log(nodes[0].isEqualNode(nodes[1])); // true

This will compare the node content, attributes and type to check if they are equivalent, so this means that a small change like adding an id to one of the nodes would be enough to return false in the comparison.

`node.replaceWith()`

This one seems like a little magic 🧙🏻‍♀️, it allows you to get one node remove it from the DOM replacing it by a entire new node.

Let's see how it works in the following HTML:

<div>
  <div>
    <h1 id="nodeB">NODE B</h1>
  </div>
</div>

If we execute this lines of javascript:

const nodeB = document.querySelector("#nodeB");
const nodeC = document.createElement('h2');
nodeC.textContent = 'Node C';
nodeB.replaceWith(nodeC)

Like magic our current DOM will be:

<div>
  <div>
    <h2>Node C</h2>
  </div>
</div>

I hope you have seem something new here today, let me know in the comments if you already knew all of this or if you learned something new 🙂

Almost a decade review

Charles Assunção — Sun, 23 Aug 2020 09:04:44 +0000

Recently I visited my hometown and had the opportunity to give a short talk about my career talking about challenges and my experience during few years on IT. Inspired by this talk and after reading Dan Abramov's Decade Review I thought about making my own Decade Review, but this thought didn’t last long when considering I never saw one line of code in my life before 2nd semester of 2013. So, Let’s start there.

June, 2013

I was already one year after finishing High School and I was 19 years old, as any young person I was suffering some pressure to go to college and find a career to myself. The problem was I had no clue about what I wanted, I came from a family of police and lawyers and although I enjoyed to study law it was far from what I wanted as profession.

In June of 2013 it was happening in my city an event named AppWeen, with a funny proposal: Put together developers using costumes between 00:00 to 06:00am to code Windows 8 Apps. I was always into computer and technology, fixing some stuff by myself and disassembling my old desktop several times when I was teenager but I had never had contact with code, if you would ask me at that time I would say it was something for super math genius, but I decide to go and check this event.

I contacted the Microsoft Student Partner behind the event and explained my lack of knowledge and asked if I still could go. He was very supportive and thanks God I decide to go even with doubts about, it was an incredible experience and I met some nice guys from the IT University who talked with me about the course, job market and answered lot of my questions. I made some friends that day, drunk a lot of Red Bull and even do the Harlem Shake:

(Yes, I am this guy spitting card in the end of the video)

Few days later I signed up myself to the University and did it in time to start yet in August of 2013. From June to August I studied all materials the people recommended me in the event so I would know at least the very basic when the classes started. There’s a lot of discussion if university is really necessary or not for developers, well, I am not getting into this here but I feel like in debt with some amazing teachers I had and I learned how to code starting in the university.

Three months studying already and I was already looking for some internship, trying to have something to put hands on and I have to admit I feel really blessed by God, even being in the very beginning I passed in the process for internship in the Microsoft Innovation Center based in other campus. It was a program to develop new ideas for 3 months with all orientation from more senior guys and researches, there I had my first contact with web technologies (Asp.net and JQuery).

2014

I had just completed my 3 months at Microsoft Innovation Center and was starting my 2nd semester in the university. Few months in 2014 the coordinator of my course recommended me for an internship position at TecMidia, a company which developed software for newspaper industry, I started there working with C# and learning a lot of things, everything was new for me and even though I was afraid to not be good enough ( hi impostor syndrome ), the excitement for a new position and having contact with the real world of a develop was even bigger. It wasn’t easy to synchronise my student life with my internship, I lived and studied 25 km far from the company and public transportation is very poor in Brazil, but it was definitely worth.

Yet in the beginning of my 2nd semester I got selected for the position of Monitor of Algorithm, given my high grade on the subject in the first semester. Basically, what I would do was to be 1 hour early every day at the university to be ready to help any student struggling with the subject and also help the professor to correct some exercises. For the next 4 semesters I had the honor to stay as Monitor and help the professor, it was definitely a very nice way to no keep all the theory from the beginning fresh in my mind.

2015

It was a great year for me, I was still Monitor in my university and intern at TecMidia, although I was working in web projects now with Asp.net. Do you remember I told you I made some good friends in that event back in 2013? So, one of them was the guy organizing the event, Now he was the Microsoft Student Partner Lead responsible for my state, we keep in touch since that event. In 2015 he recommended me to the Microsoft Student Partner program, when I got accepted was like if I had reached the stars, together with him I would be sharing my knowledge and experience with the community and we did our best, making event and talks in several cities, participating of events and meeting so many nice people in this journey.

2016

I think was the year we traveled the most for MSP events and talks, I definitely lost the count of how many kilometers we traveled ( Remember Brazil is huge, so 3 hour drive is almost considered neighborhood :P ).

In the end of the year I was invited, together with others MSP, to go to the Microsoft in São Paulo to watch an event about the Imagine Cup in which the Satya Nadella itself would be there. I don’t even need to say it was an incredible experience, right?

2017

I was now a Jr Developer at TecMidia for almost a year and I learned that I really liked web technologies and was really focusing on that it was then that I got an offer from a Fintech in my city with a really nice proposal: To make the financial market accessible for everyone. They offered me a frontend developer position, I was the 3rd member of the very new team of “frontenders”.

( Designers and Devs having lunch in peace :P )

I had just joined one of the richest experiences I ever had, I would need to write a whole new article about everything I learned at Toro Investimentos, was my first experience focused in Front-end, working with designer in a scrum team and with a mission that I could relate with. I learned a lot about technical stuff and about working with a team, I am eternally grateful for having such amazing people to help me become a better professional there. ( Thanks Helena and Fabricio for the patience with me :D )

I was there in the very beginning typing the “ng new” command of what would become the Toro Investimentos, so you can understand how I still feel so proud of what we have built there when I see any news about the company.

2018

It was definitely the year with biggest changes in my life, till there I had never been abroad, I didn’t even have a passport and yet couple of months into 2018 I passed in the process for a company in Warsaw, Poland. I couldn’t believe myself, with my broken English I managed to get through the process, it wasn’t easy. But I got there.

I was going at Credit Suisse as a contractor from SII Poland, big company, new country, new culture, new challenges, new friends… Far from family, far from old friends… It wasn’t easy to adapt.

Thanks God I made such good friends here, I very soon was travelling a lot with Pawel, Karol and Rafael. I even managed to convince Karol, who was my manager, to visit Brazil with his girlfriend. Rafael and I used to go a lot for coffees and sit down in some random Starbucks to code or study. Life got easy with these friends here, time passed fast. It doesn’t seem like I am here 2 years already.

2019

In the very beginning of 2019 I got hired as a perm for Credit Suisse. I was now a Senior Software Engineer and worked in some different projects there. Early in 2019 I started to work in a project with a team based in New York, what was quite an interesting experience to communicate with them due time zones.

Meantime I was going to coffee places almost every day together with Rafael to study Algorithm and Data Structures, it was a nice period of our lives, we keep challenge and helping each other.

The most remarkable thing about 2019 is that in July I made a bold move and even not considering myself good enough ( hi again impostor syndrome ) I applied to a position in a company I always dreamed to work on.

You can notice my career since from the beginning had a strong influence from Microsoft, so nothing more natural than the fact I always had the dream to go work there someday. I made through the process and at the end of 2019, I got the offer, I think was one of the happiest days of my life. I didn’t know where to put myself with so much joy the day I got the offer.

2020

So the year is just beginning and big changes are to come, I am soon moving to Prague and starting my new journey at Microsoft so I am sure many exciting things are to come so if you want to follow me in this new phase of my life you can follow me at Instagram, Github or Twitter and you can reach me any time to a chat or even ask about some JS weird stuff that I might be of help.

I hope you have enjoyed the read, let some comments bellow. :)

Async/await can still surprise you... A LOT!

Charles Assunção — Wed, 19 Aug 2020 17:49:44 +0000

I love technology ❤, and the fact that it doesn't matter how much we know there will always be something to amaze us. Today a friend of mine (@Rafael_Toscano) showed me something that my instant reaction was like this:

He shared with me an article from the V8 blog about "Faster async functions and promises." and among all sort of exciting things, one captured my attention in a way that I could only think "This can't be real, I have to test it."

It regards the async/await behavior and the fact you can use async/await with any "thenable" function. What does it mean? Any object which has a ".then" method can be used with async/await.

In the article, he gives the following example:

class Sleep {
  constructor(timeout) {
    this.timeout = timeout;
  }
  then(resolve, reject) {
    const startTime = Date.now();
    setTimeout(() => resolve(Date.now() - startTime),
               this.timeout);
  }
}

(async () => {
  const actualTime = await new Sleep(1000);
  console.log(actualTime);
})();

Yes, please tell me I am not the only one whose mind was blown by seeing that.

I think this helps us understand a little bit more about async/await functions and the possibilities of things we can do in our code. But also it comes with great responsibility, please don't replace simple promises everywhere by this only because it feels nice.

Only use it if you can find exceptional use cases, and if you do, please share it with us in the comments. I do love to hear about it! I'm considering if to implement a "retry strategy" wouldn't be a good opportunity for this use as following the idea in the bellow code.

const ServerMock = {
  count: 0,
  getData() {
    if (this.count === 2) {
      return Promise.resolve([{ name: "SomeName" }]);
    } else {
      this.count++;
      return Promise.reject("Error");
    }
  }
};

function fetchData(limit, time) {
  return {
    then(resolve, reject) {
      const retry = setInterval(async () => {
        limit--;
        try {
          console.log("Trying....");
          const data = await ServerMock.getData();
          if (data) {
            console.log("Resolve");
            clearInterval(retry);
            resolve(data);
          }
        } catch {
          if (limit === 0) {
            clearInterval(retry);
            reject("Limit Reached");
          }
        }
      }, time);
    }
  };
}

(async () => {
  try {
    const result = await fetchData(3, 1000);
    console.log(result);
  } catch (err) {
    console.log(err);
  }
})();

Let me know what you think about it in the comments.

React.memo(use me wisely)

Charles Assunção — Sun, 16 Aug 2020 12:29:49 +0000

React.memo is fairly simple but misunderstood High Order Component. By the docs we get this definition:

If your function component renders the same result given the same props, you can wrap it in a call to React.memo for a performance boost in some cases by memoizing the result. This means that React will skip rendering the component, and reuse the last rendered result.

performance boost 🤩? WOW, so let's memoize everything!

⚠️ Calm down Sherlock, use it wisely.

Let's have a deep look at what is the magic happening inside memo first when I said it is simple, you will have to agree after looking into the code in the react repo. The entire code is basically this:

const REACT_MEMO_TYPE = Symbol.for('react.memo');

export function memo<Props>(
  type,
  compare?: (oldProps: Props, newProps: Props) => boolean
) {
  const elementType = {
    $$typeof: REACT_MEMO_TYPE,
    type,
    compare: compare === undefined ? null : compare,
  };

  return elementType;
}

So this means that when you use it passing SomeComponent as to it you get as return basically:

  {
    $$typeof: Symbol.for('react.memo'),
    type: SomeComponent,
    compare: compare || null,
  }

This means that if you want to use this directly you will get the same result, don't believe me? Try it out in this codesandbox.

You can notice that there's a second parameter for memo, a compare function. Let's look into the docs again:

By default it will only shallowly compare complex objects in the props object. If you want control over the comparison, you can also provide a custom comparison function as the second argument.

So this means that we can have the power to decide if the component should re-render even if the props might change. So let's say you never want your component to re-render again after the first time ( for whatever the reason you want to do that ), you can simply do this:

const MemoComponent = React.memo(({ name }) => {
  return <div>{name}</div>;
}, () => true);

⚠️ Notice that I am returning true in the compare function, I am basically saying that the meaningful previously props are the same as the next props so it should not re-render. ( It's basically the inverse of the shouldComponentUpdate )

So when to use it properly? Mainly you want to use it when your component is a pure functional component and/or it will always render with the same props and when you want to have control about if it should render or not. So, for example, imagine you have the following component:

const UserInfoHeader = ({avatar, name}) => (
    <>
        <img src={avatar} />
        <div>Hi {name}</div>
    </>
)

And you gonna probably use it inside some dashboard, this is perfect opportunity to use memo, your dashboard may rerender and change several internal states but very unlikely to change the name or the avatar source, so wrapping the UserInfoHeader with React.memo will avoid unnecessary renders here.

We have some better understanding now, but what is the problem if we wrap everything with memo? When it should be avoided?

Using memo unwisely can lead you to bugs hard to debug and to the false feeling to be improving the performance. The question then is when NOT to use React.memo?

1. Often props change

React.memo has the cost to compare the props every render and if your components are updating the props all the time you are likely to lose performance since normal components wouldn't care about it and would just re-render normally.

2. Compare function is too expensive

Let's say you have a complex object being passed as prop and you want to make a very expensive calculation comparing the previous object with the new one. Heads up here, you might be also decreasing the performance than simple just re-rendering always.

3. Components with that receive functions as props

This is not a don't but a be careful when using callbacks in memoized components, for example:

const Input = React.memo(...)

const App = () => (<Input onChange={(e) => { console.log(e) }} />)

In this case, the Input is going to be re-render all the time anyway because in each App render we will be redefining the onChange for the Input so either use static functions here or combine it with useCallback to prevent it to happen.

Wrapping up

React.memo is a powerful and easy to use HOC to gain performance but the misusage can backfire and actually harm the performance. Try to always be careful with it and use some profiling tools to make sure about the valid use cases.

Do you have an example of good usage for memo or have you faced some bug because of it? Share with us in the comments. :)

Leadership, a responsibility

Charles Assunção — Sat, 15 Aug 2020 14:59:33 +0000

Lead, Head, Manager, Principal. These are all very hyped positions nowadays. Sometimes it's only a facade to the old and known boss trying to look cool or even to feed someone's ego. In some exceptional occasions, it's the position held by someone who inspires others, make valuable contributions to the team and is capable of leading us to a better version of ourselves.

Let's try to go through the business context. People are the most significant resource of a company, those who dedicate themselves every day towards a common goal. The point missed sometimes is that the value these people are capable of creating is proportional to the quality of their environment, and in this scenario, the leader should be responsible for ensuring a fertile ground.

Leadership isn't about the professional title; it's about the responsibility

When we first start, in a Jr position, we are supposed to get the job done, learn a lot, and prove our value delivering results. Keeping up with the good work, we get promoted. Until one day, we land in a leadership position as responsible for the team and the people who now do our previous tasks.

The problem manifests when you are not ready for that, and the only way you know to prove your value is to "deliver results" or show numbers. Your focus stills merely in the number of closed tasks. Leaders shouldn't be strictly focused on these metrics. Leaders don't have a direct influence on the results; it's not something in their hands anymore. Leaders can influence the people, the ones which impact the results. Fail in understand what to focus on, and people might be more concerned about defending themselves than delivering some valuable results.

When someone asks, "What are the leader traits?" the cliche answer is always something like "charisma" or "vision". Many great leaders are not that charismatic or visionary. The non-negotiable leader characteristic is courage.

Courage, because it's hard to face the external pressure, it's hard to face a CEO or a client who wants everything in a short time and say "no" thinking about what is the best for the team. The courage we are talking about is not something hidden deep in your soul that you have to dig to find. It's something external; it's something that comes with the feeling that your team has your back.

How to measure leadership

Think for one minute about people going to the gym aiming to get fit. They go to the gym on the first day, work out, go back to their houses to look in the mirror, and boom... Nothing changed! They try it another day, work out again, look in the mirror and now... Nothing! However, if you keep going, with consistency, you will inevitably get in shape.

Leadership is about that, about consistency. You can't measure it in the short term, and this is one of the reasons why many managers keep making decisions based exclusively on numbers and forgetting about the people. It's only possible to measure the leadership results in the long run when the company has not only the results but also people who love their jobs, are engaged to the company mission, and are loyal.

The problem lies in the world's tendency to quantify everything and try to fit the leadership in an intensity measure. We can't expect to put someone in a 2 days course about leadership and magically have an inspiring leader.

Two workout days wouldn't help you to get in shape, and again the consistency is the key. Working out for a few hours every day will get you there. Taking small actions every day, even if it seems meaningless such as asking how someone is doing and caring about the answer is what contributes to make you a true leader.

Serving as a leader

Everyone likes to joke about the Alcoholics Anonymous first step that says, "first, you have to admit that you have a problem." However, it's the last step that may be the most important. Several studies show that alcoholics who followed all the steps except for the last one have a greater risk of drinking again.

The last step is to "help another alcoholic to overcome the addiction." It's not about you; it's about the other. It's not about how can you lose 5kg; it's about how you can help someone else get healthier. It's not about you becoming the most successful guy in the room; it's about the impact that you can have on other people's careers.

When we notice that our leader cares more about our life balance, our well-being, and our individual goals, then we want to bleed to propagate this leader’s vision and complete the mission at his side. It becomes a feeling of being part of something for the greater good.

Working hard in something we don't care about it's known as stress. Working hard for something we love, it's called passion.

Talking about passion, stop saying, "Here we only hire passionate people." Give people something to believe, space to make mistakes, and learn from it and the passion will naturally grow.

This article is a humble TL;DR from an interview with the fantastic Simon Sinek plus some personal notes. The interview is 1 hour long, but I can guarantee it's worth each second.

Underrated array methods

Charles Assunção — Sat, 15 Aug 2020 10:48:44 +0000

We are using arrays all the time every day when coding, probably the most used data structure. Who is working with Javascript is probably relying on many of its powerful array methods such as .map, .filter, .find, .some, .every, .reduce and others.
The thing is, array prototype in JS has many other very useful methods and some of them nearly unknown by most of the developers, so let's get into it:

`copyWithin(target, start?, end?)`

🙇🏻‍♂️ Heads up with this one, it's going to modify the original array and not return a new one

This method will copy elements to the target from start position until the end, sounds a little confusing eh?! Let's see some code then

let array = [1,2,3,4,5];
console.log(array.copyWithin(3, 1, 3)) // [1, 2, 3, 2, 3]

So what the heck happened here? Take the elements starting from index 1 untill index 3 and place them starting from the index 3. So let's see another example:

let array = [1,2,3,4,5,6,7,8,9,10];
console.log(array.copyWithin(0,5)) // [6, 7, 8, 9, 10, 6, 7, 8, 9, 10]

So here we are taking the elements starting from 5 until the end of the array and placing them starting from 0. So, in other words, we can understand it like:

array.copyWithin(Where the elements must go, where should it start copying from, where should stop to copy);

Let's see one more trick with it:

let array = [1, 2, 3, 4, 5];
array.copyWithin(2); // [1, 2, 1, 2, 3]
// If the target is negative it will copy starting from reverse
array = [1, 2, 3, 4, 5];
array.copyWithin(-2); // [1, 2, 3, 1, 2]

`lastIndexOf(searchedElement, toIndex?)`

This one is particularly very useful, let's see a simple example first:

const fruits = [
  'apple',
  'banana',
  'strawberry',
  'blueberry',
  'orange',
  'blueberry',
  'pineapple',
];

// It will log the index of the last occurency of 'blueberry'
console.log(fruits.lastIndexOf('blueberry')); // 5

At some moment you can want to look for the last occurrence only if it's before some specific index, so let's say for example:

const fruits = [
  'apple',
  'banana',
  'strawberry',
  'blueberry',
  'orange',
  'blueberry',
  'pineapple',
];

// You only wanted the last index of 'blueberry' if it was 
// between the 3 first elements
console.log(fruits.lastIndexOf('blueberry', 2)); // -1

But this method can become more interesting when you have more complex objects and you combine it with other array methods. Let's look into it:

const persons = [
  { name: 'Charles', age: 26 },
  { name: 'Marcos', age: 31 },
  { name: 'Jane', age: 22 },
  { name: 'Anton', age: 22 },
  { name: 'Eduardo', age: 22 },
  { name: 'Paula', age: 26 },
];

// We want to find the index of the last person 
// who is 22 years old, 
// unfotunately lastIndexOf doesn't accept a callback 
// so we gonna transform the array in array of ages that 
// match the index with the objects and find the last 
// occurence of 22
persons
    .map(person => person.age)
    .lastIndexOf(22); // 4

`reduceRight(callBack, initialValue?)`

This one is a little funny and very easy to understand, the signature is exactly the same as the original reduce methods and its behavior are quite the same with a small difference: instead iterate from left to right it will do it from right to left ( as the name make it very clear ) so let's jump in some simple example.

const numbers = ["1", "2", "3", "4", "5"];

console.log(
  numbers.reduce((acc, curr) => {
    return acc + curr;
  }, "")
); // "12345"

console.log(
  numbers.reduceRight((acc, curr) => {
    return acc + curr;
  }, "")
); // "54321"

This method is very handy when you want to express something from left to right but evaluate it from right to left, let's see a little more complex example:

const add10 = n => n + 10;
const divideBy2 = n => n / 2;

const commands = [divideBy2, add10];

console.log(
  commands.reduce((acc, curr) => {
    return curr(acc);
  }, 100)
); // 60

console.log(
  commands.reduceRight((acc, curr) => {
    return curr(acc);
  }, 100)
); // 55

I hope something here was new for you and you leave this post knowing at least a little bit more about javascript arrays. Let me know in the comments how do you liked it :)