Vue d'ensemble developpeur FaceFlow
Vue d'ensemble developpeur FaceFlow
FaceFlow est le noyau structure de construction no-code dans PageFace.
D'un point de vue technique, il se comprend mieux comme un systeme d'objets reutilisables, de rendu gouverne et de frontieres de responsabilite claires que comme un editeur de pages libre.
Le modele technique central
FaceFlow est compose d'un petit ensemble de types d'objets aux responsabilites distinctes :
- Variables pour de petits fragments reutilisables
- Components pour des contrats de sections reutilisables
- Layouts pour des coquilles de pages partagees
- Pages pour des experiences assemblees
- Lists pour un rendu dynamique pilote par des collections
- Forms pour des workflows de soumission structures
- Reviews pour du contenu de confiance modere
Chaque objet existe pour resoudre un niveau different du systeme web. Quand ces frontieres restent claires, FaceFlow reste maintenable a grande echelle.
Comment penser FaceFlow
Le modele mental le plus propre est :
Variables -> petits fragments reutilisables
Components -> sections reutilisables
Layouts -> coquilles de pages
Pages -> experiences assemblees
Lists -> archives et collections dynamiques
Forms -> workflows de leads et de demandes
Reviews -> workflows de confiance et de preuveCe n'est pas seulement une hierarchie de contenu. C'est une hierarchie architecturale.
Frontieres des objets
Utilisez ce modele de decision :
- utilisez une Variable quand l'unite de reutilisation est petite et parametree
- utilisez un Component quand l'unite de reutilisation est une section complete avec un schema expose aux auteurs
- utilisez un Layout quand le sujet concerne le cadre de page autour de nombreuses Pages
- utilisez une Page quand vous assemblez une route ou une experience finale
- utilisez une List quand la selection de contenu et la pagination font partie du contrat
- utilisez un Form pour collecter des soumissions structurees
- utilisez une Review pour collecter et publier des retours publics gouvernes
La plupart des derives techniques dans FaceFlow apparaissent lorsqu'un objet commence a prendre la responsabilite d'un autre.
Exemple de systeme
Layout:
default-site-shell
Page:
/enterprise/
Components:
hero-banner
benefits-grid
demo-request-section
review-strip
Systemes embarques:
<div data-form-embed="enterprise-demo-request"></div>
<div data-review-embed="customer-success-reviews"></div>
Variables:
[[site-announcement]]
[[sales-contact-badge]]Cet exemple reste maintenable parce que chaque sujet a une place claire.
Scope et impact des changements
Le scope est l'un des concepts techniques les plus importants dans FaceFlow.
Il controle si une section reutilisable se comporte comme :
- un actif global au niveau du site
- un actif partage au niveau d'une famille de layouts
- un actif local a une page
Quand les utilisateurs techniques choisissent le mauvais scope, l'impact des changements devient difficile a predire. Une section locale peut devenir par erreur une dependance globale, ou un contenu repete peut rester duplique bien apres qu'il aurait du etre mutualise.
Couche de template
Les templates FaceFlow sont ecrits avec Facet.
Cela signifie que les utilisateurs techniques doivent comprendre :
- la sortie des champs
- les conditions
- les boucles
- les filtres
- l'inclusion de Variables
- la composition sure de sections
Exemple :
<section class="hero">
<h1>{{ title }}</h1>
{{#if summary}}
<p>{{ summary }}</p>
{{/if}}
[[sales-contact-badge]]
</section>Facet est la couche de template. FaceFlow est le systeme d'objets structure autour.
Sur quoi les utilisateurs techniques doivent se concentrer
Quand vous concevez avec FaceFlow, les decisions techniques les plus importantes sont en general :
- ou la reutilisation doit vivre
- combien de schema une section doit exposer
- si quelque chose doit etre dynamique ou statique
- quel est le veritable rayon d'impact d'un actif partage
- quelle part de la page appartient au Layout, au Component ou a la composition de Page
Ces decisions ont plus d'impact sur la maintenabilite que n'importe quel contenu de page pris isolement.
Erreurs techniques frequentes
Evitez ces modeles :
- utiliser des Components la ou des Variables seraient plus claires
- utiliser des Variables la ou un vrai schema de section est necessaire
- pousser du contenu specifique a une page dans le Layout
- creer un Component surdimensionne qui tente de couvrir de nombreux cas sans lien
- traiter les Lists comme un refuge pour une architecture de contenu mal definie
- embarquer des workflows metier sans revoir le chemin complet de rendu et de moderation
Ordre de lecture recommande
Ce parcours part des plus petites unites reutilisables vers l'assemblage complet du site, puis vers la couche de template.