Scope-System

Das Scope-System steuert, wo wiederverwendbare FaceFlow-Abschnitte sichtbar und geteilt werden.

Für technische Nutzer ist Scope eine der Kern-Architekturregeln in FaceFlow. Es entscheidet, ob sich ein wiederverwendbarer Abschnitt wie ein globales Asset, ein Asset für eine Seitenfamilie oder ein nur lokal für eine Seite gültiges Asset verhält.

Drei Scope-Ebenen

• Site: über die gesamte Site geteilt
• Layout: über Pages geteilt, die dasselbe Layout verwenden
• Page: lokal für eine einzelne Page

Technisches Denkmodell

Betrachten Sie Scope als einen Vertrag über Sichtbarkeit und Änderungswirkung, der an eine Instanz eines wiederverwendbaren Abschnitts angehängt ist.

Konzeptionell:

{
  "component": "announcement-strip",
  "scope": "site"
}

Wichtig ist nicht die genaue Speicherform. Die wichtige Regel ist, dass Scope bestimmt, wie breit diese Instanz wiederverwendet werden sollte und wie weit eine spätere Bearbeitung sich auswirken wird.

Warum Scope wichtig ist

Scope verhindert, dass Wiederverwendung in Chaos ausartet.

Ohne Scope-Regeln duplizieren Teams entweder:

• denselben Block überall
• teilen einen Block zu stark, der lokal hätte bleiben sollen
• verlieren den Überblick darüber, welche Änderungen welche Pages betreffen

Scope macht diese Grenzen explizit.

Denkmodell

Site scope
  -> affects all relevant Pages across the site

Layout scope
  -> affects Pages that share one Layout

Page scope
  -> affects only one Page

Das ist keine Inhaltspräferenz. Es ist eine Regel zur Auswirkung von Änderungen.

Beispielhafte Instanzzuordnung

Eine vereinfachte Page-Zusammenstellung könnte so aussehen:

Layout: docs-shell

Site scope:
  announcement-strip

Layout scope:
  docs-sidebar
  docs-subnav

Page scope:
  release-notes-cta
  migration-faq

Dieses einzelne Diagramm erklärt zwei wichtige technische Fakten:

• nicht jeder wiederverwendbare Abschnitt wird gleichermaßen geteilt
• die Überprüfung von Änderungen muss Scope berücksichtigen, bevor die Bearbeitung genehmigt wird

Scope-Beispiele

Site scope

Verwenden, wenn ein Abschnitt als sites-weites Asset fungieren muss.

Beispiele:

• globale Ankündigungsleiste
• gemeinsam genutzter Navigations-Support-Strip
• Vertrauensbanner, das auf der gesamten Site verwendet wird

Layout scope

Verwenden, wenn ein Abschnitt zu einer Seitenfamilie gehört.

Beispiele:

• Docs-Sidebar, die nur auf Dokumentationsseiten verwendet wird
• geteilte Sub-Navigation für einen Service-Bereich
• layoutspezifische Support-Leiste für eine Layout-Familie

Page scope

Verwenden, wenn der Abschnitt einzigartig für eine einzelne Page ist.

Beispiele:

• eine einmalige Kampagnen-Hero
• ein lokaler CTA-Strip
• seiten-spezifisches FAQ- oder Proof-Block

Beispiel für den Änderungsradius

Der gleiche Abschnittstyp kann je nach Absicht auf unterschiedlichen Scopes gültig sein:

announcement-strip at Site scope
  -> change affects all relevant Pages

announcement-strip at Layout scope
  -> change affects one page family

announcement-strip at Page scope
  -> change affects only one Page

Deshalb sollte Scope nach dem beabsichtigten Ausbreitungsradius gewählt werden, nicht nach der Bequemlichkeit für Redakteure.

Entscheidungsregel

Stellen Sie eine Frage:

If I change this section, which Pages should change with it?

Wenn die Antwort ist:

• "all relevant Pages" -> Site
• "Pages in this one family" -> Layout
• "only this one Page" -> Page

Beispielzusammensetzung

Site scope:
  global-announcement

Layout scope:
  docs-sidebar

Page scope:
  pricing-faq

Dieses Modell hält Wiederverwendung bewusst und macht die Auswirkungen von Änderungen vorhersehbar.

Architekturleitlinien

Verwenden Sie Scope, um diese technischen Fragen zu beantworten:

• wo sollte diese Instanz auffindbar sein?
• wie viele Pages sollten zukünftige Änderungen erben?
• wer sollte die Änderung verantworten?
• welches Maß an Prüfung ist vor dem Veröffentlichen gerechtfertigt?

In der Praxis:

• Site-Scope benötigt üblicherweise die strengste Prüfung, da die Auswirkungen breit sind
• Layout-Scope erfordert Bewusstsein für die Seitenfamilie
• Page-Scope ist der sicherste Ort für lokale Experimente

Technische Auswirkungen

Scope beeinflusst:

• wo ein wiederverwendbarer Abschnitt verfügbar ist
• wie viele Pages eine Änderung beeinflussen kann
• wie Teams über Verantwortung nachdenken
• wie geteilte Strukturen im Laufe der Zeit gepflegt werden

Deshalb sollten Scope-Entscheidungen als Architekturentscheidungen behandelt werden, nicht als Bequemlichkeitswahl für Redakteure.

Prüfungsablauf

Wenn ein Team vorschlägt, den Scope zu erweitern, prüfen Sie es wie eine Architekturänderung:

page -> layout
  question: is this section now shared by a durable page family?

layout -> site
  question: does this section now belong to the broader site, not one section?

Wenn die Antwort "not really" ist, wird der Scope wahrscheinlich zu früh erweitert.

Technische Prüfliste

• entspricht der gewählte Scope dem beabsichtigten Änderungsradius?
• ist der Abschnitt auf dieser Ebene wirklich wiederverwendbar?
• würde ein zukünftiger Redakteur verstehen, warum der Abschnitt geteilt wird?
• enthält der Abschnitt Inhalte, die lokal hätten bleiben sollen?
• wird ein angeblich lokaler Abschnitt auf viele Pages kopiert?

Anti-Patterns

Vermeiden Sie:

• Site-Scope für Inhalte, die nur eine Seitenfamilie benötigt
• Page-Scope für Inhalte, die in viele Pages kopiert wurden
• Layout-Scope für Inhalte, die zur globalen Site-Shell gehören
• Scope-Erweiterung nur, um kurzfristig Aufwand zu sparen

Beispielregel in der Praxis

Main navigation utility bar -> Site scope
Developer docs sidebar -> Layout scope
Landing page final CTA -> Page scope

Verwandte Gestaltungsregel

Scope sollte zusammen mit der Objektverantwortung geprüft werden:

• wenn die Änderung die Shell betrifft, prüfen Sie das Layout
• wenn die Änderung einen wiederverwendbaren Abschnittsvertrag betrifft, prüfen Sie die Component
• wenn die Änderung nur eine zusammengesetzte Experience betrifft, prüfen Sie die Page

Verwandt

• Components
• Layouts
• Pages