Panoramica per sviluppatori di FaceFlow
Panoramica per sviluppatori di FaceFlow
FaceFlow è il nucleo strutturato di costruzione no-code all'interno di PageFace.
Da una prospettiva tecnica, è meglio inteso come un sistema di oggetti riutilizzabili, rendering governato e confini di proprietà chiari piuttosto che come un editor di pagine a libera composizione.
Il modello tecnico centrale
FaceFlow è composto da un piccolo insieme di tipi di oggetto con responsabilità distinte:
- Variabili per frammenti riutilizzabili e leggeri
- Componenti per contratti di sezione riutilizzabili
- Layout per shell di pagina condivise
- Pagine per esperienze assemblate
- Liste per output dinamici guidati da collezioni
- Moduli per flussi di invio strutturati
- Recensioni per contenuti di fiducia moderati
Ogni oggetto esiste per risolvere un diverso livello del sistema del sito web. Quando questi confini restano chiari, FaceFlow rimane manutenibile su larga scala.
Come pensare a FaceFlow
Il modello mentale più chiaro è:
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 workflowsQuesto non è solo una gerarchia di contenuti. È una gerarchia architetturale.
Confini degli oggetti
Usa questo modello decisionale:
- usa una Variabile quando l'unità riutilizzabile è piccola e parametrizzata
- usa un Componente quando l'unità riutilizzabile è una sezione completa con uno schema orientato all'editor
- usa un Layout quando la preoccupazione è il frame della pagina attorno a molte Pagine
- usa una Pagina quando si assembla una route o esperienza finale
- usa una Lista quando la selezione dei contenuti e la paginazione fanno parte del contratto
- usa un Modulo quando si raccolgono invii strutturati
- usa una Recensione quando si raccolgono e pubblicano feedback pubblici governati
La maggior parte della deriva tecnica in FaceFlow accade quando un oggetto inizia ad assumersi la responsabilità di un altro.
Esempio di 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]]Quell'esempio rimane manutenibile perché ogni preoccupazione ha una casa chiara.
Ambito e impatto delle modifiche
L'ambito è uno dei concetti tecnici più importanti in FaceFlow.
Controlla se una sezione riutilizzabile si comporta come:
- una risorsa a livello di sito
- una risorsa di una famiglia di Layout
- una risorsa locale alla pagina
Quando gli utenti tecnici scelgono l'ambito sbagliato, l'impatto delle modifiche diventa difficile da prevedere. Una sezione locale può diventare accidentalmente una dipendenza globale, oppure contenuti ripetuti di una pagina possono restare duplicati molto tempo dopo che avrebbero dovuto essere condivisi.
Livello dei template
I template di FaceFlow sono creati tramite Facet.
Questo significa che gli utenti tecnici dovrebbero comprendere:
- l'output dei campi
- le condizionali
- i loop
- i filtri
- l'incorporamento delle Variabili
- la composizione sicura delle sezioni
Esempio:
<section class="hero">
<h1>{{ title }}</h1>
{{#if summary}}
<p>{{ summary }}</p>
{{/if}}
[[sales-contact-badge]]
</section>Facet è il livello dei template. FaceFlow è il sistema strutturato di oggetti che lo circonda.
Su cosa dovrebbero concentrarsi gli utenti tecnici
Quando si progetta con FaceFlow, le decisioni tecniche più importanti di solito sono:
- dove deve stare il riuso
- quanta esposizione di schema dovrebbe avere una sezione
- se qualcosa dovrebbe essere dinamico o statico
- qual è il vero raggio d'azione di una risorsa condivisa
- quanto della pagina appartiene al Layout rispetto al Componente rispetto alla composizione della Pagina
Quelle decisioni hanno più impatto sulla manutenibilità di qualsiasi singolo pezzo di contenuto della pagina.
Errori tecnici comuni
Evita questi schemi:
- usare Componenti dove le Variabili sarebbero più chiare
- usare Variabili dove è necessario un vero schema di sezione
- spingere contenuti specifici della pagina nel Layout
- creare un singolo Componente sovradimensionato che tenta di risolvere molti casi d'uso non correlati
- trattare le Liste come fallback per un'architettura dei contenuti poco chiara
- incorporare flussi di lavoro di business senza rivedere l'intero percorso di rendering e moderazione
Ordine di lettura consigliato
Quel percorso si muove dalle unità riutilizzabili più piccole all'assemblaggio completo del sito e poi nel livello dei template.