FaceFlow Ontwikkelaarsoverzicht
FaceFlow Ontwikkelaarsoverzicht
FaceFlow is de gestructureerde no-code bouwkern binnen PageFace.
Vanuit technisch perspectief is het het beste te begrijpen als een systeem van herbruikbare objecten, gestuurde rendering en duidelijke eigenaarschapsgrenzen, in plaats van als een vrijvormige paginabewerker.
Het Kerntechnische Model
FaceFlow bestaat uit een kleine set objecttypen met elk duidelijke verantwoordelijkheden:
- Variabelen voor lichte herbruikbare fragmenten
- Componenten voor herbruikbare sectiecontracten
- Lay-outs voor gedeelde paginasjablonen
- Pagina's voor samengestelde ervaringen
- Lijsten voor dynamische collectiegestuurde output
- Formulieren voor gestructureerde inzendingsworkflows
- Beoordelingen voor gemodereerde inhoud die vertrouwen opbouwt
Elk object is bedoeld om een ander niveau van het websitesysteem te adresseren. Wanneer die grenzen duidelijk blijven, blijft FaceFlow op grote schaal onderhoudbaar.
Hoe je over FaceFlow moet denken
Het meest heldere mentale model is:
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 workflowsDit is niet slechts een content-hiërarchie. Het is een architecturale hiërarchie.
Objectgrenzen
Gebruik dit beslismodel:
- gebruik een Variabele wanneer de hergebruikseenheid klein en geparametriseerd is
- gebruik een Component wanneer de hergebruikseenheid een volledige sectie is met een voor de editor zichtbaar schema
- gebruik een Lay-out wanneer het om het paginaram rondom meerdere pagina's gaat
- gebruik een Pagina bij het samenstellen van een uiteindelijke route of ervaring
- gebruik een Lijst wanneer contentselectie en paginering deel uitmaken van het contract
- gebruik een Formulier bij het verzamelen van gestructureerde inzendingen
- gebruik een Beoordeling bij het verzamelen en publiceren van gereguleerde openbare feedback
De meeste technische afwijkingen in FaceFlow gebeuren wanneer het ene object verantwoordelijkheden van een ander begint over te nemen.
Voorbeeldsysteem
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]]Dat voorbeeld blijft onderhoudbaar omdat elk onderdeel een duidelijke plek heeft.
Reikwijdte en impact van veranderingen
Reikwijdte is een van de belangrijkste technische concepten in FaceFlow.
Het bepaalt of een herbruikbare sectie zich gedraagt als:
- een site-brede asset
- een lay-outfamilie-asset
- een pagina-lokale asset
Wanneer technische gebruikers de verkeerde reikwijdte kiezen, wordt de impact van wijzigingen moeilijk te voorspellen. Een lokale sectie kan per ongeluk een globale afhankelijkheid worden, of herhaalde paginainhoud kan lang gedupliceerd blijven nadat het gedeeld had moeten zijn.
Sjabloonlaag
FaceFlow-sjablonen worden opgesteld via Facet.
Dat betekent dat technische gebruikers moeten begrijpen:
- velduitvoer
- voorwaardelijke logica
- lussen
- filters
- insluiten van Variabelen
- veilige samenstelling van secties
Voorbeeld:
<section class="hero">
<h1>{{ title }}</h1>
{{#if summary}}
<p>{{ summary }}</p>
{{/if}}
[[sales-contact-badge]]
</section>Facet is de sjabloonlaag. FaceFlow is het gestructureerde objectensysteem daaromheen.
Waar technische gebruikers zich op moeten richten
Bij het ontwerpen met FaceFlow zijn de belangrijkste technische beslissingen meestal:
- waar hergebruik thuishoort
- hoeveel schema een sectie moet blootgeven
- of iets dynamisch of statisch moet zijn
- wat de werkelijke reikwijdte van wijzigingen van een gedeeld asset is
- hoeveel van de pagina in Lay-out versus Component versus Pagina-compositie hoort
Die beslissingen hebben meer impact op onderhoudbaarheid dan welk enkel stuk paginainhoud dan ook.
Veelvoorkomende technische fouten
Vermijd deze patronen:
- Componenten gebruiken waar Variabelen duidelijker zouden zijn
- Variabelen gebruiken waar een echt sectieschema nodig is
- paginaspecifieke inhoud in de Lay-out onderbrengen
- een oversized Component maken die veel niet-gerelateerde use-cases probeert op te lossen
- Lijsten behandelen als een noodoplossing voor onduidelijke contentarchitectuur
- bedrijfsworkflows inbedden zonder het volledige render- en moderatiepad te beoordelen
Aanbevolen leesvolgorde
Dat pad gaat van de kleinste herbruikbare eenheden naar volledige websiteassemblage en vervolgens naar de sjabloonlaag.