Guia de Copia de Componentes React em Produção

Vou mostrar como copiar qualquer componente de um site React em produção sem precisar do código-fonte ou acesso ao repositório — apenas o site rodando no navegador. Por exemplo, aqui está a barra lateral do agente do Cursor web.

import React from "react";
import { cn } from "@/lib/utils";
import { LogoLink } from "@/ui/components/LogoLink";
import { SidebarIcon } from "@/ui/icons/SidebarIcon";

export function AgentsSidebar() {
  return (
    

      

        
        
      
      
      

        
        
        
      
    
  );
}

function AgentItem({ title, status }) {
  return (
    

      {title}
    
  );
}

Parte 1: Compreendendo as Duas Árvores

Há algo que você precisa entender primeiro. Quando você está visualizando um aplicativo React no navegador, na verdade existem duas árvores residindo na memória.

Vamos usar este site como exemplo.

Árvore nº 1: O DOM

O DOM é a representação da página pelo navegador e consiste em elementos HTML: divs, botões, spans, etc. Você pode visualizá-lo na aba Elementos das suas ferramentas de desenvolvedor. É isso que o navegador renderiza na tela.

Árvore nº 2: Fibra Reativa

React Fiber é a árvore interna do React. É uma estrutura paralela mantida pelo React, que possui informações que o DOM desconhece, como:

• Qual componente React criou quais elementos DOM
• Quais propriedades foram passadas para cada componente?
• O estado do componente, os hooks, tudo.

E aqui está o mais incrível: podemos acessar isso pelo navegador. O React anexa nós Fiber diretamente aos elementos DOM. Desde o React 16, qualquer aplicativo React expõe isso, e é o que as Ferramentas de Desenvolvedor do React usam internamente.

Assim, podemos percorrer o DOM e, para cada elemento, perguntar: “Ei, qual componente React te criou? E quais propriedades ele recebeu?”

Este é o nosso ponto de partida e a forma como vamos visualizar o interior da aplicação React.

Árvore nº 2: Fibra Reativa

React Fiber é a árvore interna do React. É uma estrutura paralela mantida pelo React, que possui informações que o DOM desconhece, como:

• Qual componente React criou quais elementos DOM
• Quais propriedades foram passadas para cada componente?
• O estado do componente, os hooks, tudo.

E aqui está o mais incrível: podemos acessar isso pelo navegador. O React anexa nós Fiber diretamente aos elementos DOM. Desde o React 16, qualquer aplicativo React expõe isso, e é o que as Ferramentas de Desenvolvedor do React usam internamente.

Assim, podemos percorrer o DOM e, para cada elemento, perguntar: “Ei, qual componente React te criou? E quais propriedades ele recebeu?”

Este é o nosso ponto de partida e a forma como vamos visualizar o interior da aplicação React.

Parte 2: Mapeando os componentes para seus resultados

Em seguida, vamos pensar no que precisamos para reconstruir um componente.

Imagine que existe um Buttoncomponente na página. Ele é usado em três lugares:

• Um botão principal no cabeçalho
• Um botão desativado de alguma forma.
• Um botão secundário no rodapé

Mesmo componente, propriedades diferentes, saída HTML diferente.

O que faremos é coletar todas essas ocorrências. Para cada uma delas, registraremos:

1. Os adereços que recebeu
2. O HTML que ele produziu

Agora, veja como sabemos que todos esses são o mesmo componente. No React Fiber, cada nó do componente tem uma typepropriedade. E, para instâncias de componentes, essa typepropriedade aponta para a função ou classe correspondente. É a mesma referência na memória.

Todos Buttonos elementos da página, independentemente dos seus acessórios, terão exatamente o mesmo valor type. Podemos usar isso para agrupá-los.

Parte 3: Pedindo ao LLM para reconstruir

Muito bem, agora temos tudo o que precisamos para solicitar um LLM. Para cada tipo de componente, temos:

1. Vários exemplos de mapeamentos de propriedades para HTML
2. O código-fonte minificado (podemos obtê-lo através de type.toString())

O código minificado não é muito legível para nós, humanos, mas os LLMs (Learning Language Machines) entendem o código minificado de forma notável e obtêm dicas sobre o que o componente original fazia. E os exemplos mostram a relação de entrada e saída de forma concreta.

Então, basicamente, estamos dizendo:

“Aqui está um componente React. Vou mostrar vários exemplos de props e a saída HTML. Por favor, escreva um código React limpo que replique este componente.”

Parte 4: O Loop de Verificação

O LLM gera um componente. Ótimo! Mas como saber se está correto? Esta é a parte crucial para que tudo funcione.

Pegamos o componente gerado pelo LLM e o renderizamos nós mesmos. Passamos as mesmas props dos nossos exemplos e capturamos a saída HTML.

Em seguida, comparamos: nosso HTML corresponde ao HTML do site original?

Se não houver correspondência, mostramos ao LLM a diferença, indicando…

“Ei, quando eu passo essas propriedades, você gerou este HTML, mas o site original gerou este outro HTML. Por favor, corrija seu código.”

Repetimos o processo até que ele seja concluído com sucesso, ou até desistirmos após algumas tentativas.

É como um pequeno conjunto de testes que derivamos automaticamente do ambiente de produção.

Parte 5: A Ordem Importa (Ordenação Topológica)

Eis um detalhe que faz muita diferença.

Alguns componentes contêm outros componentes. Um componente A LoginFormpode renderizar um Buttoncomponente B dentro dele. Um componente B Cardpode renderizar um componente AvatarC.

Ao reconstruir LoginForm, precisamos já ter um em funcionamento Button. Caso contrário, como construiríamos corretamente o nosso LoginForm?

Assim, processamos os componentes na ordem de dependência. Começamos com os componentes folha — aqueles na base da árvore que não contêm nenhum outro componente personalizado. Em seguida, seguimos até os componentes pai.

Trata-se simplesmente de uma ordenação topológica no grafo de dependência de componentes.

Page

LoginForm

Footer

Button

Input

Avatar

Parte 6: Os Casos de Falha

Isso funciona na maioria das vezes, mas abaixo estão algumas situações em que não funciona.

Problema: animações em JavaScript

Imagine uma barra de progresso: <Progress value={90} />. Se tirarmos uma captura de tela dela no meio da animação, o DOM pode mostrar width: 67%enquanto as propriedades mostram value={90}.

Nosso LLM escreve um componente que produz corretamente width: 90%para value={90}, porém isso não corresponde ao nosso snapshot!

Estamos comparando com um único quadro no tempo, mas o componente real estava em animação.

Problema: Estado interativo

Um menu suspenso que está aberto no momento. Um modal que está visível. O HTML depende de um estado interno que não podemos observar apenas pelas propriedades.

O plano B

Quando a verificação falha repetidamente, simplesmente capturamos um instantâneo do HTML tal como está. Não é mais um componente real, apenas HTML congelado. Mas pelo menos podemos continuar progredindo em outros componentes.

Parte 7: Montagem do componente final

Após reconstruirmos o componente e todas as suas dependências, nós os compomos em um componente completo. Também copiamos:

• CSS
• Recursos (imagens, fontes, etc.)

E então temos o resultado: um projeto React totalmente funcional, com a mesma aparência do site original, construído a partir de componentes reconstruídos.

Conclusão

Mas resumindo:

1. Utilizamos o React Fiber para visualizar o interior da árvore de componentes.
2. Reunimos exemplos de propriedades → HTML para cada tipo de componente.
3. Pedimos a um mestre em Direito (LLM) que escrevesse um código que se encaixasse nesses exemplos.
4. Verificamos a correção através da renderização e comparação.
5. Processamos os componentes de baixo para cima, começando pelas folhas.

A principal sacada é que o React nos fornece toda essa estrutura gratuitamente. O DOM por si só é apenas uma sopa de divs. Mas o React Fiber nos diz: “Esses três botões são o mesmo componente. Este tem essas propriedades, aquele tem aquelas propriedades.”

Essa estrutura torna possível a engenharia reversa.

É perfeito? Não. Animações o quebram, estados complexos o quebram e, às vezes, o LLM simplesmente não consegue identificar o padrão. Mas para componentes de interface do usuário mais estáticos — botões, cartões, layouts, formulários — funciona surpreendentemente bem.

RECOMENDAMOS: Box criatividade: de Austin Kleon (Roube como um artista, Mostre seu trabalho!, Siga em frente) ASSIM COMO: React e o Ecossistema Full-Stack: Guia Completo de Desenvolvimento Moderno