Skip to content

🚀 O Design System Algébrico e a Fronteira dos "Design Tokens" #2

Description

@salespaulo

Visão Geral

Iremos sair de um modelo legado baseado em Orientação a Objetos (onde componentes misturavam estado, comportamento e mutações de DOM) para abraçar o Design System Algébrico focado em Programação Funcional (Gleam + Lustre). Nosso objetivo foi tornar os estados visuais inválidos impossíveis de serem compilados, isolando a regra de negócio da representação visual.

✅ Fase 1: O Estado Atual (A Fundação Sólida)

Atualmente, alcançamos uma arquitetura pragmática e altamente resiliente focada na Web (Tailwind + HTML).

  • Vocabulário Universal (ADTs): Criamos a ontologia do sistema em core/theme.gleam. Dimensões como UIVariant, UISize, UIAppearance e UIState são tipos algébricos fortes. A identidade semântica foi completamente separada do comportamento.
  • Componentes Atômicos Puros: Componentes como typo, button e input são funções puras e cegas. Eles não gerenciam estado (MVU purista), apenas refletem os dados passados.
  • O Pipeline de Strings (Record + Interpreter): Resolvemos a complexidade da renderização usando o padrão Interpreter. O engine.compose varre um Record de gavetas (UITheme) e processa as regras de estilização (o nosso "Motor V8" privado no componete).
  • A Fronteira de Responsabilidade (SRP): O motor de temas retorna estritamente List(#(String, Bool)). Ele é proibido de retornar Attribute(msg) do Lustre, garantindo que o motor de estilos jamais tenha poderes para injetar eventos ou manipular o DOM acidentalmente.

Os commits ainda serão enviados, aguarde...

👾 Fase 2: O Chefão Final (O Futuro Multiplataforma)

Nosso "Pipeline de Strings" atual nos acopla inevitavelmente à gramática do Tailwind CSS, ou pior à soluções "String Typed Programming". Para alcançarmos a universalidade real e renderizarmos nossas interfaces em PDFs, planilhas Excel ou displays E-Ink (IoT), precisamos transcender as strings.

O Objetivo (To-Do):

  • Migrar do "Stringly Typed" para "Design Tokens": Substituir o retorno de List(#(String, Bool)) dos nossos motores locais por uma AST intermediária List(DesignToken).
  • Desacoplamento de Adaptadores (Ports & Adapters): O motor passará a retornar valores físicos literais (ex: TokenBackground(RGB(37, 99, 235))).
  • Múltiplos Renderizadores: Criar interpretadores finais específicos por plataforma (ex: tokens_to_tailwind para a Web, tokens_to_pdf_commands para os relatórios).

Conclusão: A Fase 1 nos entrega um produto Web perfeito e blindado. A Fase 2 será ativada quando a necessidade de novas plataformas (PDF/Nativo) for exigida pelo negócio, mantendo as nossas ADTs (UIVariant, etc.) intactas.

🌌 Fase 3: A Singularidade (Code Generation & Design Tokens)

Quando a nossa arquitetura transcender as strings do Tailwind (Fase 2), daremos o passo final rumo à automação absoluta.

  • O Objetivo: Eliminar a escrita manual de motores de estilo (paint_theme).
  • A Ferramenta: Criar um script de build (./dev/generator.gleam) capaz de ler arquivos JSON padronizados (exportados pelo Figma Tokens/Token Studio).
  • O Fluxo: O script fará o parse do JSON dos designers e gerará automaticamente o código Gleam das nossas matrizes ComponentTheme, garantindo que o código em produção seja um espelho exato (1:1) do que foi desenhado no Figma, sem intervenção humana no CSS.
  • Resultado: Designers controlam a UI via JSON; o compilador do Gleam garante a segurança; os desenvolvedores focam apenas na lógica de negócio.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestepicSe estendem por meses, anos e talvez nunca terminem, épicos de trabalho desta biblioteca.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions