Atomic Design: a anatomia de uma interface

Se você já trabalhou em um projeto React maior, provavelmente já encontrou uma pasta cheia de componentes com nomes pouco claros: Button, ButtonPrimary, HeaderButton, HomeButton, NavbarButton...

Conforme o projeto cresce, organizar os componentes se torna um desafio. É justamente esse problema que o Atomic Design, criado por Brad Frost, busca resolver.

A ideia é simples: construir interfaces da mesma forma que a natureza constrói tudo ao nosso redor, começando pelas menores partes e evoluindo até formar estruturas completas.

O que é Atomic Design?

Atomic Design é uma metodologia para organizar interfaces em níveis de complexidade.

Em vez de pensar apenas em "componentes", pensamos em cinco camadas:

• Átomos
• Moléculas
• Organismos
• Templates
• Páginas

Cada camada possui uma responsabilidade bem definida.

Essa separação facilita o reaproveitamento de componentes e deixa a manutenção muito mais simples.

Átomos

⁠Átomos são os menores elementos da interface.

Eles não conhecem regras de negócio nem contexto. Apenas executam sua função.

Exemplos:

• Botão
• Input
• Label
• Ícone
• Avatar

Um botão simples pode ser implementado assim:

type ButtonProps = {
  children: React.ReactNode;
  onClick?: () => void;
};

export function Button({ children, onClick }: ButtonProps) {
  return (
    <button onClick={onClick}>
      {children}
    </button>
  );
}

Perceba que o componente não sabe onde será utilizado. Ele apenas renderiza um botão.

Moléculas

Uma molécula é formada por vários átomos trabalhando juntos.

Um bom exemplo é um campo de pesquisa.

Ele possui:

• Input
• Botão
• Ícone

Cada elemento continua sendo independente, mas juntos passam a resolver um problema específico.

export function SearchField() {
  return (
    <div>
      <input placeholder="Pesquisar..." />

      <Button>
        Buscar
      </Button>
    </div>
  );
}

Agora já existe uma responsabilidade clara: pesquisar.

Organismos

Organismos são conjuntos de moléculas formando uma seção completa da interface.

Um Header normalmente possui:

• Logo
• Campo de pesquisa
• Menu
• Avatar do usuário

export function Header() {
  return (
    <header>
      <Logo />

      <SearchField />

      <Navbar />

      <UserAvatar />
    </header>
  );
}

Observe que praticamente tudo já é reutilizado.

Templates

⁠
⁠Templates definem apenas o layout da página.

Eles dizem onde cada organismo ficará, mas ainda não possuem dados reais.

Por exemplo:

export function BlogTemplate() {
  return (
    <>
      <Header />

      <main>
        <Article />
      </main>

      <Footer />
    </>
  );
}

Nesse momento ainda não existe um artigo verdadeiro.

Páginas

A Página utiliza o Template e preenche os componentes com dados vindos de uma API ou CMS.

No caso de um projeto Next.js utilizando Hygraph, seria algo parecido com:

export default async function BlogPage() {
  const posts = await getPosts();

  return (
    <BlogTemplate posts={posts} />
  );
}

Agora a estrutura está completa.

Como isso ajuda em projetos React?

Sem uma organização bem definida, é comum encontrar componentes gigantes contendo centenas de linhas de código.

Isso dificulta:

• Reutilização
• Testes
• Manutenção
• Escalabilidade

Com Atomic Design, cada componente possui apenas uma responsabilidade.

Quando surge um novo projeto, grande parte dos componentes já pode ser reaproveitada.

Uma estrutura comum de pastas

Uma organização bastante utilizada é:

Só de olhar a estrutura já fica fácil entender onde cada componente deve ficar.

Atomic Design é obrigatório?

Não.

Projetos pequenos dificilmente precisam dessa divisão.

Por outro lado, aplicações grandes, desenvolvidas por várias pessoas e com dezenas de telas, costumam se beneficiar bastante dessa metodologia.

Ela torna o código mais previsível e facilita a evolução do projeto ao longo do tempo.

Conclusão

Atomic Design não é apenas uma forma de organizar pastas, mas uma maneira de pensar a construção de interfaces.

Ao dividir a aplicação em pequenas partes reutilizáveis, você reduz a duplicação de código, melhora a manutenção e torna o desenvolvimento mais consistente.

Independentemente do tamanho do projeto, compreender essa metodologia ajuda a criar componentes mais desacoplados e preparados para crescer junto com a aplicação.