Sistema de Escopo

O sistema de escopo controla onde seções reutilizáveis do FaceFlow ficam visíveis e são compartilhadas.

Para usuários técnicos, escopo é uma das regras arquiteturais centrais no FaceFlow. Ele decide se uma seção reutilizável se comporta como um ativo global, um ativo de família de páginas ou um ativo local apenas da página.

Três níveis de escopo

• Site: compartilhado por todo o site
• Layout: compartilhado entre Páginas que usam o mesmo Layout
• Página: local a uma única Página

Modelo mental técnico

Pense no escopo como um contrato de visibilidade e impacto de mudança anexado a uma instância de seção reutilizável.

Conceitualmente:

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

O campo importante não é o formato exato de armazenamento. A regra importante é que o escopo determina com que amplitude essa instância deve ser reutilizada e quão amplamente uma edição posterior irá se propagar.

Por que o escopo importa

O escopo evita que o reuso se torne caos.

Sem regras de escopo, equipes ou:

• duplicam o mesmo bloco em todos os lugares
• compartilham demais um bloco que deveria ter permanecido local
• perdem o controle de quais mudanças afetam quais Páginas

O escopo torna essas fronteiras explícitas.

Modelo mental

Site scope
  -> affects all relevant Pages across the site

Layout scope
  -> affects Pages that share one Layout

Page scope
  -> affects only one Page

Isto não é uma preferência de conteúdo. É uma regra de impacto de mudança.

Mapeamento de instâncias — exemplo

Uma montagem simplificada de Página pode parecer com isto:

Layout: docs-shell

Site scope:
  announcement-strip

Layout scope:
  docs-sidebar
  docs-subnav

Page scope:
  release-notes-cta
  migration-faq

Esse único diagrama explica dois fatos técnicos importantes:

• nem toda seção reutilizável é compartilhada da mesma forma
• a revisão de mudanças deve levar o escopo em conta antes de aprovar a edição

Exemplos de escopo

Escopo do Site

Use quando uma seção deve se comportar como um ativo de todo o site.

Exemplos:

• barra de anúncio global
• faixa de suporte à navegação compartilhada
• banner de confiança usado em todo o site

Escopo de Layout

Use quando uma seção pertence a uma família de páginas.

Exemplos:

• barra lateral de documentação usada apenas em páginas de documentação
• subnavegação compartilhada para uma seção de serviço
• trilho de suporte em toda a seção para uma família de Layouts

Escopo de Página

Use quando a seção é única para uma Página.

Exemplos:

• um hero de campanha pontual
• uma faixa de CTA local
• FAQ específico da página ou bloco de prova

Exemplo de raio de mudança

O mesmo tipo de seção pode ser válido em diferentes escopos dependendo da intenção:

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

É por isso que o escopo deve ser escolhido pelo raio de impacto pretendido, não pela conveniência do editor.

Regra de decisão

Faça uma pergunta:

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

Se a resposta for:

• "todas as Páginas relevantes" -> Site
• "Páginas desta família" -> Layout
• "apenas esta Página" -> Página

Composição — exemplo

Site scope:
  global-announcement

Layout scope:
  docs-sidebar

Page scope:
  pricing-faq

Esse modelo mantém o reuso intencional e torna o impacto da mudança previsível.

Orientação arquitetural

Use o escopo para responder a estas perguntas técnicas:

• onde essa instância deve ser descobrível?
• quantas Páginas devem herdar edições futuras?
• quem deve ser o dono da mudança?
• qual nível de revisão é justificado antes da publicação?

Na prática:

• o escopo Site normalmente precisa da revisão mais rigorosa porque o impacto é amplo
• o escopo Layout precisa de consciência da família de páginas
• o escopo Página é o lugar mais seguro para experimentação local

Impacto técnico

O escopo afeta:

• onde uma seção reutilizável está disponível
• quantas Páginas uma mudança pode afetar
• como as equipes raciocinam sobre propriedade
• como a estrutura compartilhada é mantida ao longo do tempo

É por isso que decisões de escopo devem ser tratadas como decisões arquiteturais, não escolhas de conveniência do editor.

Padrão de revisão

Quando uma equipe propõe alargar o escopo, revise como uma mudança arquitetural:

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?

Se a resposta for "não realmente", o escopo provavelmente está sendo alargado cedo demais.

Lista de verificação para revisão técnica

• o escopo escolhido corresponde ao raio de mudança pretendido?
• a seção é realmente reutilizável nesse nível?
• um editor futuro entenderia por que a seção é compartilhada?
• a seção está carregando conteúdo que deveria ter permanecido local?
• uma seção supostamente local está sendo copiada em muitas Páginas?

Anti-padrões

Evite:

• escopo Site para conteúdo que só uma família de páginas precisa
• escopo Página para conteúdo copiado em muitas Páginas
• escopo Layout para conteúdo que pertence ao shell global do site
• alargar o escopo apenas para economizar esforço a curto prazo

Regra de exemplo em prática

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

Regra de design relacionada

O escopo deve ser revisado junto com a responsabilidade do objeto:

• se a mudança afeta o shell, revise o Layout
• se a mudança afeta um contrato de seção reutilizável, revise o Componente
• se a mudança afeta apenas uma experiência montada, revise a Página

Relacionados

• Componentes
• Layouts
• Páginas