Fernando Nagase's blog

Git: da pedra aos metais — parte 1

Fernando Nagase — Mon, 08 Jan 2024 19:21:17 GMT

Um dos fatores mais importantes para mim ao aprender sobre um novo assunto é estudar a forma como o entendimento sobre ele evoluiu ao longo da história, pois acredito que, ao fazer isso, muito se revela sobre o contexto em que as pessoas passaram a estudá-lo e a utilidade que ele traz para a sociedade.

Nesse sentido, resolvi experimentar uma abordagem nova para mim, que consiste em criar minhas próprias versões de ferramentas de software comumente usadas. Meu intuito com isso não é apenas replicar cada ferramenta em sua "forma final", mas compreender as possíveis escolhas que as levaram a ser como são.

É exatamente esse processo que pretendo relatar na série "Git: da pedra aos metais", que se inicia com esta publicação. Nela, começarei criando a versão mais óbvia que eu conseguir pensar para o versionamento de código e, parte por parte, trarei novas melhorias até atingir um resultado semelhante ao próprio Git.

Ao mesmo tempo em que escrevo cada artigo, planejo realizar a implementação do sistema com a linguagem Rust e disponibilizar o código de cada versão juntamente às publicações. Até o final da série, minha expectativa é que o sistema implemente as funcionalidades a seguir:

persistência e restauração de versões (commit);
rastreamento de histórico (log);
ramificações do histórico (branching);
staging area (index).

Eu não recomendaria esta série para pessoas que nunca tiveram contato com o Git, pois pretendo implementar o sistema já levando em consideração alguns dos conceitos existentes em Git. Por outro lado, caso você já o tenha utilizado e queira aprender ainda mais sobre seu funcionamento, essa é a oportunidade!

Primeira abordagem: cada versão é uma cópia completa do repositório

Inicialmente, optei por uma abordagem trivial e que, provavelmente, todos já utilizamos para fazer backup de algum projeto: para cada versão que precisamos guardar, todo o conteúdo presente atualmente no diretório de trabalho é copiado para um novo diretório.

Esse trabalho é automatizado por meio da interação com uma interface de linha de comando (CLI), de forma semelhante ao Git, e essa CLI, nomeada genericamente como vcs, conta com apenas três comandos: init, commit e restore .

Conforme sugerido pelo nome, a responsabilidade do comando init é inicializar um repositório controlado pelo sistema no diretório atual, o que, ao menos por ora, consiste em criar um diretório oculto .vcs para abrigar todos os arquivos relacionados ao controle de versão, de forma análoga ao diretório .git do Git.

O comando commit é responsável por criar o backup do repositório, o que, como discutimos anteriormente, trata-se apenas de copiar todo o conteúdo para um diretório específico dentro de .vcs. Nesse caso, o diretório de cada backup recebe como nome um número sequencial, como 1, 2, 3 etc., indicativo de sua versão.

Para facilitar o trabalho de identificar qual é o número associado à versão atual, utilizei um arquivo version dentro de .vcs, que, a cada execução de commit, tem seu conteúdo substituído pelo número da nova versão.

Finalmente, cada diretório de versão abriga um arquivo extra com o nome README, cujo conteúdo é uma string informada pelo usuário durante o commit (commit ) para ajudar a identificar as alterações introduzidas por cada um deles.

O último comando, restore , recebe o encargo de restaurar o repositório para o exato estado em que se encontrava na versão informada, o que, na prática, consiste em apagar todo o conteúdo do diretório raiz do repositório, com exceção de .vcs, e criar uma cópia de todos os arquivos salvos no backup da versão desejada para o diretório atual, com exceção de README.

O conteúdo do diretório .vcs se assemelha ao seguinte:

ls .vcs/
1 2 3 version

O conteúdo do diretório de uma versão específica contém uma cópia de todos os arquivos do próprio repositório juntamente a um arquivo README com a descrição do commit:

ls .vcs/3/
README a.txt b.txt

Tudo o que fiz até aqui é basicamente o que já fazemos ao copiar backups de um projeto para a nuvem ou para um outro dispositivo de armazenamento local, com a única diferença sendo a automatização desse processo por meio da CLI.

Como já sabemos, essa abordagem é prática, mas carrega consigo alguns problemas. Na próxima parte desta série, vou enumerar e resolver alguns desses problemas para melhorar o sistema. Com isso, encerro a primeira parte por aqui! Até a próxima!

Repositório

O código-fonte desta primeira versão pode ser consultado no repositório do GitHub.

Atribuições

Fotografia da capa por Azzedine Rouichi em Unsplash

A história da Inversão de Controle em 10 minutos

Fernando Nagase — Fri, 20 Oct 2023 18:12:41 GMT

Entre o final da década de 1970 e o início da década de 1980, uma equipe de programadores do Xerox PARC (Palo Alto Research Center) trabalhava na criação de um ambiente de ferramentas integradas com o objetivo de facilitar o desenvolvimento e manutenção de software com a linguagem Mesa.

Um dos componentes centrais do XDE (Xerox Development Environment), como foi denominado o projeto, era o Tajo, que, resumidamente, oferecia o arcabouço necessário para implementar e executar as ferramentas em questão.

Diferentemente de outros ambientes de desenvolvimento daquela época, que executavam uma única tarefa por vez, com o Tajo, era possível interagir com múltiplas ferramentas simultaneamente, pois ele representava cada uma delas como uma janela em uma interface gráfica de usuário.

Para tanto, uma característica especialmente interessante no contexto deste artigo foi adotada no design do Tajo: as ferramentas agregadas "sob o seu guarda-chuva" deveriam funcionar de forma passiva e não podiam iniciar procedimentos por conta própria.

Em outras palavras, o Tajo funcionava de acordo com um sistema de notificações, em que cada ferramenta entraria em ação — por meio de procedimentos de resposta previamente configurados pelo seu desenvolvedor — apenas quando notificadas pelo Tajo de que o usuário realizou alguma interação (com mouse ou teclado, por exemplo) com uma janela pertencente a ela.

Essa característica foi sintetizada pelo nome lei de Hollywood ou princípio de Hollywood na especificação funcional do Tajo, aparentemente, em referência à forma como atores e atrizes iniciantes adentravam no mundo de Hollywood. A explicação a seguir é feita por Alexandre Aquiles no livro Desbravando SOLID (2022):

Há milhares de atores e atrizes tentando a sorte em Hollywood. E todo filme tem uma pessoa responsável por definir quem vai interpretar cada papel. Imagine se os milhares de atores e atrizes ligassem à procura de uma oportunidade. A pessoa responsável pelo elenco não sairia do telefone!

Por isso, em Hollywood, a pessoa responsável pelo elenco obtém uma lista de atores e atrizes com seus telefones e as características de cada um. E essa pessoa comumente diz: "Não me ligue, deixa que eu te ligo". Esse é o Hollywood Principle.

Ou seja, da mesma forma que a pessoa responsável pelo elenco de um filme se encarregaria de ligar para um ator ou atriz caso houvesse um papel disponível, o Tajo tinha o papel de notificar cada ferramenta quando fosse o momento certo de agir.

No ano de 2004, Martin Fowler publicou um exemplo em seu site que parece compatível com o princípio de Hollywood e nos ajuda a entendê-lo melhor:

As primeiras interfaces de usuário eram controladas pelo programa da aplicação. O que você tinha na interface de um programa era uma sequência de comandos como "Insira seu nome", "Insira seu endereço" etc., e ele conduziria esses prompts para coletar uma resposta para cada um deles. Tratando-se de UIs gráficas (ou mesmo as baseadas em telas), o framework de UI é que conteria o loop principal da aplicação, e o seu programa apenas forneceria event handlers para cada campo (de um formulário) na tela. O controle principal do programa foi invertido, afastado de você em direção ao framework.

(Traduzido e adaptado por Fernando Nagase)

Desenvolvendo software ao contrário

Você notou como, no exemplo, Fowler utilizou a expressão "o controle do programa foi invertido"? Acontece que o comportamento promovido pelo princípio de Hollywood é exatamente o que seria chamado, posteriormente, de inversão de controle. Esse era, inclusive, o tema abordado por Fowler no artigo em questão.

Até o momento, discutimos apenas sobre o contexto de interfaces gráficas de usuário, mas a inversão de controle é um princípio ainda mais amplo, que se aplica à matéria de frameworks de software como um todo, conforme seria abordado por alguns autores anos após a concepção do princípio de Hollywood.

De acordo com Fowler (2004), o termo inversão de controle teria aparecido pela primeira vez no artigo Designing Reusable Classes, publicado por Ralph Johnson e Brian Foote em 1988, em que os autores discutiam sobre o projeto (design) de classes reutilizáveis em programação orientada a objetos com a linguagem Smalltalk.

Nesse artigo, Johnson e Foote descrevem o fato de que, em frameworks de software, é comum que os métodos implementados pelos usuários do framework para suprir uma aplicação sejam executados e coordenados pelo próprio framework, em vez de serem chamados explicitamente pelo código do usuário.

Essa característica, referenciada pelo artigo de forma tangecial como uma inversão de controle, foi considerada importante pelos autores por permitir aos frameworks de software funcionarem como "esqueletos extensíveis", que podem ser adaptados por métodos fornecidos pelos seus consumidores para atender diferentes aplicações.

Em uma publicação de 1996, John Vlissides também abordou o tema e afirmou que, por meio do princípio de Hollywood, frameworks de software são capazes de capturar aspectos invariáveis de arquitetura e implementação, enquanto delegam as partes variáveis para o código específico de cada aplicação.

Essa mesma inversão de controle foi tratada por Michael Mattson, também em 1996 (conforme citado por Stefano Mazzocchi em 2004), como a principal diferença entre frameworks orientados a objetos (que chamam, eles mesmos, o código de uma aplicação) em relação a bibliotecas de classes (que são chamadas pelas aplicações).

Mudança de paradigma

Até o final da década de 1990, a expressão "inversão de controle" aparecia frequentemente ao lado de "princípio de Hollywood", mas, diferentemente da forma como a aplicamos atualmente, não parecia ser considerada um termo por si só.

Um evento-chave para essa mudança de interpretação parece ter ocorrido em 1998, quando Stefano Mazzocchi apresentou o conceito da inversão de controle à comunidade do Apache Avalon, um projeto cujo objetivo era prover um framework para o desenvolvimento de aplicações server-side na linguagem Java.

Um dos princípios adotados pelo Avalon era a programação orientada a componentes (COP), que promove a modularização de aplicações por meio do conceito de componente, isso é, uma porção delimitada de código exposta sob uma interface padronizada e que resolve uma responsabilidade bem definida.

Em outras palavras, para lidar com cada responsabilidade (como acesso ao banco de dados, caching, autorização etc.) em uma aplicação desenvolvida com o Avalon, era possível escolher diferentes implementações de componentes, que, por funcionarem sob uma interface comum, poderiam ser utilizadas de forma intercambiável.

A IoC era utilizada pelo Avalon no contexto do gerenciamento de dependências entre componentes, pois encorajava que um componente não configurasse suas dependências por conta própria, mas as recebesse já configuradas dos trechos de código onde fossem utilizados, nesse caso, chamados de contêineres do componente.

Figura 1 - Sem a IoC (à esquerda), o componente A instancia suas próprias dependências. Com a IoC (à direita), ele as recebe de seu "contêiner" (o método main)

Ocorre que, em grandes projetos de software, que reúnem um número elevado de componentes, tornaria-se difícil gerenciar manualmente o ciclo de vida de todos eles, já que o próprio desenvolvedor precisaria coordenar as suas rotinas de inicialização e destruição. O exemplo a seguir foi retirado do documento "Developing With Avalon" e demonstra a verbosidade desse tipo de gerenciamento.

class ContainerComponent implements Component, Initializable, Disposable
{
    DocumentRepository docs = new DatabaseDocumentRepository();
    GuardianComponent guard = new DocumentGuardianComponent();
    DefaultComponentManager manager = new DefaultComponentManager();

    public void initialize()
        throws Exception
    {
        Logger docLogger = new LogKitLogger( Hierarchy.defaultHierarchy()
        .getLoggerFor( "document" ) );

        this.docs.enableLogging( docLogger.childLogger( "repository" ) );
        this.guard.enableLogging( docLogger.childLogger( "security" ) );

        DefaultConfiguration pool = new DefaultConfiguration("dbpool");
        pool.setValue("main-pool");
        DefaultConfiguration conf = new DefaultConfiguration("");
        conf.addChild(pool);

        this.manager.addComponent( DocumentRepository.ROLE, this.docs );
        this.manager.addComponent( GuardianComponent.ROLE, this.guard );
        this.docs.compose( this.manager );
        this.guard.compose( this.manager );

        this.docs.configure(conf);

        this.guard.initialize();
        this.docs.initialize();
    }

    public void dispose()
    {
        this.docs.dispose();
        this.guard.dispose();
    }
}

Com isso, uma solução proposta pelo Avalon foi a criação de um "contêiner genérico" (Excalibur Component Manager) para automatizar o controle sobre cada componente, que poderia ser configurado por meio de arquivos XML. Desse modo, os componentes poderiam ser facilmente acessados por meio do ECM, removendo-se a necessidade de se preocupar com seus ciclos de vida.

Foi exatamente esse contexto de gerenciamento de dependências que, no início da década de 2000, influenciou o surgimento de outros frameworks, como o PicoContainer e Spring Framework, chamados de "contêineres baseados em IoC", que ofereciam funcionalidades semelhantes ao Avalon.

Desde então, o termo "inversão de controle" passou a ser cada vez mais utilizado de forma "standalone" no contexto de gerenciamento de dependências e estabeleceu uma nova tendência.

Injeção de dependência

Em 2004, Martin Fowler publicou um artigo em que discutia sobre o surgimento de uma nova onda de "lightweight containers" e sobre como eles se relacionavam com o princípio da inversão de controle. Um trecho desse artigo nos é especialmente interessante:

A Inversão de controle é uma característica comum entre frameworks, logo, dizer que esses "lightweight containers" são especiais por usarem inversão de controle é como dizer que meu carro é especial por ter rodas.

A pergunta é: "qual aspecto do controle eles estão invertendo?"

(Traduzido e adaptado por Fernando Nagase)

Ou seja, indo ao encontro da definição de Foote e Johnson (1988) sobre como a IoC está inerentemente ligada ao próprio conceito de framework de software, Fowler julgou inadequado o uso desse termo para designar o padrão de projeto implementado pelos contêineres analisados, por ser muito genérico.

Antes de publicar o artigo, entretanto, Fowler já havia demonstrado um rascunho para outros programadores envolvidos com o assunto, entre os quais Rod Johnson (criador do Spring Framework) e Paul Hammant (co-líder do PicoContainer), com quem discutiu uma nova nomenclatura, chegando ao termo "Injeção de Dependência".

Desde então, a escolha entre um termo ou outro parece ter se tornado confusa, principalmente pelo fato de algumas pessoas terem passado a considerá-los sinônimos, o que foi refutado por Mazzocchi alguns dias após a publicação original de Fowler.

Com base nas posições de Mazzocchi (2004) e Fowler (2005), assim como a defendida em um artigo no site do PicoContainer sobre a história da IoC, considero seguro tratar a inversão de controle como um princípio amplo (conforme abordado por Johnson e Foote, Vlissides e Mattson).

Por outro lado, a injeção de dependência se trata de uma entre diversas formas de se atingir a inversão de controle, tendo seu foco voltado para a coordenação de dependências entre objetos (conforme implementado pelo PicoContainer, Spring Framework e demais contêineres do tipo).

Conclusão

As primeiras discussões sobre a inversão de controle foram levantadas no contexto de frameworks de software e a tratavam como um princípio amplo, preocupado com a transferência de aspectos reutilizáveis entre aplicações das mãos dos desenvolvedores para as mãos de frameworks.

No entanto, a grande popularização do termo pelos chamados "contêineres baseados em IoC" fez com que o conceito da inversão de controle se confundisse com o que hoje chamamos de "injeção de dependência", isso é, uma forma específica de IoC voltada para o gerenciamento de dependências entre os componentes de uma aplicação.

Referência

Atribuições

Fotografia da capa por Cedric Letsch em Unsplash

O que é o padrão Strangler Fig Application?

Fernando Nagase — Thu, 22 Jun 2023 19:27:24 GMT

O padrão de projeto Strangler Fig Application, que também é conhecido como padrão Strangler Application ou simplesmente Strangler, teve seu nome baseado em uma analogia popularizada por Martin Fowler.

Ao meu ver, as analogias compõem um recurso poderosíssimo para facilitar o entendimento de assuntos complexos. Por meio de comparações, elas permitem explicar conceitos desconhecidos por meio daqueles que já conhecemos... Isso, é claro, se tivermos primeiramente uma referência com a qual comparar.

Dito isso, eu te faço uma pergunta: você sabe o que são Strangler Figs? Se, assim como eu, você nunca tinha ouvido falar sobre esse termo até se deparar com o padrão abordado neste artigo, continue lendo, pois vamos começar pelas "raízes" para entender o seu significado e qual a sua relação com desenvolvimento de software.

O que são Strangler Figs?

Em uma publicação feita em seu próprio site, Fowler relata que concebeu uma metáfora sobre a migração de sistemas críticos durante uma viagem que fez para a Austrália, após observar o comportamento de certas árvores que podiam ser encontradas naturalmente por lá.

Essas árvores, que na verdade fazem parte de uma família com várias outras espécies, são denominadas Strangler Figs ou "figueiras estranguladoras", em português, e recebem esse nome devido à forma pela qual normalmente se desenvolvem: elas crescem ao redor de árvores hospedeiras e as "estrangulam".

Para ser mais específico, elas produzem frutos cujas sementes são depositadas nas copas das outras árvores principalmente como resultado da alimentação de pássaros, e quando essas sementes encontram os recursos necessários, elas germinam e suas raízes passam a crescer do alto até se estabelecerem no solo.

O resultado desse processo pode ser, ocasionalmente, a morte da árvore hospedeira, visto que a figueira passa a competir tanto pelos nutrientes do solo quanto pela luz solar, nas partes superiores. Você pode ver como esse tipo de árvore se parece assistindo este vídeo (YouTube).

Strangler Fig Application vs. Strangler Application

Tratamento de exceções em Java: o que há de especial?

Fernando Nagase — Sat, 10 Jun 2023 20:45:09 GMT

As exceções em Java são um pouco diferentes se comparadas com as de outras linguagens de programação. Eu não sei se esse é o seu caso, mas, quando comecei a estudar Java, eu sentia essa diferença enquanto programava e não sabia explicar qual era o motivo.

Por exemplo, por que algumas exceções produzem erros de compilação quando não são tratadas enquanto outras não? E, em relação a esses erros produzidos, por que eles são "magicamente" resolvidos ao especificar os tipos das exceções após a palavra-chave throws, na assinatura do método pelo qual são lançadas?

No final das contas, a resposta é simples (ou nem tanto, conforme explico na última seção). Basta entender como as exceções em Java foram projetadas e a razão pela qual elas foram organizadas da forma que foram. É isso que eu tentarei te explicar até o fim deste artigo.

Introdução às exceções

Por baixo do pano, todo método define uma espécie de contrato com o código que o consome. Nele, especifica-se detalhes como a forma de utilizá-lo (ou seja, seus parâmetros) e o comportamento esperado ao chamá-lo (produz um valor de retorno ou efeitos colaterais).

No entanto, há situações em que um método não é capaz de seguir o seu fluxo padrão, geralmente em decorrência de fatores externos, como o ambiente em que o programa está sendo executado.

Nesse contexto, um exemplo comumente utilizado é o de um método que recebe do usuário o nome de um arquivo e tenta abri-lo: caso o nome informado não exista, o arquivo não pode ser aberto, e o método é impedido de prosseguir da forma esperada.

É esse aspecto que as exceções representam. Por meio delas, é possível sinalizar a ocorrência de situações excepcionais que podem acontecer ao invocar um método, e essas situações podem ser detectadas e "tratadas" pelo desenvolvedor por meio de um mecanismo adequado — os famosos blocos try-catch.

// código omitido
public void doSomething() {
    try {
        doAnotherThing(); // potencialmente lança ExampleException
    } catch (ExampleException e) {
        // tratamento da exceção
    }
}
// código omitido

Tradicionalmente, o tratamento de uma exceção não é obrigatório e não precisa ser feito pelo método que a lançou (nem mesmo por outros métodos que o tenham invocado!), o que é uma vantagem até certo ponto, pois possibilita que as exceções "borbulhem" (bubble) de baixo para cima na call stack até o local mais adequado para o tratamento. A figura 1 ilustra esse comportamento.

Figura 1 - As exceções "borbulham" na call stack até que um método as capture.

Checked vs. Unchecked Exceptions

Ocorre que a linguagem Java considera as exceções lançadas por um método uma parte do seu próprio contrato, e sua sintaxe obriga que elas sejam informadas a qualquer código que o invoque. Em outras palavras, as exceções precisam constar na assinatura do método, da mesma forma que seus parâmetros e valor de retorno.

Esse requisito é justificado pela noção de que o desenvolvedor deve ser capaz de antecipar e contornar exceções, seja exibindo uma mensagem de erro ao usuário, seja buscando uma rota alternativa para a ação solicitada. É por esse motivo que especificamos as exceções após a palavra-chave throws.

// código omitido
public void doAnotherThing() throws ExampleException {
    // código omitido
    if (condition) {
        /*
            ExampleException representa uma situação que é prevista ao
            invocar o método doAnotherThing, mas que ocorre apenas em
            condições excepcionais (por exemplo, se "condition"
            for verdadeiro). Espera-se que o código consumidor
            antecipe essa situação e a trate de maneira adequada.
        */
        throw new ExampleException()
    }
    // código omitido
}
// código omitido

Dessa forma, sempre que lidamos com um código que possivelmente lança exceções, temos duas opções: ou as tratamos imediatamente (com try-catch) ou as tornamos parte do próprio contrato do método no qual trabalhamos (com throws em sua assinatura), esperando que um outro método faça o tratamento. Esse comportamento é denominado Catch or Specify Requirement.

Figura 2 - Todos os métodos que trabalham com uma exceção, mas não a tratam, precisam torná-la parte do seu próprio contrato com "throws".

Para garantir que o desenvolvedor tome conhecimento sobre as exceções possivelmente lançadas por um método, o compilador Java acusa um erro de compilação caso uma exceção não tenha sido tratada (ou, ao menos, postergada com throws). Sendo assim, as exceções em Java são conhecidas como checked exceptions (exceções verificadas).

No entanto, algumas exceções são naturalmente internas à aplicação (não devem ser expostas pelo contrato) e não podem ser contornadas de forma satisfatória, pois geralmente decorrem de defeitos de programação (como uma tentativa de acessar campos em um valor nulo ou realizar uma divisão por zero). Essas exceções são conhecidas como unchecked exceptions (exceções não verificadas).

Unchecked exceptions vs. Runtime exceptions

Introdução ao Declarative UI em React

Fernando Nagase — Sat, 20 May 2023 21:40:11 GMT

O lançamento da nova documentação do React em março de 2023 foi, para mim, uma ótima oportunidade para revisar alguns conceitos básicos para os quais eu nunca havia dado tanta atenção, e, por incrível que pareça, uma das leituras que mais me chamou a atenção foi a dessa seção, que explica sobre dois conceitos presentes desde a concepção do React: UI reativa e programação declarativa.

De forma resumida, o React permite criar interfaces de usuário que reagem a mudanças no estado de uma aplicação e disparar as atualizações correspondentes na UI por meio de descrições sobre como ela deve se parecer em vez de comandos para alterar a interface diretamente. Em outras palavras, o desenvolvedor não se preocupa com como exibir a interface, mas com o que deve ser exibido.

Em React, você não manipula diretamente a UI — isso é, você não habilita, desabilita, mostra ou oculta componentes diretamente. Em vez disso, você declara o que quer mostrar e o React identifica como atualizar a UI. (tradução nossa.)

-- Reacting to Input with State

Trata-se de um tema bem interessante, mas antes de entrar em mais detalhes, eu gostaria de te mostrar o que todo esse assunto tem a ver com cortar o seu próprio cabelo. Ficou com curiosidade? Então continue comigo até a próxima seção!

Cortes de cabelo podem ser complicados; a UI também

Flávio é um rapaz jovem e se preocupa com o seu visual, mas não esteve satisfeito com o seu cabelo nos últimos dias e sente que está na hora de experimentar um novo corte, só que com um detalhe: ele mesmo queria fazê-lo.

A primeira etapa foi comprar as ferramentas necessárias, como uma tesoura, uma máquina de cortar cabelo e um pente. Em seguida, estudou algumas técnicas de barbearia pela internet e, por fim, iniciou o trabalho em sua própria casa.

Após terminar, Flávio limpou o local, tomou um banho, penteou o cabelo e, quando se olhou no espelho, teve uma surpresa infeliz ao perceber que o resultado não o agradou tanto quanto esperava — seria melhor ter ido ao cabeleireiro — ele pensou.

Figura 1 — Flávio após ver o seu cabelo no espelho (GIF via tenor.com)

Ao meu ver, essa situação pode ser comparada a de um desenvolvedor front-end implementando uma aplicação web moderna, cuja interface de usuário precisa ser constantemente atualizada para acompanhar as interações com o usuário.

Do mesmo modo que Flávio poderia ter apenas explicado como queria seu cabelo para que um cabeleireiro fizesse o corte, tendo em mãos as ferramentas, técnicas e espaço adequados; um desenvolvedor web poderia ver o seu trabalho facilitado ao dispor de uma biblioteca de código que recebesse descrições da interface de usuário e fizesse os trabalhos de exibi-la e atualizá-la da forma adequada.

Figura 2 — Flávio, caso tivesse ido ao cabeleireiro (GIF via tenor.com)

Com isso, não estamos reconhecendo ser impossível realizar todo esse trabalho por conta própria, afinal, era assim que tudo era feito até alguns anos atrás. Acontece que esse processo pode ser complexo, sujeito a erros e nem sempre será feito de forma eficiente quando falamos em grandes aplicações, e é nesse sentido que bibliotecas de UI como o React entram em cena.

Mas como descrever uma interface de usuário?

Diferentemente de como Flávio poderia simplesmente descrever o seu corte para o cabeleireiro, nós não temos uma forma tão trivial para solicitar ao computador que exiba as interfaces de usuário, pois não falamos a mesma língua. Logo, justifica-se a necessidade de encontrar uma maneira padronizada para descrever a UI, assim como o React utiliza a sintaxe do JSX para esse fim.

Ocorre que, além de descrever e exibir os "esqueletos" de componentes da interface com JSX — isso é, apenas as suas estruturas — precisamos gerenciar a exibição de conteúdo dinâmico, que varia conforme as "situações" em que cada componente se encontra. Esse comportamento é abordado e implementado em React por meio do conceito de estado e do hook useState.

Utilizando esses dois recursos — JSX e estado — implementamos componentes em React por meio de funções que, a grosso modo, têm como principal objetivo expor uma forma de obter descrições atualizadas de um componente sempre que houver alterações no seu estado, sendo que a esse evento, em que o React chama uma dessas funções, atribui-se o nome de "renderização".

Para ser um pouco mais específico, o fluxo de atualização de um componente se assemelha ao descrito a seguir:

o estado do componente, que é gerenciado de forma centralizada e interna ao React, sofre uma alteração (por exemplo, devido à chamada de uma função set);
o React invoca a função de renderização do componente em questão e fornece a ela uma cópia com os novos valores das suas variáveis de estado. O valor retornado é uma representação válida para o componente naquele momento;
com a nova representação do componente em mãos, o React transfere as mudanças necessárias ao DOM, o que provoca uma atualização da interface exibida pelo navegador para corresponder ao estado atual do componente.

A base de conhecimento do React fornece uma explicação ainda mais detalhada sobre esse assunto, mas, de forma geral, podemos sintetizar esse fluxo conforme ilustrado na figura 3.

Figura 3 — componente visualizado como uma função matemática (baseado na ilustração de Asaf Varon)

Bônus: chamadas cumulativas de funções "set"

Uma consequência do processo de renderização em React diz respeito a uma limitação sobre como devemos utilizar funções set para alterar variáveis de estado de um componente, mais especificamente, quando tentamos chamá-las "de uma só vez" para aplicar mudanças cumulativas. Para entender melhor o que eu quero dizer, veja o exemplo a seguir:

// trecho de código retirado de https://react.dev/learn/state-as-a-snapshot#rendering-takes-a-snapshot-in-time

// Código omitido

// Código omitido

Quando estamos começando em React, é comum chegarmos à conclusão de que o resultado ao clicar no botão descrito acima (ou ao disparar qualquer evento semelhante) seja um incremento de três unidades no valor de number, mas, surpreendentemente, o que ocorre é um incremento de uma única unidade.

O motivo por trás disso é que, uma vez que o JSX é processado pela função de render do componente, a representação resultante sempre "enxerga" os valores de estado (nesse caso, o de number) como estavam no momento da renderização, e, até que o componente seja "chamado" novamente pelo React, ele não recebe o estado atualizado.

Como resultado, cada chamada de setNumber enxerga o valor de number somente como ele estava no momento em que onClick foi chamado, pois todas foram feitas antes que o componente fosse renderizado novamente. Logo, cada uma solicita a atualização de number para o mesmo valor (o valor inicial somado a 1).

Considerações finais

Podemos dizer que o tema tratado neste artigo é introdutório e até mesmo faz parte dos fundamentos do React, mas acredito que ter um entendimento claro sobre ele ajuda a construir uma base sólida, que facilita compreender o funcionamento da biblioteca com mais detalhes, por exemplo, da forma que me ajudou a entender com maior propriedade o fenômeno descrito na seção bônus.

Em suma, você deve se lembrar que o React segue um paradigma declarativo, cuja ideia é descrever a UI em vez de controlá-la diretamente, em contraste com uma abordagem imperativa, e fazemos isso por meio de funções de render, que fornecem descrições atualizadas dos componentes após mudanças em seus estados, sendo utilizadas pelo React para descobrir como ele deve atualizar o DOM.

A figura 4 sintetiza a diferença entre os paradigmas declarativo e imperativo.

Figura 4 — Paradigma imperativo vs. paradigma declarativo

Finalmente, deixo explícito que vários outros detalhes sobre o funcionamento do React foram omitidos no contexto deste artigo, como o gerenciamento de estado, Virtual DOM e o processo de reconciliação em geral. Sendo assim, sugiro que continue estudando sobre esses assuntos, sendo a base de conhecimento do React a minha principal recomendação (por sinal, foi a maior fonte de informações para a escrita deste texto).

Referências

Atribuições

Fotografia da capa por Chris Knight em Unsplash
Logo da marca React sob a licença Creative Commons Attribution 4.0