DEV Community: jreeeedd

Otimizando a perfomance do Schepta com React

jreeeedd — Thu, 16 Apr 2026 22:04:16 +0000

Quando você cria um formulário com dezenas de campos, cada digitação do usuário não deveria custar mais do que alguns microssegundos de trabalho do JavaScript mas na maioria das bibliotecas de formulário, uma única tecla pressionada causa uma cascata de re-renders que percorre toda a árvore React — do componente raiz até os filhos.

Esse artigo documenta as otimizações que fizemos no Schepta para eliminar esse problema com algumas mudanças arquiteturais que mudam fundamentalmente onde o estado vive e quem é notificado quando ele muda.

O problema: onde o estado mora importa

Num formulário típico construído com useState, o estado de todos os campos vive num único objeto no topo da árvore:

FormFactory (state: { nome, email, telefone, ... })
  └── ScheptaFormProvider (context: { values, adapter })
        └── Context.Provider  ← emite novo valor a cada keystroke
              └── Seção A
                    └── Campo "nome"    ← re-renderiza (faz sentido)
                    └── Campo "email"   ← re-renderiza (não precisa)
              └── Seção B
                    └── Campo "telefone" ← re-renderiza (não precisa)

O React Context não é granular. Quando qualquer valor no contexto muda, todos os consumidores daquele contexto re-renderizam (mesmo que o campo específico não tenha mudado).

A solução em três camadas

Camada 1 — O adapter não depende mais do React para escrever

Antes, quando o usuário digitava algo, o NativeReactFormAdapter chamava this.setState — o setter do useState do FormFactory. Isso colocava o React no caminho crítico de toda escrita:

setValue("nome", "João")
  → this.setState({ nome: "João", ... })   ← React setState
  → FormFactory re-renderiza
  → ScheptaFormProvider re-renderiza
  → Context.Provider emite novo valor
  → TODOS os campos re-renderizam

A mudança: o adapter agora é self-contained. O estado vive em this.state (JS puro), e as escritas notificam diretamente os subscribers via um sistema de pub/sub interno, sem passar pelo React:

setValue(field: string, value: any): void {
  // Atualiza estado interno (JS síncrono, sem React)
  this.state = { ...this.state, [field]: value };
  this._version++;

  // Notifica só quem precisa saber
  this._fieldSubscribers.get(field)?.forEach(cb => cb());
  this._globalSubscribers.forEach(cb => cb());
}

O adapter ganhou também um método setValues para resets e hidratação externa, que notifica todos os subscribers de uma vez.

Camada 2 — O contexto React se torna estável

Com o adapter self-contained, não há mais razão para passar values pelo contexto. O contexto agora carrega apenas uma coisa: a referência estável do adapter. E essa referência nunca muda após o mount.

// Antes: contexto mudava a cada keystroke
const contextValue = useMemo(() => ({ adapter, values }), [adapter, values]);

// Depois: contexto nunca muda
const contextValue = useMemo(() => ({ adapter }), []); // deps vazias

Com isso, useContext(ScheptaFormContext) deixa de disparar re-renders. O React não tem mais nada novo para propagar.

Para que os campos ainda recebam seus valores de forma reativa, usamos useSyncExternalStore — que conecta diretamente ao pub/sub do adapter, sem passar pelo contexto:

export function useScheptaFieldValue(field: string): any {
  const { adapter } = useContext(ScheptaFormContext); // stable, never re-renders

  const subscribe = useCallback(
    (onStoreChange: () => void) => adapter.subscribeField(field, onStoreChange),
    [adapter, field]
  );
  const getSnapshot = useCallback(
    () => adapter.getFieldSnapshot(field),
    [adapter, field]
  );

  return useSyncExternalStore(subscribe, getSnapshot, getSnapshot);
}

useSyncExternalStore é a API do React 18 projetada exatamente para esse padrão: stores externos que gerenciam seu próprio estado. Ela garante que só o campo cujo valor mudou re-renderiza, e nenhum outro.

Camada 3 — O FormFactory só re-renderiza quando precisa

Num formulário sem templates dinâmicos, o FormFactory não precisa saber nada sobre o que o usuário está digitando. Ele renderizou a estrutura do formulário uma vez e seu trabalho está feito.

Mas o Schepta suporta expressões como {{ $formValues.tipo === 'pj' }} para mostrar/esconder campos condicionalmente. Nesses casos, o FormFactory precisa re-rodar o orchestrator quando os valores mudam.

A solução: detectar isso em tempo de configuração, não em tempo de execução.

// Checagem estática feita uma vez por schema (useMemo([schema]))
const needsFormValueRerender = useMemo(
  () => hasFormValueTemplates(schema),
  [schema]
);

hasFormValueTemplates percorre o schema recursivamente e retorna true se encontrar qualquer {{ ... }} que referencie $formValues. Para formulários que só usam $externalContext ou não têm templates, retorna false.

Com isso, o FormFactory só se inscreve no adapter se o schema realmente precisar:

const subscribeToAdapter = useCallback(
  (onStoreChange: () => void) => {
    if (needsFormValueRerender && adapter instanceof NativeReactFormAdapter) {
      return adapter.subscribeAll(onStoreChange);
    }
    return () => {}; // no-op para formulários estáticos
  },
  [needsFormValueRerender, adapter]
);

O resultado no Profiler

Antes

Ao digitar em qualquer campo, o React Profiler mostrava:

FormFactory como origem do update
ScheptaFormProvider re-renderizando por consequência
Context.Provider emitindo novo valor
Todos os DefaultFieldRenderer na árvore re-renderizando

Depois

O mesmo keystroke no Profiler mostra apenas:

O DefaultFieldRenderer específico daquele campo re-renderizando
FormFactory não aparece mais como origem de updates
Todos os outros campos permanecem cinza (não re-renderizaram)

Resumo das mudanças

Antes	Depois
`setValue` → `setState` React → FormFactory re-renderiza	`setValue` → `this.state` JS → só o campo re-renderiza
Contexto carrega `{ adapter, values }` — muda a cada keystroke	Contexto carrega `{ adapter }` — nunca muda
Todos os `useContext()` re-renderizam quando qualquer valor muda	`useSyncExternalStore` isola cada campo individualmente
FormFactory sempre re-renderiza em formulários com valores	FormFactory re-renderiza somente se o schema usa `{{ $formValues.* }}`
`React.memo` ineficaz (context cascade sobrepõe o memo)	`React.memo` funciona como esperado — compara props, não cascata

O que não mudou

A API pública do Schepta permanece idêntica. FormFactory, ScheptaFormProvider, useScheptaFieldValue, useScheptaFormValues — tudo funciona exatamente como antes. A otimização é transparente para quem usa a biblioteca.

Formulários com templates dinâmicos como {{ $formValues.tipo === 'pj' }} continuam funcionando corretamente: o FormFactory detecta automaticamente que precisa acompanhar as mudanças de valor e se inscreve no adapter de forma seletiva.

Onde e como usar o Schepta

jreeeedd — Thu, 26 Mar 2026 16:20:19 +0000

Este artigo é para quem vai adotar o Schepta: planos futuros da arquitetura (outras factories além de forms), cenários de uso — multi-tenant, testes A/B, wizards, white-label — e por que a suite de testes garante que sua aplicação pode focar na parte de negócio. No final, um resumo prático de onde o projeto vive e da extensibilidade.

Planos futuros e arquitetura: outras factories, prioridade em forms

O core do Schepta (orquestrador, registry, middlewares, pipeline schema → render) é agnóstico do tipo de UI. O mesmo mecanismo que hoje alimenta o FormFactory pode alimentar outras factories — por exemplo MenuFactory (navegação dinâmica a partir de schema), dashboards, wizards. A arquitetura já prevê isso (tipos de componente como menu-item, menu-container na documentação de conceitos).

No momento foi priorizado forms porque grande parte da complexidade em aplicações multi-tenant está nos formulários: campos por tenant, validações por contexto, fluxos diferentes por cliente. Resolver bem “schema → form” desbloqueia o cenário mais doloroso; outras factories podem vir em seguida.

A arquitetura permite a criação de outras factories além de forms. A escolha de lançar com foco em forms é priorização (multi-tenant + complexidade), não limitação do desenho.

Outros usos além de multi-tenant

Multi-tenant já está no centro: um schema por tenant, UI consistente.

Testes A/B: o mesmo fluxo ou tela pode ser servido com schemas diferentes — por exemplo variação A com 3 campos, variação B com 5 campos ou ordem diferente. O backend ou a camada de feature flags entrega o schema da variação; o Schepta renderiza. Sem trocar código do app, só o JSON.

Wizards e fluxos dinâmicos: próximos passos ou telas dependentes de contexto (respostas do usuário, perfil, permissões) podem ser modelados como schemas diferentes por etapa; o Schepta renderiza cada etapa.

White-label / configuração por cliente: além de multi-tenant “duro”, cenários em que cada cliente tem sua própria definição de formulários (CRM, ferramentas internas); o schema vem de configuração ou API e o Schepta mantém a UI consistente.

Prototipagem e ferramentas low-code: ferramentas que geram ou editam schemas (por humano ou por IA) e usam o Schepta como runtime de preview ou produção.

Uso com IA e produtos no chat: um produto que roda diretamente dentro do chat (por exemplo via MCP — Model Context Protocol) mantém a consistência entre os componentes: o cliente cria o próprio MCP e disponibiliza nas tools o schema de acordo com o usuário e com o que ele está pedindo; o Schepta renderiza o formulário ou a UI no próprio chat. Assim, assistentes como o Claude podem invocar as tools (obter schema, validar, abrir preview) e a interface exibida é sempre a mesma engine Schepta, previsível e testável.

Schema-driven UI serve para vários problemas, não só “um form por tenant”.

Cenário	Como o Schepta ajuda
Multi-tenant	Um schema por tenant; mesma engine, UI consistente.
Testes A/B	Schemas diferentes por variação; sem alterar código.
Wizards	Um schema por etapa; renderização por contexto.
White-label	Schema por cliente via config ou API.
Low-code / IA	Runtime estável para schemas gerados ou editados.
IA / produto no chat	Cliente expõe schema nas tools do MCP; Schepta renderiza no chat com a mesma engine.

Testes como garantia: o app foca no negócio

O Schepta é coberto por 103 testes unitários e 26 testes E2E (Playwright) que validam o fluxo completo: schema → resolução → render → interação em React, Vue e Vanilla, incluindo integrações com react-hook-form e Formik. Isso garante que a engine se comporta corretamente — resolução de componentes, middlewares, validação, binding de campos.

Ao adotar o Schepta, o time do app não precisa se preocupar com “será que o schema vira componente certo?”, “será que o middleware roda na ordem?”, “será que o form adapter conecta?”. Esses detalhes estão cobertos pela suite; regressões da engine são detectadas antes de chegar ao app.

Nos aplicativos que usam o Schepta, o time pode concentrar esforço na parte voltada para negócio: validações específicas do domínio, regras de negócio em middlewares, definições de forms por contexto ou tenant, integração com APIs e fluxos. A “infraestrutura” de schema→UI está testada e estável.

Os testes são a garantia de que as funcionalidades da engine funcionam, abstraindo esses detalhes para que, nos apps onde o Schepta será usado, as preocupações sejam apenas a parte voltada para negócio (validações específicas, definições específicas de forms, etc.).

Em resumo

Onde vive: monorepo com @schepta/core, adapters (react, vue, vanilla), factories por framework; documentação e exemplos em schepta.org.
Testes: 103 testes unitários e 26 testes E2E (React, Vue, Vanilla), incluindo react-hook-form e Formik — garantia da engine; o app foca em lógica de negócio.
Extensibilidade: middlewares para transformar props; registry para trocar componentes; renderers por tipo (field, container, button, content); expressões em props com $formValues e $externalContext.

Showcases por framework (React, Vue, Vanilla, MUI, Chakra, Vuetify, etc.) estão disponíveis na documentação.

Próximo passo

No último artigo da série entramos em como o Schepta funciona por dentro: factories, orquestradores, component registry e o pipeline de resolução até o render. Para quem quer profundidade técnica.

Enquanto isso: schepta.org para docs e exemplos.

Why I didn't take the common path

jreeeedd — Sat, 14 Mar 2026 16:26:00 +0000

The current moment in software development is pushing many devs toward two paths: microsaas (or a closed product) to monetize quickly, or betting on AI agents and agentic automation — products and tools where the agent "resolves" tasks on its own. This article is about why I didn't go that route. An analysis of the landscape, a conscious choice, and a provocation: the common path is legitimate, but it's not the only one.

What's at stake

There's pressure for revenue, for visible impact, for surfing the wave of the moment. Microsaas has become a shortcut for many indie developers: lean product, subscription, growth. On the other side, AI agents and agentic workflows have gained traction — the idea that AI isn't just an assistant, but an autonomous workforce that reads code, implements features, opens PRs. In 2025–2026 this stopped being just an experiment and became a concrete option for both product and positioning.

None of this is wrong. These are choices. What I want to make clear is: why, in the case of Schepta, I chose a different path.

Foundation before agent, value before price

At some point you've probably seen the same thing I have: devs launching microsaas, others automating everything with agents, the feeling that anyone not on that track is leaving money on the table.

I considered both paths.

Microsaas brings contracts, pricing, and vendor lock-in before the value is proven. For a problem like this — turning a schema into real UI, stably across multiple frameworks — that's friction before its time. The value needs to be demonstrated first; the business model comes after.
Agents have a similar appeal: automating interface generation seems like the obvious next step. But agents that generate or modify UI need a stable foundation to operate on — a clear, auditable contract between backend, agent, and frontend. Building the agent before that foundation is fragile. Order matters: first the engine works well, then the agent has something solid to build on.

But a stable foundation has a cost: it needs to be proven. Broken forms and flows impact users and business directly — it's a mission-critical problem. Schepta's 100+ unit and E2E tests exist exactly for this reason: so the engine is reliable enough to be extended, contributed to, and used in production without surprises.

And that was the path I chose. Whether it was the right one, only time will tell.

If this discussion about paths resonated with you, Schepta's documentation and examples are waiting for you at schepta.org.

What about you: are you on the microsaas path, the agents path, or building something else entirely? What drove your decision?

Next step

In the next article in the series we talk about When AI generates the interface: the schema as a guardrail: how the ecosystem (json-render, A2UI) validates this approach, how Schepta responds to the problem of AI non-determinism, and how it fits into workflows ranging from assisted coding to 100% automated agents.

What Schepta is and what problem it solves

jreeeedd — Sat, 14 Mar 2026 15:10:27 +0000

This article explains what Schepta is, the problem it solves, and the space it fills. Why I chose an open source library over a microsaas — and why I haven't (yet) bet on AI agents that resolve tasks autonomously — is the topic of the next article in the series.

What it is and what problem it solves

Schepta is a tool that turns an interface description — in JSON format — into real screens and forms, without having to write each screen by hand in code. That description can be interpreted in React, Vue, or plain JavaScript, depending on the project.

The problem it helps solve shows up when the interface depends on many contexts: multiple clients (multi-tenant), multiple flows, A/B tests, or when the backend — or even AI tools — define what should appear on screen. In those cases, writing and maintaining each variation in code becomes chaos. Schepta centralizes the screen definition in a single format (the schema); a single engine interprets that format and generates the interface. Those using Schepta can focus on business rules and on defining what to show in each context, instead of the implementation details of each variation.

Why Schepta exists — the space it fills

Schepta exists for scenarios where you need the interface definition (what to show, in what order, with what validations) to be treated as data — a schema that carries UI semantics, not just data validation. It was designed to be framework-agnostic: the same schema works in React, Vue, or plain JavaScript. The core is lean and extensible, with sensible defaults you can swap out when needed. And the entire flow was built for server-driven or context-driven UI — for example, one schema per client or per tenant — not just for fixed forms defined at build time.

If this space makes sense for your project, Schepta is an option. The choice between Schepta and other tools depends on the needs of each project and team; what matters is that this space exists and that Schepta is here to fill it.

If this problem sounds familiar, the guide, documentation, and examples (React, Vue, and Vanilla) are at schepta.org.

Have you ever dealt with this chaos of forms that change per client, A/B test, or backend? How did you solve it?

Next step

In the next article in the series I talk about why I didn't take the common path: an analysis of the current moment in software development, what many devs are doing (microsaas, AI agents, and agentic automation) — and why I chose an open source library, without SaaS and without betting (yet) on agents that resolve tasks autonomously.

Quando a IA gera a interface: o schema como guardrail

jreeeedd — Fri, 13 Mar 2026 22:28:37 +0000

Schepta no mundo das IAs

Grandes players na corrida de IA e de plataformas já adotam a ideia de “UI a partir de JSON” ou protocolos declarativos. O Schepta não está inventando o conceito; está implementando uma engine framework-agnostic no mesmo espaço. Neste artigo: como essa tendência valida o caminho, como o Schepta responde ao problema do não-determinismo das IAs e como ele se encaixa em fluxos que vão do código assistido ao 100% automatizado com agents.

Validação: json-render e o ecossistema

A ideia de usar schema ou JSON como fonte da verdade para a interface já é levada a sério por quem constrói ferramentas de desenvolvimento. Projetos como o json-render (Vercel) focam em renderizar UI a partir de JSON no ecossistema React. O A2UI (Google) é um projeto aberto para interfaces dirigidas por agentes: um único spec em JSON pode ser renderizado em várias plataformas (web, Flutter, etc.). Isso reforça que o caminho do Schepta — especificação declarativa, múltiplos runtimes — está alinhado com a direção do mercado.

O Schepta implementa uma engine com foco em forms e extensibilidade (middlewares, registry), no mesmo espaço conceitual em que esses projetos atuam. A citação aqui é de validação: o caminho é válido.

Schepta como resposta ao não-determinismo das IAs

IAs são não determinísticas. A mesma pergunta pode gerar saídas diferentes; código ou UI gerados diretamente por LLMs variam em formato, estilo e até correção. Colocar isso direto na tela ou no código da aplicação gera imprevisibilidade e risco.

O Schepta introduz uma camada de contrato. Em vez de a IA gerar componentes ou markup solto, ela gera — ou o desenvolvedor edita — um schema JSON. Esse schema é validado (estrutura, tipos, regras) e só então é transformado em UI pelo motor do Schepta. Ou seja: dado um schema válido, a UI é determinística. A não-determinismo fica contida na produção ou edição do schema; a renderização é sempre previsível e testável.

Em fluxos com IA — copilot, agents, backends que montam UI dinamicamente — você precisa de um ponto de estabilidade. O schema é esse ponto: pode ser gerado por IA, por humano ou por um agent; uma vez válido, o Schepta garante o mesmo resultado. Testes E2E podem rodar sobre schemas fixos; regressões vêm de mudanças no schema, não de variação aleatória do render.

Em resumo: o Schepta é a camada que torna a UI previsível mesmo quando a fonte (IA, agent, backend) não é.

Fluxos de trabalho com IA: do código assistido ao 100% automatizado

O Schepta se posiciona em um contínuo de fluxos com IA.

Código assistido (human-in-the-loop): o desenvolvedor usa IA para sugerir ou gerar schemas (por exemplo: “gera um form de cadastro com email, nome, aceite de termos”); revisa e ajusta o JSON; o Schepta renderiza. A IA acelera a produção do schema; o humano valida; a engine garante UI consistente.

Híbrido (IA gera, humano aprova): o backend ou uma ferramenta alimentada por IA produz o schema (formulário por tenant, wizard por contexto); um passo de aprovação ou validação — humano ou por regras — pode existir antes de enviar ao front; o Schepta recebe o schema e renderiza. Ainda há controle; a renderização continua determinística.

100% automatizado (agents): um agent toma decisões e produz o schema (por exemplo um assistente que monta a tela conforme a conversa); o schema é enviado ao cliente; o Schepta renderiza sem intervenção humana. O contrato (schema) segue válido e versionável; o único não-determinismo está na geração do schema pelo agent; uma vez entregue, a UI é previsível e auditável.

Em todos os níveis, o Schepta oferece:

interface estável — sempre schema in, UI out;
validação na entrada — schema inválido não vira tela quebrada; 3. mesma engine para assistido e automatizado, permitindo evoluir o fluxo sem trocar de stack;
testabilidade — cenários com schemas fixos cobrem o comportamento do render independentemente de quem gerou o schema.

Do código assistido ao 100% automatizado com agents, o Schepta é a camada que transforma qualquer schema válido em UI determinística — seja o schema escrito à mão, sugerido por um copilot ou gerado por um agent. Já existe um exemplo concreto desse fluxo: o MCP do Schepta no Claude.

Demo: Schepta via MCP no Claude

O MCP (Model Context Protocol) permite que assistentes como o Claude usem ferramentas externas. Existe um MCP para o Schepta que expõe três ferramentas no Claude: obter o JSON Schema dos formulários, validar uma instância de formulário contra esse schema e abrir um preview do formulário diretamente no chat. Assim, você pode pedir ao Claude que crie ou edite um formulário Schepta em linguagem natural; o Claude chama as ferramentas (schema → validação → preview) e o formulário é renderizado na conversa.

Um exemplo de prompt que você pode usar para reproduzir a demonstração:

Crie um formulário de cadastro de funcionário usando o MCP do Schepta. O formulário deve ter as seções e campos abaixo:

Seção "Dados Pessoais"

Nome completo (InputText)

E-mail corporativo (InputText)

Telefone (InputPhone)

Seção "Cargo e Departamento"

Cargo (InputText)

Departamento (InputSelect)

Data de início (InputDate)

Configuração e descrição das ferramentas: Schepta MCP na documentação.

Próximo passo

No próximo artigo da série falamos de onde e como usar o Schepta: planos futuros (outras factories além de forms), outros usos (multi-tenant, testes A/B, wizards, white-label).

Por que não fui pelo caminho comum

jreeeedd — Fri, 13 Mar 2026 19:09:08 +0000

O momento atual no desenvolvimento de software empurra muitos devs para dois caminhos: microsaas (ou produto fechado) para monetizar rápido, ou apostar em agentes de IA e automação com agentes — produtos e ferramentas em que o agente “resolve” tarefas sozinho. Este artigo é sobre por que não fui por aí. Uma análise do cenário, uma escolha consciente e uma provocação: o caminho comum é legítimo, mas não é o único.

O que está em jogo

Há pressão por receita, por impacto visível e surfar a onda da vez. Microsaas virou atalho para muitos indies: produto enxuto, assinatura, crescimento. Do outro lado, agentes de IA e workflows agentic ganharam tração — a ideia de que a IA não é só assistente, mas workforce autônoma que lê código, implementa features, abre PRs. Em 2025–2026 isso deixou de ser só experimento e virou opção concreta de produto e de posicionamento.

Nada disso é errado. São escolhas. O que quero deixar claro é: por que, no caso do Schepta, escolhi outro caminho.

Base antes de agente, valor antes de preço

Em algum momento você provavelmente viu o mesmo que eu: devs lançando microsaas, outros automatizando tudo com agents, a sensação de que quem não está nessa trilha está deixando dinheiro na mesa.

Eu considerei os dois caminhos.

Microsaas traz contrato, preço e vendor lock-in antes de o valor estar provado. Para um problema como esse — transformar um schema em UI real, de forma estável em vários frameworks — isso é fricção antes da hora. O valor precisa ser demonstrado primeiro; o modelo de negócio vem depois.
Agents têm um apelo parecido: automatizar a geração de interface parece o passo óbvio. Mas agents que geram ou alteram UI precisam de uma base estável para operar — um contrato claro e auditável entre backend, agent e frontend. Construir o agent antes dessa base é frágil. A ordem importa: primeiro a engine funciona bem, depois o agent tem onde se apoiar.

Mas base estável tem um custo: precisa ser provada. Formulários e fluxos quebrados impactam usuário e negócio diretamente — é um problema mission critical. Os mais de 100 testes unitários e E2E do Schepta existem exatamente por isso: para que a engine seja confiável o suficiente para ser estendida, contribuída e usada em produção sem surpresas.

E esse foi o caminho que eu escolhi, se foi o correto ou não, somente o tempo dirá.

Se essa discussão de caminhos fez sentido pra você, a documentação e os exemplos do Schepta estão te esperando em schepta.org.

E você: está no caminho do microsaas, dos agentes ou tá construindo alguma outra coisa? Qual foi a linha que você seguiu pra tomada de decisão?

Próximo passo

No próximo artigo da série falamos de Quando a IA gera a interface: o schema como guardrail: como o ecossistema (json-render, A2UI) valida essa abordagem, como o Schepta responde ao problema do não-determinismo das IAs e como ele se encaixa em fluxos que vão do código assistido ao 100% automatizado com agents.

O que é o schepta e que problema ele resolve

jreeeedd — Fri, 13 Mar 2026 15:39:44 +0000

Este artigo explica o que é o Schepta, que problema ele resolve e que espaço ele preenche. Por que escolhi uma lib open source em vez de microsaas e por que não apostei (ainda) em agentes de IA que resolvem tarefas sozinhos é o tema do próximo artigo da série.

O que é e que problema resolve

O Schepta é uma ferramenta que transforma uma descrição da interface — em formato JSON — em telas e formulários reais, sem precisar escrever cada tela à mão em código. Essa descrição pode ser interpretada em React, Vue ou JavaScript puro, conforme o projeto.

O problema que ele ajuda a resolver aparece quando a interface depende de muitos contextos: vários clientes (multi-tenant), vários fluxos, testes A/B, ou quando o backend e até ferramentas de IA definem o que deve aparecer na tela. Nesses casos, escrever e manter cada variação em código vira caos. O Schepta centraliza a "definição" da tela num único formato (o schema); uma única engine interpreta esse formato e gera a interface. Quem usa o Schepta pode focar nas regras de negócio e na definição do que mostrar em cada contexto, em vez dos detalhes de implementação de cada variação.

Por que o Schepta existe — que espaço ele preenche

O Schepta existe para cenários em que você precisa que a definição da interface (o que mostrar, em que ordem, com que validações) seja tratada como dado — um schema que carrega semântica de UI, não só de validação de dados. Ele foi pensado para ser agnóstico de framework: o mesmo schema pode ser usado em React, Vue ou JavaScript puro. O núcleo é enxuto e extensível, com padrões sensatos que você pode trocar quando precisar. E o fluxo todo foi desenhado para interface dirigida por servidor ou por contexto — por exemplo um schema por cliente ou por tenant —, não só para formulários fixos definidos no momento do build.

Se esse espaço faz sentido para o seu projeto, o Schepta é uma opção. A escolha entre usar o Schepta ou outras ferramentas depende das necessidades de cada projeto ou de cada time; o que importa é que esse espaço existe e que o Schepta está aí para preenchê-lo.

Se esse problema te soa familiar, o guia, a documentação e os exemplos (React, Vue e Vanilla) estão em schepta.org.

E você: já passou por esse caos de forms que mudam por cliente, A/B ou backend? Como resolveu?

Próximo passo

No próximo artigo da série conto por que não fui pelo caminho comum: uma análise do momento atual no desenvolvimento de software, o que muitos devs estão fazendo (microsaas, agentes de IA e automação com agentes) e por que escolhi uma lib open source, sem SaaS e sem apostar (ainda) em agentes que resolvem tarefas sozinhos.