Pule para o conteúdo principal

A Extração da Biblioteca Que Mudou Tudo

Como a integração da nossa interface de chat e sistema de arquivos em pacotes reutilizáveis transformou um único produto em uma plataforma.

O momento em que um produto se torna uma plataforma

Há um momento específico na vida de todo produto em que ele deixa de ser um aplicativo único e começa a ser uma plataforma. Para nós, esse momento foi em 26 de novembro de 2025 — cinco dias após o primeiro commit.

Foi quando extraímos nossa interface de chat, sistema de arquivos virtual e utilitários principais em três pacotes separados e reutilizáveis: @fulldiveVR/chat-ui, @fulldiveVR/vfs-ui e @fulldiveVR/core-ui-utils.

Parece uma decisão de engenharia. Na verdade, foi uma decisão de negócios.

Por que fizemos isso no quinto dia, e não no quinquagésimo

A sabedoria convencional diz: não extraia bibliotecas muito cedo. Espere até ter um segundo caso de uso. Espere até que a API se estabilize. Espere até “saber o que você está construindo.”

Ignoramos tudo isso.

Aqui está o motivo: sabíamos que teríamos múltiplos produtos usando a mesma interface de chat. Sabíamos que a UI de gerenciamento de arquivos seria necessária em diferentes contextos. E sabíamos que quanto mais esperássemos, mais esses componentes estariam acoplados às necessidades específicas do dashboard.

No quinto dia, o pacote chat-ui tinha cerca de 2.000 linhas de código. Limpo. Bem definido. Fácil de extrair.

Se tivéssemos esperado até o quinquagésimo dia, teria sido 10.000 linhas com dezenas de dependências implícitas no estado, roteamento e configuração específicos do dashboard. Extrair isso então teria sido um projeto de várias semanas em vez de um de dois dias.

O que extraímos

chat-ui — Todo o sistema de renderização de chat. Balões de mensagem, respostas em streaming, anexos de arquivos, troca de agentes, exibição de chamadas de ferramentas. Tudo o que um usuário vê quando conversa com um agente de IA.

vfs-ui — A interface do sistema de arquivos virtual. Árvores de arquivos, criação de pastas, pré-visualizações de arquivos, arrastar e soltar, diálogos de upload. Tudo o que um usuário vê ao gerenciar seus arquivos.

core-ui-utils — Utilitários compartilhados. Tokens de tema, hooks comuns, primitivas de layout. As coisas que tanto chat-ui quanto vfs-ui precisam, mas que nenhuma delas deve possuir.

Cada um se tornou um pacote npm versionado, publicado no GitHub Packages, consumido pelo dashboard como qualquer outra dependência.

Os retornos compostos

Em fevereiro de 2026, nosso pacote chat-ui estava na versão 2.0.12. Isso representa dezenas de lançamentos — cada um melhorando a experiência de chat em todos os produtos que o utilizam.

Quando adicionamos mensagens de tarefas em segundo plano ao chat-ui, todos os produtos receberam mensagens de tarefas em segundo plano. Quando adicionamos mensagens de usuário colapsáveis, todos os produtos ganharam mensagens de usuário colapsáveis. Quando corrigimos um bug de renderização, todos os produtos receberam a correção.

Esse é o retorno composto da extração precoce: as melhorias se multiplicam.

Mas vai além da reutilização de código. Extrair essas bibliotecas nos forçou a pensar sobre nossas interfaces. O que um componente de chat precisa saber? O que um gerenciador de arquivos precisa de sua aplicação host? Essas perguntas, feitas cedo, produziram respostas mais limpas do que teriam meses depois, quando tudo estava entrelaçado.

O benefício inesperado: velocidade

Aqui está o que mais nos surpreendeu. Após o custo inicial de extração (cerca de dois dias de refatoração), nossa velocidade de desenvolvimento aumentou.

Por quê? Porque os limites estavam claros. Trabalhar na experiência de chat significava trabalhar no chat-ui. Trabalhar no gerenciamento de arquivos significava trabalhar no vfs-ui. Não havia “eu mudei o chat e quebrei o gerenciador de arquivos” porque eram literalmente pacotes separados com interfaces definidas.

Novos membros da equipe podiam trabalhar no chat-ui sem entender todo o código do dashboard. Relatórios de bugs podiam ser imediatamente triados para o pacote certo. Os testes eram mais rápidos porque cada pacote tinha seu próprio conjunto de testes.

A lição para outros construtores

Se você pode desenhar uma caixa em torno de um componente — se ele tem entradas claras, saídas claras e um propósito claro — extraia-o cedo. Não espere pelo mítico “momento certo.” O momento certo é quando a extração é pequena e barata. Essa janela se fecha mais rápido do que você imagina.

Extraímos três bibliotecas na primeira semana. Oitenta dias depois, elas foram atualizadas mais de cem vezes. Cada atualização melhorou cada produto. Esse é o tipo de alavancagem que transforma uma pequena equipe em uma produtiva.

Como extraímos três bibliotecas em uma semana

  1. 1

    Identifique os limites

    A renderização de chat, gerenciamento de arquivos e utilitários principais tinham interfaces claras. Tudo que estava por trás dessas interfaces poderia ser movido para pacotes.

  2. 2

    Extrair e publicar

    Movemos chat-ui, vfs-ui e core-ui-utils para pacotes separados no GitHub Packages. O mesmo código, devidamente escopado.

  3. 3

    Consuma nossos próprios pacotes

    O painel mudou de código local para pacotes publicados. Se isso quebrasse para nós, quebraria para qualquer um.

  4. 4

    Itere na velocidade do pacote

    Agora, as melhorias no chat-ui beneficiam todos os produtos que o utilizam. Uma solução, em todos os lugares.

Perguntas sobre extração de biblioteca

Não é cedo demais para extrair bibliotecas na primeira semana?

Depende. Se os limites estão claros — e com a interface de chat e gerenciamento de arquivos, estavam — a extração antecipada previne entrelaçamento. É muito mais difícil extrair uma biblioteca de um código que vem crescendo junto por seis meses.

Como você gerencia o versionamento entre pacotes?

Versionamento semântico. Mudanças que quebram a compatibilidade recebem um aumento maior. Atualizamos o painel com frequência — às vezes várias vezes por dia — assim conseguimos identificar regressões rapidamente.

Isso atrasou o desenvolvimento?

Por cerca de dois dias, sim. Depois disso, o desenvolvimento acelerou significativamente. As mudanças na biblioteca de UI melhoraram automaticamente todos os produtos que a utilizam.