🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português
🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português

FaceFlow — Layout System

A layout is the structural frame that wraps every page. It defines where the header goes, where the footer goes, what global styles apply, and where page-specific content is placed. Think of it as the "shell" of your website — consistent across all pages that use it.

Documentation developpeur Layout

Les Layouts definissent le cadre de page partage utilise par les Pages FaceFlow.

Pour les utilisateurs techniques, un Layout est le contrat de coquille de page. Il determine ou vivent les regions partagees, ou le contenu de page est injecte et comment une famille de Pages garde un cadre coherent sans dupliquer la structure page par page.

Responsabilite centrale

Un Layout doit controler :

  • la structure globale du document
  • le placement du header, du footer et des regions partagees
  • le point d'insertion du contenu principal
  • les wrappers structurels et le cadrage d'une famille de pages
  • un style ou un comportement au niveau layout en option

Un Layout ne doit pas porter du contenu marketing specifique a une page.

Squelette de Layout

La plupart des Layouts peuvent se comprendre via un pattern simple :

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>{{ page.title }}</title>
</head>
<body>
  {header}
  {siteComponents}
  <main>
    {content}
  </main>
  {footer}
</body>
</html>

L'exigence cle est un point d'insertion {content} fiable. Sans lui, les Pages n'ont aucun endroit previsible ou se rendre.

Exemple de contrat de coquille

Un Layout peut aussi exposer des regions partagees supplementaires tout en gardant une frontiere de propriete propre :

<body class="resource-layout">
  {header}
  <div class="resource-shell">
    <aside class="resource-sidebar">
      {siteComponents}
    </aside>
    <main class="resource-main">
      {content}
    </main>
  </div>
  {footer}
</body>

La regle importante est que la coquille reste structurelle. La Page possede toujours la sequence rendue dans {content}.

Relation avec Pages et Components

Gardez le modele de propriete clair :

  • Layout possede la coquille
  • Page possede la composition de l'experience
  • Component possede les sections reutilisables dans l'experience

Quand les Layouts restent structurels, les familles de pages restent faciles a faire evoluer.

Regions partagees

Les Layouts sont le bon endroit pour des regions partagees comme :

  • une navigation persistante
  • un cadrage de footer standard
  • des sidebars de documentation
  • des rails de support utilises par toute une famille de pages

Exemple :

<body class="docs-layout">
  {header}
  <div class="docs-shell">
    <aside class="docs-sidebar">
      {siteComponents}
    </aside>
    <main class="docs-content">
      {content}
    </main>
  </div>
  {footer}
</body>

Il s'agit d'une reutilisation structurelle. Une banniere promotionnelle ponctuelle n'a pas sa place ici.

Familles de Layouts

Les familles de layouts courantes incluent :

  • la coquille principale du site marketing
  • la coquille de landing page de campagne
  • la coquille de ressources ou de documentation
  • la coquille de portail ou de base de connaissance

Chaque famille doit representer un pattern structurel durable, pas une variation de contenu temporaire.

Styling au niveau layout

Les Layouts peuvent definir des decisions de style partagees qui appartiennent a la coquille :

<body class="min-h-screen bg-slate-950 text-white">
  {header}
  <main class="mx-auto max-w-7xl px-6 py-16">
    {content}
  </main>
  {footer}
</body>

C'est approprie lorsque le style appartient au cadre de page. Le styling specifique a une section doit toujours vivre dans les Components.

Impact des changements

Les changements de Layout ont un fort impact car un Layout affecte souvent de nombreuses Pages.

Avant de modifier un Layout, revoyez :

  • quelle famille de pages en depend
  • si des regions partagees changent de sens
  • si les hypotheses de largeur de contenu, d'espacement ou de navigation changent
  • si les Components existants s'integrent toujours correctement dans la coquille

Pattern de revue de Layout

Lorsqu'un changement de Layout est propose, verifiez l'impact dans cet ordre :

semantique de coquille
-> regions partagees
-> largeur de contenu et espacements
-> compatibilite des components
-> comportement de la famille de pages dependante

Cela aide les equipes a eviter d'approuver un petit changement de coquille qui casse silencieusement plusieurs Pages dependantes.

Checklist de revue technique

  • le Layout expose-t-il un point d'insertion de contenu clair ?
  • ne porte-t-il que des sujets au niveau de la coquille ?
  • plusieurs Pages peuvent-elles le reutiliser sans exceptions ponctuelles ?
  • les regions partagees sont-elles vraiment partagees ?
  • changer ce Layout affecterait-il de nombreuses Pages de facon comprehensible ?

Anti-patterns

Evitez :

  • d'embarquer du copy specifique a une page directement dans le Layout
  • de creer des Layouts presque dupliques pour de petites variations
  • de faire remonter de la logique de section dans la coquille
  • d'utiliser le Layout comme un depotoir pour tout le contenu partage
  • de changer la semantique de la coquille sans verifier les Pages dependantes

Regle de decision exemple

Utilisez un Layout quand le changement affecte le cadre autour de nombreuses Pages :

nouvelle sidebar docs sur toute la section docs -> Layout
nouveau bloc CTA dans une section d'une page -> Component
nouveau contenu de preuve propre a une page -> composition de Page