Jordan Walke e o React: como os componentes mudaram a arquitetura de UI

Quem é Jordan Walke e por que o React importou

Jordan Walke é um engenheiro de software conhecido por criar o React enquanto trabalhava no Facebook. Antes do React, frontends eram frequentemente construídos em torno de páginas, templates e uma crescente pilha de “código cola” que tentava manter HTML, CSS e JavaScript sincronizados. A ideia central de Walke foi inverter o modelo: em vez de tratar a UI como um conjunto de documentos que você vai remendando, trate‑a como uma árvore de pequenos componentes reutilizáveis que você compõe em recursos maiores.

A mudança: de templates para componentes

Isso não foi apenas uma nova biblioteca — foi uma nova forma de pensar sobre trabalho de UI. Um componente agrupa uma parte da interface com a lógica e o estado que ela precisa, e expõe uma interface limpa (props) para o resto do app. Isso faz com que trabalhar com UI pareça mais com montar peças de Lego do que editar uma única página frágil.

O React foi importante porque ajudou equipes a:

• Construir funcionalidades compondo peças previsíveis
• Deixar as mudanças de dados dirigirem o que você vê, em vez de atualizar o DOM manualmente
• Escalar bases de código com limites mais claros e padrões mais reutilizáveis

O que este post cobre (sem jargões desnecessários)

Vamos percorrer as ideias práticas que tornaram o React influente:

• Composição: como componentes se encaixam e permanecem fáceis de manter
• UI declarativa (incluindo JSX): descrever a UI que você quer, não os passos para desenhá‑la
• Renderização dirigida por estado e fluxo unidirecional de dados: manter atualizações previsíveis
• Uma visão de alto nível do DOM virtual e da reconciliação (sem mitologia)
• Como essas ideias mudaram a arquitetura frontend, o fluxo de trabalho das equipes e a manutenção a longo prazo

Você não precisa ser um especialista em frameworks para acompanhar. O objetivo é clarear o modelo mental — para que você reconheça bons padrões de React, evite equívocos comuns e aplique os mesmos princípios fora do React.

Os problemas de frontend que o React veio resolver

Antes do React, muitas equipes construíam interfaces ricas costurando templates, manipulação do DOM no estilo jQuery e uma pilha crescente de regras “quando X acontece, atualize Y”. Isso funcionava — até a UI ficar complexa.

Ponto de dor #1: atualizações manuais do DOM que não se mantêm consistentes

Um padrão comum era: buscar dados, renderizar HTML e então anexar handlers que mutavam o DOM diretamente. No momento em que o estado mudava (um novo item, um erro de validação, um toggle), alguém tinha que lembrar todos os lugares que dependiam disso.

Isso levava a bugs como:

• Um contador atualiza no cabeçalho, mas não na barra lateral.
• Um spinner some em um painel, mas fica preso em outro.
• Um formulário de edição mostra valores obsoletos após salvar.

Ponto de dor #2: lógica de UI duplicada entre funcionalidades

À medida que telas evoluíam, as mesmas regras de negócio acabavam duplicadas em vários handlers: “desative o botão se o campo estiver vazio”, “destacar itens não lidos”, “mostrar estado vazio quando não há resultados”. Quando os requisitos mudavam, era preciso caçar arquivos não relacionados para atualizar cada cópia.

Por que a complexidade da UI cresce mais rápido que a dos dados

Os dados podem ser modelados com poucas estruturas claras: uma lista de posts, um objeto usuário, um conjunto de filtros. A UI, porém, adiciona combinações: carregando vs carregado, erro vs sucesso, lido vs não lido, editando vs visualizando, filtrado vs não filtrado — muitas vezes tudo junto.

A necessidade: renderização previsível quando os dados mudam

Imagine um feed de notícias:

• Você carrega 20 posts.
• Aparece um banner de “novos posts”.
• Você curte um post, marca outro como lido e aplica um filtro.

Sem uma regra previsível como “a UI é uma função do estado”, você acaba coordenando muitas edições no DOM que podem conflitar. O objetivo do React foi tornar as atualizações confiáveis: mude os dados/estado, e a UI re‑renderiza para corresponder — sempre.

O modelo de componentes: UI como pedaços pequenos e reutilizáveis

Um componente é um pequeno pedaço da interface que você pode nomear, reutilizar e raciocinar isoladamente. Em linguagem simples: um componente recebe entradas e retorna como a UI deve parecer para essas entradas.

Esse enquadramento “entradas → saída” é o coração do modelo de componentes. Em vez de tratar uma tela como um grande template, você a divide em blocos com propósito — botões, cards, menus, formulários e seções inteiras — e então os monta.

Props: as entradas que moldam o que você vê

No React, as entradas mais comuns são as props (propriedades). Props são valores que você passa para um componente para configurá‑lo: texto, números, flags, manipuladores de evento ou até outro UI.

A saída é a UI que o componente renderiza. Se as props mudam, o componente pode produzir uma saída diferente — sem que você tenha que caçar onde atualizar o DOM.

Por exemplo, um componente Button pode receber props como label, disabled e onClick. Um UserCard pode receber name, avatarUrl e status. Você pode ler a interface do componente (suas props) da mesma forma que leria uma especificação de produto: “O que essa UI precisa para renderizar corretamente?”

Reuso e consistência: construa uma vez, use em todo lugar

Dividir a UI em componentes traz benefícios rápidos:

• Reuso: o mesmo Modal, Input ou Dropdown pode aparecer em várias páginas.
• Consistência: componentes compartilhados impõem uma única aparência e um conjunto de comportamentos (validação, espaçamento, acessibilidade) em vez de permitir que cada página reinvente a roda.
• Mudanças mais rápidas: atualize o componente uma vez e todos os locais que o usam se beneficiam.

Isso é uma grande mudança em relação a copiar e ajustar marcação por página. Componentes tornam a duplicação desnecessária — e, eventualmente, inaceitável.

A mudança de modelo mental: pensar em peças

O React incentiva a projetar UI da mesma forma que você projetaria um sistema: como partes compostas. Uma “página de Checkout” vira uma árvore de componentes — CheckoutPage contendo OrderSummary, ShippingForm e PaymentMethod. Cada parte tem entradas claras e uma responsabilidade clara.

Essa mudança — pensar primeiro em componentes — é uma razão principal pela qual o React transformou a arquitetura frontend. Deu às equipes uma unidade compartilhada de design e desenvolvimento: o componente.

UI declarativa e JSX: descrever a visão

A maior mudança de mentalidade do React é a UI declarativa: você descreve como a interface deve ser para um dado estado, e o React cuida de atualizar a página quando esse estado muda.

Em vez de localizar elementos, editar texto, alternar classes e manter o DOM sincronizado manualmente, você foca na “forma” da UI. Quando os dados mudam, a UI é redescrita, e o React calcula o conjunto mínimo de mudanças necessárias.

JSX como uma forma legível de expressar estrutura

JSX é uma forma conveniente de escrever a estrutura de componentes usando uma sintaxe parecida com HTML dentro do JavaScript. Não é uma nova linguagem de template que você deve aprender do zero; é um atalho para “este componente renderiza esta árvore de elementos”.

O benefício chave é que a marcação e a lógica que decide o que mostrar vivem juntas, o que torna os componentes mais fáceis de entender isoladamente.

Declarativo vs. imperativo (um contraste rápido)

Código imperativo foca em como atualizar a UI passo a passo:

// Imperativo: manter o DOM em sincronia manualmente
function setLoggedIn(isLoggedIn) {
  const el = document.querySelector('#status');
  el.textContent = isLoggedIn ? 'Welcome back' : 'Please sign in';
  el.classList.toggle('ok', isLoggedIn);
  el.classList.toggle('warn', !isLoggedIn);
}

Código declarativo foca em o que a UI deve ser para o estado atual:

function Status({ isLoggedIn }) {
  return (
    \u003cp className={isLoggedIn ? 'ok' : 'warn'}\u003e
      {isLoggedIn ? 'Welcome back' : 'Please sign in'}
    \u003c/p\u003e
  );
}

Por que as equipes gostam

Porque a renderização é expressa como uma descrição pura, os componentes tendem a ser mais legíveis, mais fáceis de revisar e mais simples de refatorar. Designers, engenheiros com foco em produto e colegas novos frequentemente conseguem acompanhar JSX sem vasculhar handlers de evento e mutações do DOM.

Essa clareza melhora a colaboração: decisões de UI ficam visíveis em um lugar, e mudanças têm menos chance de causar efeitos colaterais ocultos em outras partes da interface.

Renderização dirigida por estado e fluxo unidirecional de dados

“Estado” é simplesmente os dados que podem mudar enquanto o usuário interage com a UI. Pode ser o texto atual de uma busca, se um menu está aberto, os itens de um carrinho ou o resultado de uma requisição de rede. Se pode mudar e a tela deve refletir isso, é estado.

Renderização dirigida por estado: a UI segue os dados

A jogada-chave do React é tratar a renderização como consequência do estado, não como uma sequência de passos manuais no DOM. Você descreve como a UI deve ser para um estado dado. Quando o estado atualiza, o React re‑renderiza as partes relevantes.

Esse modelo mental difere de “encontre um elemento, atualize seu texto, então altere esta classe”. Em vez disso, você atualiza o estado, e a UI atualiza naturalmente porque é derivada desse estado.

Fluxo unidirecional de dados: menos surpresas, debug mais fácil

Fluxo unidirecional significa que os dados se movem em uma única direção:

• Um componente pai passa dados para filhos via props.
• Filhos podem solicitar mudanças chamando callbacks.
• Estado vive em um dono claro (frequentemente o componente que coordena a funcionalidade).

Isso reduz surpresas porque você pode seguir o caminho de uma atualização: um evento acontece, o estado muda em um lugar e a UI re‑renderiza a partir desse novo estado. Há menos ambiguidade sobre “quem mudou esse valor?”.

Um pequeno cenário: clique de botão atualiza um contador

function Counter() {
  const [count, setCount] = React.useState(0);

  return (
    \u003cdiv\u003e
      \u003cp\u003eCount: {count}\u003c/p\u003e
      \u003cbutton onClick={() =\u003e setCount(count + 1)}\u003eAdd\u003c/button\u003e
    \u003c/div\u003e
  );
}

Aqui, count é estado. Clicar no botão atualiza o estado com setCount. O React então re‑renderiza, e o parágrafo mostra o novo número. Você nunca “edita o DOM” diretamente.

O mesmo padrão escala para filtrar listas (estado = texto do filtro, UI = itens filtrados) ou validação de formulários (estado = valores e erros, UI = mensagens). Dados mudam primeiro; a visão é apenas o resultado.

Reconciliação e o DOM virtual (visão de alto nível)

A ideia-chave do React não é “desenhar a página mais rápido”. É: trate a UI como o resultado do estado e, quando o estado mudar, compare o que você quer agora com o que tinha antes — então atualize apenas o que realmente mudou.

Comparar versões da UI em vez de reescrever tudo

Quando o estado ou as props de um componente mudam, o React chama seus componentes novamente para produzir uma nova descrição da UI. Pense nisso como tirar dois snapshots:

• Snapshot A: como a UI era antes
• Snapshot B: como a UI deve ser agora

Em vez de limpar o DOM e reconstruí‑lo, o React tenta calcular o menor conjunto de operações no DOM necessário para ir de A para B.

O que “DOM virtual” significa (sem hype)

O “DOM virtual” é simplesmente a representação em memória da UI — uma árvore leve de elementos (e saída de componentes) que descreve o que deve estar na tela. Não é um segundo navegador ou um DOM mais rápido. É uma estrutura de dados que o React consegue inspecionar e comparar de forma eficiente.

Reconciliação: descobrir o que mudou

Reconciliação é o processo de descobrir o que mudou entre a árvore virtual anterior e a próxima. O React usa heurísticas para fazer isso rapidamente, como:

• Elementos de tipos diferentes são tratados como diferentes (um <div> não é um <span>)
• Keys ajudam a identificar itens em listas para que o React possa parear “o mesmo item” entre renders

Uma vez que o React sabe o que mudou, ele aplica atualizações pontuais no DOM real.

Uma nota prática sobre performance

Isso não é mágica. Performance depende de padrões: keys estáveis, evitar re‑renders desnecessários, manter o trabalho do componente pequeno e não fazer cálculos caros durante a renderização. O React pode reduzir churn no DOM, mas sua estrutura de componentes e fluxo de dados ainda determinam o quão fluida a app parece.

Padrões de composição de UI que escalam

O maior truque de escala do React não é um flag ou um plugin — é a composição: construir telas aninhando componentes, passando dados via props e usando children para permitir que um componente “embrulhe” outro UI.

Quando equipes adotam composição, elas deixam de pensar em páginas únicas e começam a pensar em partes pequenas e confiáveis que podem ser reorganizadas sem reescrever tudo.

Noções básicas de composição: aninhamento, props e children

O aninhamento é a versão visual de como a UI está estruturada: uma página contém seções, que contêm cards, que contêm botões. Props são os botões de configuração (texto, estados, callbacks). E children é como você cria componentes que fornecem estrutura enquanto permitem que quem chama decida o conteúdo interno.

Um bom modelo mental: props customizam, children preenchem, aninhamento monta.

Padrões que você verá em bases de código saudáveis

Componentes de layout definem estrutura e espaçamento sem possuir lógica de negócio. Exemplos: Page, SidebarLayout, Stack, Modal. Eles costumam depender de children, para que o mesmo layout envolva várias telas diferentes.

Inputs reutilizáveis padronizam comportamento e estilo de formulários: TextField, Select, DatePicker. Em vez de copiar labels, estados de erro e mensagens por toda a app, você centraliza essas decisões e expõe uma API simples de props.

Componentes de lista e item mantêm a UI repetida previsível. Uma divisão comum é ItemList (busca, paginação, estados vazios) mais ItemRow (como um item aparece). Isso facilita mudar a renderização sem quebrar o tratamento de dados.

Compartilhar comportamento sem compartilhar marcação

Hooks são a maneira moderna de reutilizar comportamento com estado (como toggles, estado de formulário ou fetching) entre componentes sem forçá‑los a ter a mesma forma de UI. Essa separação ajuda equipes a evoluir o design mantendo a lógica consistente.

Por que isso apoia sistemas de design

Composição é como sistemas de design se mantêm consistentes: componentes viram os blocos aprovados e layouts definem regras de espaçamento e hierarquia. Quando o sistema muda — cores, tipografia, estados de interação — os produtos herdam as melhorias com menos edições manuais.

Gerenciando estado: do local ao compartilhado

Estado é apenas “dados que podem mudar”. No React, onde esse estado vive importa tanto quanto o próprio estado.

Estado local do componente: mantenha perto de onde é usado

Estado local pertence a um único componente (ou a um pequeno widget) e não precisa ser lido em outro lugar. Pense: se um dropdown está aberto, o valor atual de um input ou qual aba está selecionada.

Manter esse estado local reduz coordenação e torna os componentes mais fáceis de reutilizar. Uma boa regra: se só um componente se importa com isso, não exporte para o resto da app.

Quando o estado vira compartilhado (e por quê)

Estado compartilhado é dado que várias partes da UI precisam concordar. Exemplos comuns incluem:

• Status de autenticação e o usuário atual
• Tema (claro/escuro) e preferências de acessibilidade
• Conteúdo do carrinho de compras
• Critérios de busca e filtro usados por vários componentes

Quando múltiplos componentes precisam da mesma fonte de verdade, duplicar estado leva a incoerências (“o cabeçalho diz 3 itens, a página do carrinho diz 2”).

Abordagens comuns (conceitual)

Subir o estado (lift state up): mova o estado para o pai comum mais próximo e passe‑o por props. Frequentemente é a solução mais simples e mantém o fluxo explícito.

Context: útil quando muitos componentes precisam do mesmo valor sem prop drilling, como tema ou auth. Context é melhor para preocupações relativamente estáveis e de âmbito de app.

Stores externas: quando o estado cresce (atualizações frequentes, dados derivados, fluxos entre páginas), uma store dedicada pode centralizar lógica e atualizações.

Previsibilidade: prefira uma fonte única de verdade

O fluxo unidirecional do React brilha quando há um dono claro por cada pedaço de estado. Mire em uma fonte única de verdade quando praticável, e derive o resto (contagens, totais, listas filtradas) desse estado em vez de armazenar duplicatas.

Manutenibilidade: testes, refatoração e fluxos de equipe

A maior vantagem diária do React não é uma técnica de renderização — são os limites de componente que transformam trabalho de UI em mudanças menores e mais seguras. Quando um componente tem uma responsabilidade clara e uma superfície pública estável (suas props), equipes podem refatorar internals sem forçar reescritas pela app. Essa estabilidade facilita code reviews, reduz quebras acidentais e ajuda novos colegas a entender onde mexer.

Testes: trate componentes como funções quase puras

Um modelo mental útil é: dadas props e estado, um componente deve descrever a UI de forma previsível. Mesmo que existam efeitos e APIs do navegador, a maior parte da lógica do componente pode permanecer determinística. Por isso testes de React frequentemente focam em comportamento e saída:

• Renderize o componente com props/estado específicos e afirme o que os usuários podem ver e fazer.
• Prefira testar pela DOM (texto, roles, labels) em vez de métodos internos.
• Faça mock dos limites (rede, storage, tempo) para manter testes rápidos e confiáveis.

Checagens de acessibilidade se encaixam naturalmente: testar por roles e nomes acessíveis detecta labels faltando, estados de foco quebrados e semântica inconsistente cedo. Checagens de consistência (lint, formatação, uso do design system) reforçam a mesma ideia: componentes previsíveis são mais fáceis de manter.

Fluxo de trabalho da equipe: contratos estáveis escalonam colaboração

Quando componentes expõem uma API pequena de props e escondem detalhes de implementação, várias pessoas podem trabalhar em paralelo — uma ajusta estilos, outra muda fetching de dados, uma terceira atualiza testes — sem pisarem no trabalho uns dos outros.

Checklist: design de componente manutenível

• Uma responsabilidade clara por componente.
• Props formam uma API pequena e estável (evite props “tudo em um”).
• Prefira composição ao invés de prop drilling profundo.
• Mantenha efeitos isolados (hooks/utilitários), não espalhados.
• Escreva testes focados no comportamento visível pelo usuário (incluindo acessibilidade).
• Reuse padrões compartilhados via design system ou primitivas comuns.

Noções básicas de performance, sem mitos

Performance no React costuma ser menos sobre “React ser lento” e mais sobre quanto trabalho sua app pede ao navegador. A UI mais rápida é a que faz menos: menos nós do DOM, menos reflows, menos cálculos caros e menos viagens de rede.

Armadilhas comuns: onde o trabalho desperdiçado se esconde

Um problema frequente são re‑renders desnecessários: uma pequena mudança de estado faz uma subárvore grande re‑renderizar porque o estado está muito no topo, ou porque props mudam de identidade toda vez (novos objetos/funções criados inline).

Outro ponto clássico são listas pesadas — centenas ou milhares de linhas com imagens, formatação e handlers. Mesmo que cada linha seja “barata”, o trabalho total soma e o scroll fica travado porque o navegador não dá conta.

Otimizações práticas que geralmente valem a pena

Comece pela estrutura:

• Divida componentes para que atualizações de estado re‑renderizem apenas as partes que mudam.
• Use memoização (componentes memoizados ou cálculos memoizados) quando um componente re‑renderiza com os mesmos inputs.
• Aplique virtualização/windowing para listas longas, renderizando apenas o que está visível.

Também foque no que o usuário percebe: reduza latência de entrada, acelere o first meaningful paint e mantenha interações suaves. Uma melhoria de 20ms em uma interação muito usada pode importar mais do que reduzir 200ms em uma tela rara.

“Estado derivado”: calcule, não armazene

Estado derivado é dado que você pode calcular a partir de outro estado/props (como fullName a partir de firstName + lastName, ou itens filtrados a partir de uma lista + query). Armazená‑lo cria bugs: você passa a ter duas fontes de verdade que podem divergir.

Prefira calcular valores derivados durante a renderização (ou memoizar a computação se for cara). Armazene apenas o que não se pode derivar — tipicamente entrada do usuário, respostas do servidor e intenção da UI (por exemplo, “o painel está aberto?”).

Como o React reconfigurou a arquitetura frontend

O React não só introduziu uma forma mais agradável de escrever UI; ele empurrou equipes a reorganizar como frontends são construídos, compartilhados e mantidos. Antes de componentes serem o modelo padrão, muitos projetos tratavam a UI como páginas com scripts e templates espalhados. Com o React, a unidade da arquitetura passou a ser cada vez mais o componente: uma peça de UI com API clara (props) e comportamento previsível.

SPAs, roteamento e estrutura “app‑like”

O React se encaixou bem na ascensão das single‑page applications (SPAs). Quando a renderização é dirigida por estado, a “página” deixa de ser um template servido pelo servidor e passa a ser uma composição de componentes mais roteamento no cliente. Essa mudança tornou comum estruturar o código por áreas de funcionalidade e partes reutilizáveis de UI em vez de arquivos HTML separados.

Bibliotecas de componentes e sistemas de design

Uma vez que a UI é construída a partir de peças reutilizáveis, é natural padronizar essas peças. Muitas organizações migraram de copiar/colar marcação para construir bibliotecas de componentes: botões, controles de formulário, modais, primitivas de layout e padrões como estados vazios. Com o tempo, essas bibliotecas frequentemente evoluíram para sistemas de design — componentes compartilhados mais guidelines — para que equipes lancem experiências consistentes sem reinventar a UI em cada tela.

Um vocabulário de UI compartilhado entre equipes

Componentes incentivam equipes a nomear as mesmas coisas. Quando todo mundo fala sobre um <Button>, <Tooltip> ou <CheckoutSummary>, as conversas ficam mais concretas: as pessoas discutem comportamento e limites, não apenas aparência. Esse vocabulário compartilhado também ajuda novos integrantes a se ambientarem mais rápido, porque o sistema é descoberto pelo código.

Influência no ecossistema além do React

O sucesso do React influenciou como a comunidade frontend pensou sobre UI: desenvolvimento component‑first, renderização declarativa e fluxo de dados previsível viraram expectativas comuns. Outros frameworks adotaram ideias parecidas, mesmo com diferenças de implementação, porque as práticas subjacentes mostraram ser mais fáceis de escalar em equipes reais.

Compromissos, equívocos e um checklist de adoção

O React ganhou reputação por facilitar evolução de UIs complexas, mas não é “grátis”. Conhecer os trade‑offs desde o início ajuda equipes a adotá‑lo pelas razões certas — e a evitar decisões por imitação.

Compromissos reais a planejar

O React tem curva de aprendizado: componentes, hooks e modelos mentais como atualizações de estado e effects demandam tempo para internalizar. O React moderno também costuma assumir ferramenta de build (bundling, linting, TypeScript opcional mas comum), o que adiciona configuração e manutenção. Por fim, o React introduz camadas de abstração — bibliotecas de componentes, roteamento, padrões de fetching — que ajudam, mas também podem esconder complexidade até que algo quebre.

Equívocos comuns (e a realidade)

“React é só a view.” Na teoria, sim; na prática, o React molda fortemente sua arquitetura. Limites de componente, propriedade do estado e padrões de composição influenciam fluxo de dados e organização do código.

“O DOM virtual é sempre mais rápido.” O DOM virtual trata mais de atualizações previsíveis e ergonomia do desenvolvedor. O React pode ser rápido, mas a performance depende de padrões de renderização, memoização, tamanhos de lista e evitar re‑renders desnecessários.

Onde o React brilha (e quando manter simples)

O React é uma boa escolha para apps com muitos estados interativos, bases de código duradouras e múltiplos desenvolvedores trabalhando em paralelo. Para um site de marketing estático ou alguns widgets pequenos, opções mais simples (templates do servidor, JS leve ou frameworks mínimos) podem ser mais fáceis de lançar e manter.

Checklist de adoção + próximos passos

• Defina a complexidade da UI e o tempo de vida esperado (meses vs anos).
• Escolha um stack base (React + um framework, ou React puro) e documente convenções.
• Combine uma estratégia de estado: o que fica local vs compartilhado.
• Padronize testes (componentes + integração) e regras de revisão de código.
• Reserve tempo para checagens de performance e acessibilidade.

Se você estiver prototipando um app em React e quiser validar essas ideias rapidamente (limites de componente, propriedade de estado, padrões de composição), um fluxo de trabalho de prototipação pode ajudar. Por exemplo, Koder.ai permite descrever recursos por chat e gerar um frontend React funcional mais backend Go/PostgreSQL, iterar com snapshots/rollback e exportar o código‑fonte quando você estiver pronto para assumir manualmente. É uma forma prática de testar decisões de arquitetura em uma feature real antes de comprometer uma construção completa.

Próximo passo: prototipe uma funcionalidade real, meça complexidade e velocidade da equipe e então escale padrões deliberadamente — não por padrão.