Notação visual para as árvores de parent e owner do React

O problema de ler componentes como código

O autor afirma que a estrutura de uma aplicação React não está em nenhum arquivo isolado: ela inclui o que contém o quê, quais partes um limite de erro cobre e quem lê um contexto. Ler componentes como código exige muito esforço para tarefas como descobrir quem renderiza um componente, de onde vem uma prop ou o que é re-renderizado quando um estado muda. Ao rastrear uma prop por quatro componentes, ele diz sentir a memória de trabalho sobrecarregada. Segundo ele, desenvolvedores experientes não têm memória maior; apenas conhecem tão bem o código que blocos inteiros se tornam unidades familiares.

O React DevTools mostra a árvore de pais e, ao selecionar um componente, a árvore de donos. Para o autor, essa visualização continua textual, parece um muro de nomes com indentação e não mostra as duas árvores juntas.

A notação

Antes de criar a ferramenta, o autor desenhava à mão pequenos diagramas em papel para entender partes do código, com círculos para os componentes. Ele formalizou esses rascunhos na série Parents & Owners e agora propõe uma notação visual, que chama de parent-owner trees. A ferramenta atual foi feita com o Claude Code sobre a biblioteca bippy, que lê a árvore de fibers de um app em execução ou de um trecho de código.

Na árvore de pais, a aninhagem do JSX mostra onde a saída de cada componente aparece. A relação de dono, que indica quem criou o elemento e de onde vêm as props, aparece como arcos tracejados. Quando as duas árvores coincidem, o arco fica junto ao cotovelo; quando divergem, o arco salta de linha. Segundo o autor, isso acontece quando se passa JSX a um componente por props, como children ou sidebar.

A notação usa marcas para componentes próprios, elementos do DOM e as APIs do React, como Suspense, error boundaries, context, memo, lazy, Profiler, Activity, ViewTransition e createPortal. Quadrados preenchidos representam os wrappers. Uma área é exclusiva quando o wrapper mais próximo vence, como em Suspense e contextos, ou inclusiva quando todos se aplicam, como em Profiler e Activity.

Memo, contexto e limites de renderização

No React.memo, um disco marca o ponto em que as props são comparadas com o snapshot anterior. O autor observa que o React Compiler faz essa memoização no build, por isso o uso manual de memo deve se tornar mais raro. Nesse caso, o compilador armazena os elementos no componente pai, e não há disco no filho.

No contexto, a área mostra quem pode consumir o valor, e as linhas ligam o valor aos componentes que chamam useContext. Um componente pode estar na área sem ler o contexto. O autor argumenta que o contexto segue a árvore de pais, enquanto as props seguem a árvore de donos.

Suspense e error boundaries são mostrados como áreas que o fallback substitui. Os fallbacks declarados aparecem tracejados, indicando que não estão montados. O autor lembra que o React ainda não tem error boundary baseado em hooks e que a biblioteca react-error-boundary preenche essa lacuna.

Server Components

O autor afirma não ter escrito nenhum Server Component, por isso fala com cautela. Ele diz que a diferença entre árvore de pais e de donos é central para entender o limite entre servidor e cliente. Componentes de servidor aparecem em outra cor e em itálico, sem fiber no cliente. Um componente de servidor passado como children a um componente cliente aparece dentro de uma subárvore cliente, e seu arco de dono continua saindo do componente de servidor original. Para ele, esse entrelaçamento é difícil de ver no código e fica visível na árvore de donos.

Para que serve

O objetivo principal é ajudar as pessoas a entender melhor o React. Para o autor, a estrutura entre componentes é importante, implícita e difícil de enxergar, e um diagrama pode funcionar como o que diSessa chama de material intelligence, pensamento apoiado em materiais externos. Ele já usou os diagramas em posts e em revisões de código, para mostrar como os componentes poderiam ser compostos melhor.

O autor também relaciona o tema à revisão de código gerada por IA. Ele diz que hoje escreve pouco React à mão e revisa o que o Claude Code gera. Como o código ficou barato, o que resta revisar é a composição. Ele cita Geoffrey Litt, para quem a compreensão virou gargalo, e Karpathy, que sugeriu pedir a um LLM um diagrama do que foi construído. O autor observa que cada modelo pode inventar sua própria notação, enquanto uma gramática visual compartilhada permite ler diagramas novos porque as regras não mudam.

Limites e próximos passos

O autor reconhece que a ferramenta ainda está longe de estar pronta. Ela funciona com exemplos pequenos e curados, não com uma base de código real. O maior problema em aberto é mostrar sob demanda a parte certa de uma árvore grande. A notação também deixa de fora hooks, props individuais, renderização condicional e re-renders. Como direção futura, ele cogita uma integração bidirecional com o código, em que editar o diagrama altere o código, e diz que os diagramas talvez sejam mais úteis no editor do que em um navegador.