Visão Geral para Desenvolvedores do FaceFlow
Visão Geral para Desenvolvedores do FaceFlow
FaceFlow é o núcleo estruturado de construção sem código dentro do PageFace.
Do ponto de vista técnico, é melhor entendido como um sistema de objetos reutilizáveis, renderização governada e limites claros de propriedade, em vez de um editor de página livre.
Modelo Técnico Central
FaceFlow é composto por um pequeno conjunto de tipos de objeto com responsabilidades distintas:
- Variáveis para fragmentos reutilizáveis e leves
- Componentes para contratos de seção reutilizáveis
- Layouts para molduras de página compartilhadas
- Páginas para experiências montadas
- Listas para saída dinâmica orientada por coleções
- Formulários para fluxos estruturados de envio
- Avaliações para conteúdo público de confiança moderado
Cada objeto existe para resolver um nível diferente do sistema do site. Quando esses limites permanecem claros, o FaceFlow continua sustentável em escala.
Como Pensar sobre o FaceFlow
O modelo mental mais limpo é:
Variables -> small reusable fragments
Components -> reusable sections
Layouts -> page shells
Pages -> assembled experiences
Lists -> dynamic archives and collections
Forms -> lead and request workflows
Reviews -> trust and proof workflowsIsto não é apenas uma hierarquia de conteúdo. É uma hierarquia arquitetural.
Limites dos Objetos
Use este modelo de decisão:
- Use uma Variável quando a unidade de reutilização for pequena e parametrizada
- Use um Componente quando a unidade de reutilização for uma seção completa com um esquema voltado ao editor
- Use um Layout quando a preocupação for o quadro da página ao redor de muitas Páginas
- Use uma Página ao montar uma rota ou experiência final
- Use uma Lista quando seleção de conteúdo e paginação fizerem parte do contrato
- Use um Formulário ao coletar envios estruturados
- Use uma Avaliação ao coletar e publicar feedback público governado
A maior parte da deriva técnica no FaceFlow acontece quando um objeto começa a assumir a responsabilidade de outro.
Exemplo de Sistema
Layout:
default-site-shell
Page:
/enterprise/
Components:
hero-banner
benefits-grid
demo-request-section
review-strip
Embedded systems:
<div data-form-embed="enterprise-demo-request"></div>
<div data-review-embed="customer-success-reviews"></div>
Variables:
[[site-announcement]]
[[sales-contact-badge]]Esse exemplo permanece sustentável porque cada preocupação tem um lar claro.
Escopo e Impacto das Mudanças
O escopo é um dos conceitos técnicos mais importantes no FaceFlow.
Ele controla se uma seção reutilizável se comporta como:
- um ativo de todo o site
- um ativo da família de Layouts
- um ativo local da Página
Quando usuários técnicos escolhem o escopo errado, o impacto das mudanças se torna difícil de prever. Uma seção local pode se tornar acidentalmente uma dependência global, ou conteúdo repetido em páginas pode permanecer duplicado muito depois de deveria ter sido compartilhado.
Camada de Templates
Os templates do FaceFlow são criados através do Facet.
Isso significa que usuários técnicos devem entender:
- saída de campo
- condicionais
- laços
- filtros
- incorporação de Variáveis
- composição segura de seções
Example:
<section class="hero">
<h1>{{ title }}</h1>
{{#if summary}}
<p>{{ summary }}</p>
{{/if}}
[[sales-contact-badge]]
</section>O Facet é a camada de templates. O FaceFlow é o sistema estruturado de objetos ao redor dele.
No que os Usuários Técnicos Devem se Concentrar
Ao projetar com FaceFlow, as decisões técnicas mais importantes geralmente são:
- onde a reutilização deve ocorrer
- quanto esquema uma seção deve expor
- se algo deve ser dinâmico ou estático
- qual é o verdadeiro raio de impacto de uma alteração em um recurso compartilhado
- quanto da página pertence ao Layout versus Componente versus Página na composição
Essas decisões têm mais impacto na manutenibilidade do que qualquer peça isolada de conteúdo de página.
Erros Técnicos Comuns
Evite estes padrões:
- usar Componentes onde Variáveis seriam mais claras
- usar Variáveis onde um esquema de seção real é necessário
- colocar conteúdo específico de página no Layout
- criar um Componente excessivamente grande que tenta resolver muitos casos de uso não relacionados
- tratar Listas como uma solução alternativa para arquitetura de conteúdo pouco clara
- incorporar fluxos de trabalho de negócio sem revisar o caminho completo de renderização e moderação
Ordem de Leitura Recomendada
Esse caminho vai das menores unidades reutilizáveis até a montagem completa do site e, em seguida, para a camada de templates.