Headless
Até aqui a documentação assumiu o caminho principal: um app gerado que renderiza a partir do manifesto pelo runtime da plataforma. Existe um segundo caminho, para quando você já tem um site sob medida e quer só algumas capacidades do Fayz dentro dele — não o shell inteiro. É o modo headless.
Esta página descreve o conceito e o formato. O empacotamento headless dos plugins está chegando com os plugins de website (blog, payments, agenda público) — por isso as importações concretas ainda não são mostradas aqui: elas só serão publicadas quando os pacotes exportarem o subpath. Experimental
A ideia
No caminho principal, o Fayz é dono da página: o shell, o menu e o layout vêm do scaffold, e você liga plugins. No caminho headless, você é dono da página — um site bespoke em qualquer framework — e importa de um plugin só o que precisa: os dados e os componentes de uma capacidade, sem o shell.
Isso serve para sites de marketing que querem, por exemplo, um blog e um botão de agendamento embutidos no design próprio, sem adotar a navegação do admin.
O formato: um bundle { manifest, Provider } + subpaths
O plano de empacotamento é que cada plugin voltado a website exponha um bundle headless com duas peças:
manifest— o mesmoPluginManifestque descreve a capacidade (o contrato não muda entre os dois caminhos).Provider— um provider React que injeta o contexto do plugin (data provider, tenant) na sua árvore, para os seus componentes consumirem via hooks.
O componente de cada capacidade é servido por um subpath dedicado do pacote (ex.: a peça pública de agendamento, separada da peça de admin). Você monta o Provider uma vez na raiz do seu site e usa os componentes headless onde quiser no seu próprio layout.
Por que o contrato é o mesmo
O ponto que faz o headless valer a pena: um plugin não é reescrito para virar headless. O mesmo PluginManifest que roda no shell do admin roda dentro do seu site — muda só quem monta a página. É a mesma simetria da escada de personalização: o plugin declara a capacidade, e o host (o shell do Fayz ou o seu site) decide como renderizá-la.
Enquanto isso
Se você precisa hoje de um site sob medida com capacidades Fayz, o caminho suportado é o app gerado com um scaffold storefront e páginas recompostas via blocos (níveis 3–6 da escada de personalização). O modo headless completo — importar um bundle de plugin dentro de um projeto totalmente seu — chega com os plugins de website.
Próximo: entenda a biblioteca core que todos esses caminhos compartilham em Modelo de dados.