Forem: Vinicius

Como configurar caminhos absolutos em sua aplicação.

Vinicius — Thu, 28 May 2020 13:50:54 +0000

Em nossa vivência de projeto, algumas arquiteturas de pastas favorecem nosso entendimento de cada módulo do projeto.

No entanto, algumas situações podem nos levar a caminhos extensos, de difícil entendimento e que necessitam obrigatoriamente de se guiar pelo intellisense do vs-code (ou algo similar).

import { Module } from '../../../Folder'

Situações como esta podem se tornar comuns e cansativas ao importar um módulo/componente. E é aí que entra a magia dos caminhos absolutos para importação.

Em nosso arquivo jsconfig.json (ou tsconfig.json pra quem usa TypeScript) - vale ressaltar, se você não tem este arquivo, basta cria-lo na raiz do seu projeto e voilá! - precisamos inserir uma simples regra:

{
  "compilerOptions": {
    "baseUrl": "src" // <- Este é o nosso cara.
  },
  "include": ["src"]
}

Modificando nossa baseUrl, podemos definir qual será o caminho para importação, mudando totalmente a forma como importamos componentes dentro da nossa aplicação.

A mesma situação apresentada anteriormente pode se tornar:

import { Module } from 'components/Folder'

Onde components é uma pasta diretamente ramificada de src.

Espero que este breve artigo sirva de algum auxílio!

Dissecando React - Parte 3: Funções, Classes e Props

Vinicius — Thu, 04 Jul 2019 02:10:22 +0000

Definindo um Componente

Componentes são, sumáriamente, um conjunto de nossos elementos que servem a um propósito final. São como funções, recebem algumas características e apresentam comportamento programável.

Todo o cerne de nossa aplicação gira em torno da composição de componentes, sua reutilização e seu comportamento e facetas por todo o projeto.

Neste texto, pretendo explicar e exemplificar as diferenças entre componentes declarados como funções, como classes e o que são props. Assim, daremos um primeiro passo em direção ao entendimento de estado e o ciclo de vida de nossos componentes.

Função ou Classe?

Podemos declarar um mesmo componente de duas grandes formas diferentes. Observe o código abaixo:

    const Introducao = (props) => {
        return <h1>Ola! Meu nome e {props.name}</h1>
    }

No trecho de código acima declaramos um componente, composto por um elemento que, com base nos textos passados, apresenta um valor variável props.name. Perceba que acessamos a informação name da mesma forma que acessaríamos o valor de um objeto.

A forma a qual declaramos o componente acima foi em formato de função. No caso, poderíamos também escrever:

    function Introducao(props) {
        return <h1>Ola! Meu nome e {props.name}</h1>
    }

A primeira forma que escrevemos se caracteriza como uma arrow function enquanto a segunda versão é uma função comum. Suas diferenças não cabem no momento, mas pretendo escrever sobre suas vantagens e desvantagens futuramente. De todo modo, na grande maioria dos casos, independente do uso, veremos os mesmos resultados em tela.

A outra grande forma de se declarar um componente é utilizando, e extendendo componente, em uma classe.

    class Introducao extends React.Component {
        render() {
            return <h1>Ola! Meu nome e {this.props.name}</h1>
        }
    }

Classes são como nossas funções de componentes, só que com esteróides. Elas trazem uma série de características adicionais. Anteriormente, somente classes eram capazes de alguns efeitos que hoje, com os Hooks , fizeram-se possíveis também nos componentes declarados por funções.

Mas isso é conversa pra uma outra hora.

Entendendo o que são props

Pra isso, precisamos entender que nossos elementos são representados por suas próprias tags. Vejamos o seguinte trecho de código:

    const BomDia = <h1>Ola, bom dia!</h1>

    const Introducao = <BomDia />

Chamando o elemento BomDia como um componente, posso invoca-lo e utilizar seu conteúdo a medida do que julgar necessário. É neste ponto que a componentização começa a fazer um incrível papel de reutilização e organização do projeto.

Consideremos o seguinte trecho de código como nosso exemplo:

    const Saudacao = props => {
        return <h1>Ola, {props.name}, tenha um otimo dia!</h1>
    }

    const BoasVindas = <Saudacao name="Julieta" />
    ReactDOM.render(
        BoasVindas,
        document.getElementById('root')
    );

No trecho de código acima temos um exemplo de como as props passam informações de componentes mais abrangentes para componentes mais específicos. As possibilidades são infinitas, levando em consideração que qualquer estrutura de dados pode ser o valor de uma prop.

Poderíamos então passar funções, objetos inteiros, arrays com dados, strings, numeros, o que for por props para alterar o comportamento ou aspecto de um componente diante de cada situação em que ele for chamado.

Um ponto importante quando utilizamos componentes: O JSX considera tags iniciadas em minúsculo como elementos HTML, enquanto tags iniciadas em letras maiúsculas são tratadas como componentes e, assim, devem estar presentes no escopo.

Imutabilidade das Props

Nossas props são imutáveis e devem permanecer como tal. A documentação do React nos dá um ótimo exemplo entre funções puras e impuras. Veja as seguintes funções retiradas da própria documentação para fins comparativos:

    // Exemplo 01 - Funcao Pura
    function sum(a, b) {
        return a + b;
    }

    // Exemplo 02 - Funcao Impura
    function withdraw(account, amount) {
        account.total -= amount;
    }

Podemos ver que na primeira função, seu resultado não altera seus parâmetros, garantindo os mesmos resultados sempre que passados os mesmos valores. Diferentemente, a segunda função altera diretamente um de seus parâmetros.

Em React, ambas as funções podem existir, exceto para um único caso: Quando tratamos de props, as funções devem ser sempre puras. Em outras palavras: As props recebidas devem ter sempre o mesmo valor. Todo papel de mutabilidade é delegado para uma outra parte do componente, denominada State e que falaremos sobre ela futuramente.

Extraindo componentes: Dividir e conquistar

Uma das partes cruciais para se facilitar a reutilização de um componente é em particioná-lo em vários pedaços, montando nosso componente como um grande LEGO™.

    const MeuComponente = props => {
        return(
            <div className="news">
                <div className="header">
                    <h1>{props.title}</h1>
                    <h2>{props.subtitle}</h2>
                </div>
                <div className="content">
                    <p>{props.content}</p>
                    <p>{props.author.name}</p>
                    <img src={props.author.picture} />
                </div>
            </div>
        )
    }

Esta é uma forma de expressar nosso componente, porém é uma boa prática separarmos os componentes que nos convém e que podem ser reaproveitados em diversos outros componentes de nossa aplicação, como no exemplo a seguir:

    const Header = (title, subtitle) => {
        return(
            <div className="header">
                <h1>{title}</h1>
                <h2>{subtitle}</h2>
            </div>
        )
    }

    const Content = (content, name, picture) => {
        return(
            <div className="content">
                <p>{content}</p>
                <p>{name}</p>
                <img src={picture} />
            </div>
        )
    }

    const MeuComponente = props => {
        return(
            <div className="news">
                <Header title="Extra, Extra!" subtitle="Julieta usa caixinha de areia!" />
                <Content 
                    content="Julieta usa caixinha de areia e impressiona moradores" 
                    name="Vinicius"
                    picture="./foto-do-autor.jpeg"
                />
            </div>
        )
    }

Perceba como cada pedaço do código exerce seu papel, com funções específicas e que se relacionam para formar o componente final.

Este conceito é essencial para se utilizar bem todas as ferramentas que o React nos fornece. No caso de uma classe, nossos elementos em funções poderiam ser substituídos por métodos que nos retornam estes mesmos dados, com algumas diferenças na sintaxe.

    class MeuComponente extends React.Component {

        renderHeader = (title, subtitle) => {
            return(
                <div className="header">
                    <h1>{title}</h1>
                    <h2>{subtitle}</h2>
                </div>
            );
        };

        renderContent = (content, name, picture) => {
            return(
                <div className="content">
                    <p>{content}</p>
                    <p>{name}</p>
                    <img src={picture} />
                </div>
            );
        };

        getInfo = () => {
            return {
                title: "Extra! Extra!",
                subtitle: "Julieta usa caixinha de areia!",
                content: "Julieta usa caixinha de areia e surpreende moradores",
                name: "Vinicius",
                picture: "./foto-do-autor.jpeg"
            };
        };

        render() {
        const data = getInfo();
        // Desestruturação do objeto data, vale a pena dar uma olhada sobre!
        const { title, subtitle, content, name, picture } = data;
            return(
                {renderHeader(title, subtitle)}
                {renderContent(content, name, picture)}
            )
        }
    }

Conclusão

Esta parte é muito importante para entender a mecânica de como nossa cabeça tem que trabalhar, sempre dividindo bem as tarefas entre as funções e métodos que criam nossos elementos e componentes.

Portanto, minha recomendação é que a leitura deste artigo seja feita com muita calma e um olhar científico, no sentido de se estudar a um nível bem fracionado as informações que constam nas funções, nos conceitos e no fluxo.

No próximo texto, falarei sobre estado e sua manipulação.

Seu feedback é muito importante para que eu sempre melhore! :)

Até mais!

Dissecando React - Parte 2: Renderização e Imutabilidade

Vinicius — Tue, 02 Jul 2019 01:53:16 +0000

O que são Elementos?

Resumidamente, seriam nossas moléculas em uma aplicação em React. São nossos elementos que compõem nossos componentes, e portanto, não devem ser confundidos com tal.

    const meuElemento = <p>Conteudo do Elemento</p>

Acima, um exemplo de um elemento. Como evidenciado na documentação do React, elementos são meros objetos e são de baixissimo custo para sua criação, quando comparados com elementos do DOM do navegador. Deixando a cargo do React DOM controlar e atualizar os elementos no DOM.

Imutabilidade e Renderização

Precisamos compreender alguns termos importantes e que são responsáveis pela renderização de nossos elementos.

Primeiramente, root. Observe o trecho de código a seguir:

    <div id="root"></div>

    const titulo = <h1>Conteudo do Titulo</h1>
    ReactDOM.render(titulo, document.getElementById('root'));

Root define o nó (ou node) onde nosso ReactDOM irá gerenciar os elementos ali inseridos. No exemplo acima, estamos inserindo o elemento titulo na nossa div raíz.

Nossas aplicações geralmente possuirão apenas um único root node. Essa situação pode ser diferente em aplicações que estão passando por um processo de integração com React.

No entanto, como o ReactDOM pode saber o que mudou e que deve ser atualizado na nossa tela? Seguindo o princípio da imutabilidade. Elementos em React são imutáveis, ou seja, não podem mudar seus atributos uma vez que criados. Eles representam sua interface em um determinado ponto do tempo. Profundo, não?

Então, segundamente, temos um outro nome importante: ReactDOM.render(). Até então, nossa única forma de criar um novo elemento e renderizá-lo. Todas as vezes que mudarmos o conteúdo de nossa tag titulo teríamos que chamar ReactDOM.render() novamente e recriar este elemento.

E é neste ponto que a magia acontece...

Em time que tá ganhando não se mexe... Ou quase isso.

É basicamente isso que o ReactDOM faz. Compara os elementos e seus filhos com os elementos anteriores, e só atualiza no DOM as alterações necessárias, evitando assim um carregamento total da página para uma simples alteração.

Por mais que nossos elementos sejam complexos, apenas as partes que apresentarem uma mudança quando comparados a suas versões anteriores serão re-renderizados na tela.

Tendo este comportamento em mente, fica muito mais fácil entender como são tratados nossos elementos no ReactDOM.

Conclusão

Enquanto nossa leitura anterior foi mais intensa, a de hoje já foi um pouco mais simples, mas não menos importante. Entender o princípio da imutabilidade e como nosso ReactDOM atualiza as informações no DOM de nosso navegador são peças chave para realmente dominar o comportamento de nossos componentes e aplicações.

Espero que este texto sirva de alguma ajuda para fixar os conceitos de React, e que sirva como uma ponte pro nosso próximo texto que está por vir, onde falarei melhor sobre componentes, classes e funções.

Seu feedback é muito importante para que eu sempre melhore! Aguardo seu contato nos comentários ou pessoalmente.

Até a proxima!

Dissecando React - Parte 1: JSX

Vinicius — Mon, 01 Jul 2019 01:18:35 +0000

Uma breve retratação ao leitor

Este texto pode conter algumas leves imprecisões para fins didáticos. Alguns conceitos podem não abrangir a sua totalidade para simplificar um conceito a fim de tornar-se mais tangível à realidade do leitor, considerando-se que o publico-alvo deste texto é especificamente direcionado para quem não teve nenhum - ou muito pouco - contato com desenvolvimento, especialmente em React.

Dito isto, espero que a leitura esteja a altura de grandes nomes que me inspiram diariamente e que essa série de introduções, por assim dizer, auxiliem na jornada de pessoas que se interessem em começar no vasto campo do desenvolvimento.

Elaborando nosso sumário

Esta é uma primeira parte introdutória sobre uma série de textos que pretendo elaborar a fim de explicar de uma forma simplificada - porém entrando em detalhes - as características de uma aplicação em React, perpassando por componentes, estados, props, hooks e suas particularidades no geral.

Com isto em vista, esse sumário será atualizado neste e nos demais textos a medida que novos artigos forem publicados. Daremos nosso Hello World com a parte mais introdutória que é entender um componente e suas características principais.

1. JSX
2. Renderização e Imutabilidade

Meu Deus, o que é JSX?

Antes de partirmos para o que interessa, precisamos entender uma ferramenta que tornará nossa vida mais fácil quando se trata de criar uma aplicação em React.

No ramo de desenvolvimento, existe um termo muito comum chamado "Syntax sugar", que significa, basicamente um facilitador de sintaxe que nos permite acelerar nossa produção, seja tornando um código mais legível, mais simplificado ou mais fácil de escrever.

O JSX é uma extensão de JavaScript (JSX significando JavaScript XML, para os curiosos) que nos permite invocar, por assim dizer, elementos do React. Vejamos:

    const Felino = <img src="./foto-do-meu-pet.png" />

O que temos escrito acima não é nem uma template string ou HTML. É tudo JavaScript. O JSX é capaz de interpretar o que escrevemos como se fossem tags de HTML e "traduzir" isto para a criação de um elemento em React.

Diferente de outros modelos de desenvolvimento que separam suas funções e html em arquivos diferentes, a proposta do React foi de unificar a lógica geral: manipulação de eventos, renderização dos componentes, mudança de estados - tendo em vista que estas etapas estão muito atreladas no comportamento de um componente.

Uau, mas e agora?

Vejamos o seguinte trecho de código:

    const Felino = {
        name: "Julieta",
        photo: "./foto-do-meu-pet.png",
        subtitle: "Miau"
    };

    const CartaoDoPet = (
        <h1>{Felino.name}</h1>
        <img src={Felino.photo} />
        <p>{Felino.subtitle}</p>
    );

Muita informação? Não se desespere. Vamos no passo-a-passo.

Primeiro declaramos um objeto com as informações do nosso pet.

    const Felino = {
        name: "Julieta",
        photo: "./foto-do-meu-pet.png",
        subtitle: "Miau"
    };

Queremos embutir - ou no jargão, embeddar - estas informações dentro de um componente.

    const CartaoDoPet = (
        <h1>{Felino.name}</h1>
        <img src={Felino.photo} />
        <p>{Felino.subtitle}</p>
    );

Aqui é onde inserimos as informações do nosso objeto dentro do JSX. As chaves abrem espaço para que qualquer expressão válida de JavaScript possa ser ali inserida. Pode ser uma operação matemática (1 + 1), dados de um objeto ou até mesmo uma função.

No exemplo acima, nós acessamos os dados de um objeto que contem as informações do pet que preencherá nosso componente CartaoDoPet.

E tem muito mais. Imagine se não tivéssemos os dados da gatinha Julieta para preencher nosso cartão e, para estes casos, quiséssemos que uma mensagem fosse exibida para o usuário.

    const CartaoDoPet = {
        if(Felino) {
            return (
                <h1>{Felino.name}</h1>
                <img src={Felino.photo} />
                <p>{Felino.subtitle}</p>
            )
        }
        return <h1>Nenhum felino encontrado.</h1>
    }

Se Felino for verdadeiro, ele retorna com o nosso componente e seus dados preenchidos. Para demais casos, a mensagem será apresentada!

Isso porque JSX, no final das contas, é JavaScript - e será traduzido para tal quando rodarmos o projeto. E isto nos traz a uma segunda questão do JSX:

    const NomeDoPet = <h1 className="fonteAzul">{Felino.name}</h1>

Parece HTML, mas escrevemos className ao invés de class, e está em camelCase. Por quê?

Isso se dá porquê convencionou-se que, por se tratar de JavaScript e não HTML, utiliza-se camelCase. Tanto é que class é um termo reservado e, por isso, precisamos utilizar className para referenciar ao class de HTML.

Uma pausa para recapitular e respirar

Já sabemos embutir valores dentro de nosso elemento e sabemos que no final das contas, tudo vira JavaScript - e que aquele HTML que escrevemos com JSX na verdade é JavaScript disfarçado pra facilitar a criação de um elemento React.

Em outras palavras, veja o comparativo do código a seguir:

    const item = <h1 className="titulo">Meu titulo</h1>;

    const item = React.createElement(
        'h1',
        { className: 'titulo' },
        'Meu titulo'
    );

Ambos representam a mesma coisa. O JSX é interpretado pelo Babel, uma ferramenta que nos auxilia a escrever javascript moderno e transforma nosso elemento "html" em um React.createElement, uma função de criação de elemento pertencente ao React.

Essa função é importante pelo seguinte papel: Ela quem passa ao React o que será renderizado no DOM (Document Object Model - ou, em outras palavras, o que seu navegador vai entender e mostrar na tela), o que será atualizado, desmontado e tudo mais!

'Meu Titulo' representa o elemento Children do nosso elemento. Então quando inserimos um conteúdo dentro das nossas tags, ele é passado como este elemento Children. Salve isto em mente, pois futuramente, veremos algumas utilidades para manipular o conteúdo que estiver dentro do elemento Children.

Conclusão

A fim de não deixar a leitura muito extensa e dar um espaço para a digestão do conteúdo, encerro esta parte por aqui. Há muito mais sobre o comportamento do JSX na própria documentação do React, tudo muito bem detalhado.

No próximo texto, apresentarei um pouco sobre as formas que um componente React pode se apresentar e convenções, a fim de que assim tenhamos um primeiro contato com as propriedades e ciclo de vida de um componente.

Agradeço a leitura de todos, e seu feedback é muito importante pra que eu possa melhorar no conteúdo aqui apresentado.

Até a próxima!

Explicando Promises de uma forma didática

Vinicius — Tue, 26 Mar 2019 17:40:06 +0000

Introdução

Enquanto escrevemos nossos códigos, diariamente esbarramos - mesmo que de forma inconsciente - no que chamamos de Promises (ou Promessas). As similaridades entre o objeto de uma promise e uma promessa feita no dia-a-dia são maiores do que pensamos quando tratamos pelo fluxo que elas percorrem.

Quando prometemos algo para alguém, podemos cumprir esta promessa ou não. Em JavaScript, esse comportamento é muito parecido. Ao estabelecermos uma promise, este retorno pode ou não se concretizar - e assim definirmos uma decisão para esses casos (resolve ou reject).

Iniciando pelo básico

Digamos que eu faça uma promessa aos meus gatos de alimentá-los todas as manhãs.

Em JavaScript teríamos:

let promessaDeAlimentarGatos = new Promise(function(resolve, reject){
    let poteCheio = true;

    if(poteCheio) {
        resolve('Buchinho cheio');
    } else {
        reject('Fome');
    }
});

Resultado: 'Buchinho cheio'.

Como na vida real, em JavaScript temos dois retornos chamados de resolve e reject. No exemplo acima, por poteCheio ser verdadeiro, meus gatos tiveram mais um dia de barriga cheia e muita preguiça.

Portanto, respeitando as condições, a Promise se resolveu com a mensagem Buchinho cheio. Se poteCheio fosse falso, meus gatos estariam com fome e a Promise rejeitaria com a mensagem Fome.

Onde está a verdadeira utilidade

Como o resultado da Promise depende diretamente de cumprir ou não as condições, temos uma forma de aplicar este resultado fazendo bom uso disso.

Nossa Promise agora existe, então podemos executá-la e exibir uma mensagem de acordo com o resultado obtido, da seguinte forma:

promessaDeAlimentarGatos.then(function(result){
    console.log('Meus gatos estão com ', result)
}).catch(function(result) {
    console.log('Meus gatos estão com ', result);
});

Dissecando este código temos o seguinte fluxo:

Executamos a Promise promessaDeAlimentarGatos
Se o retorno for resolvido (resolve), nossa função .then será ativada e nos mostrará a mensagem 'Meus gatos estão com Buchinho Cheio'.
Se o retorno for rejeitado (reject), nossa função .catch será ativada e nos mostrará a mensagem 'Meus gatos estão com Fome'.

E são as funções .then e .catch que nos trazem uma ótima aplicabilidade do uso das Promises.

Encadeando Promises

Atualmente, tenho 3 gatos. Digamos que quero exibir quais gatos eu já enchi o pote de ração.

Como eu sou só um, eu teria de seguir uma linha para encher todos os potes.

Esta atividade pode ser transcrita para JavaScript da seguinte forma:

let alimentarLuna = function() {
    return new Promise(function(resolve, reject) {
        resolve('Alimentei a Luna');
    });
}

let alimentarJulieta = function(message) {
    return new Promise(function(resolve, reject) {
        resolve(message + ', e' + alimentei a Julieta');
    });
}

let alimentarGatarina = function() {
    return new Promise(function(resolve, reject) {
        resolve(message + ' e ' + alimentei a Gatarina.');
    });
}

Temos acima, três promises que nos retornam quais gatas foram alimentadas. Mas pra isso, eu preciso primeiro encher o pote da primeira gata para passar para o pote da segunda gata.

Podemos transcrever isto para JavaScript da seguinte forma:

alimentarLuna().then(function(result){
    return alimentarJulieta(result);
}).then(function(result){
    return alimentarGatarina(result);
});

O resultado seria impresso na tela desdobrando os resultados das promises

Alimentei a Luna, e alimentei a Julieta e alimentei a Gatarina.

Os resultados das promises foram concatenados e resultaram na frase completa ao fim do processo.

Por que existem as Promises?

Pra isso, precisamos entender que JavaScript é uma linguagem single-threaded, ou seja, trabalha com apenas um caminho - executa apenas uma linha de código em um determinado tempo.

Para que nosso programa não travasse dependendo da resposta de um serviço, elaboramos as Promises - que rodam essa linha de código e convenientemente nos avisam quando esta execução foi encerrada.

Essa discussão pode ficar bem mais aprofundada, mas para nos mantermos no assunto, vou encerrar concluindo que as Promises existem para que os programas em JS possam buscar informações de serviços sem parar a aplicação por inteiro.

Entendendo Promise.all e Promise.raise

As promises não necessariamente precisam rodar em sequência. Podemos, utilizando do exemplo, dividir as tarefas de alimentar as gatas com os outros 2 moradores de minha casa - de forma simultânea.

Assim trataríamos da seguinte forma:

Promise.all([alimentarLuna(), alimentarJulieta(), alimentarGatarina()]).then(function(){
    console.log('Todas as gatas foram alimentadas');
});

Digamos que novas atividades aparecem a medida que os moradores finalizam as suas atividades, podemos usar .raise para notificar quando estas etapas forem se concluindo.

Promise.raise([limparCaixa(), varrerPelos(), trocarAgua()]).then(function(){
    console.log('Um morador finalizou uma das atividades');
});

Conclusão

Resumidamente, as Promises funcionam como nossas promessas. Elas podem ou não se concretizar, e com isso temos tratativas para um final positivo ou negativo deste resultado.

Utilizar .then e .catch para tratar Promises encadeadas é um daqueles momentos que uma Promise brilha de verdade.

Espero que este breve texto te ajude, e se encontrar algo de errado em minhas palavras, fique a vontade para me corrigir. Atualizarei a publicação sempre que possível.

Quais as diferenças entre Stateless e Pure Components?

Vinicius — Thu, 07 Mar 2019 21:10:56 +0000

Uma das primeiras duvidas que tive durante minha jornada como desenvolvedor iniciante foi sobre quando/por quê utilizar Components, Pure Components e Stateless Components.

Pois bem, durante minhas indagações, acabei fazendo diversas pesquisas na internet até formular uma maneira bem mastigável e aplicável de entender as diferenças entre seus conceitos e utilidades.

Quando estamos trabalhando com desenvolvimento de Front-End, uma das grandes preocupações é em como executar uma aplicação de forma performática dentro dos limites dos navegadores. E é neste ponto que os Pure Components brilham de verdade.

Ao trabalharmos com Pure Components, estamos alterando a forma que o React trabalha com a função shouldComponentUpdate de forma que este componente só irá chamar o render() quando houver uma alteração OU nas props OU no state.

Esta é a principal diferença entre um Pure Component e um Stateless Component. O Pure Component utiliza de um shallowEqual por detrás dos panos para fazer uma comparação leve e decidir se o componente deve ou não ser renderizado novamente.

if (this._compositeType === CompositeTypes.PureClass) {
  shouldUpdate = !shallowEqual(prevProps, nextProps) || ! shallowEqual(inst.state, nextState);
}

Em razão do uso de shallowEqual, é recomendado que um Pure Component não tenha componentes filhos, isso se dá pois o retorno da comparação mais rasa sempre será false para elementos criados em JSX e que possuem elementos-filhos.

Um Pure Component também herda as funções de ciclo de vida do React, enquanto um Stateless Component não.

Mas como estas características se diferem na prática?

Pense em uma tela com diversos cards. Dentro deles, temos informações variadas como nome, idade, cidade e emprego. Considere também que estes cards são paginados e apresentados em tela de 10 em 10.

Essa situação é ideal para o uso de um Pure Component a fim de que as informações que se mantiverem iguais não sejam re-renderizadas, melhorando considerávelmente o desempenho de nossa lista de cards.

Agora, Stateless Components têm sua aplicação ideal em componentes menores, por exemplo, uma tag anexada ao card que apresente a informação admin ou membro. Isso se dá porque:

É uma view muito pequena para ter a real necessidade de componentizar.
A perda de desempenho é muito pequena para uma UI deste tamanho.
As funções de ciclo de vida não serão necessárias neste pequeno componente.

Conclusão

Analisar a situação é sempre o melhor passo para aplicar um Pure ou Stateless Component. Porém, se tivermos de criar uma regra de ouro, seria:

Pure Components são ideais para se ganhar performance e reduzir a quantidade de renderizações que um componente realizará durante seu ciclo de vida.
Stateless Components têm um código mais legível/simples, e fazem um papel ideal para pequenos componentes, evitando a separação (e eventual caos total) do seu projeto em muitos arquivos pequenos.

Espero que minhas pequisas possam ajudar do mesmo jeito que me ajudaram.

Até!