Design Studio Local

O que é o Design Studio Local?

O Design Studio Local é um ambiente de desenvolvimento integrado ao Storefront Local que permite ao desenvolvedor criar, testar e validar blocos e schemas do Design Studio diretamente na máquina, antes de publicar qualquer alteração no ambiente de produção.

Com ele, é possível:

• Validar se os schemas dos blocos estão corretos;
• Validar se os templates HTML dos blocos compilam sem erros de Scriban;
• Visualizar blocos com conteúdo mockado (sem precisar cadastrar nada no CMS de produção);
• Importar o layout que está publicado atualmente na loja;
• Acompanhar o status de todos os arquivos em tempo real via LiveReload.

Como acessar

Com o projeto rodando localmente, acesse:

http://localhost:5501/design-studio/dashboard

O painel exibirá um resumo do estado atual do projeto com contadores de Templates, Schemas, Blocks e Layouts Locais.

LiveReload ativo — alterações nas pastas Blocks/ e Layouts/ recarregam automaticamente o painel.

Design Studio Dashboard

O painel é dividido em três seções principais:

1. Templates

Lista os templates do projeto (ex.: Pages/home.html) e exibe:

• Os tipos de bloco associados a cada template (ex.: banner_principal, vitrine_1, newsletter);
• Se existe um Layout Local salvo para aquele template;
• Ações disponíveis: Preview, Gerar Layout e Importar Publicado.

2. Validação de Schemas

Exibe o status de validação de cada arquivo *.schema.json encontrado na pasta Blocks/.

Exemplo de erro de schema:

{
  "success": false,
  "type": "marquee_banner",
  "file": "Blocks/marquee_banner.schema.json",
  "errors": [
    "Setting 'speed': field 'type' is required."
  ]
}

Exemplo de schema válido:

{
  "success": true,
  "type": "marquee_banner",
  "file": "Blocks/marquee_banner.schema.json"
}

3. Validação de Blocks

Exibe o status de validação dos arquivos *.html de cada bloco na pasta Blocks/, verificando se o template Scriban compila corretamente.

Exemplo de erro de bloco:

{
  "success": false,
  "type": "banner_carousel",
  "file": "Blocks/banner_carousel.html",
  "errors": [
    {
      "message": "Error while parsing if statement: The <end> statement was not found in: if <expression> ... end|else|else if",
      "line": 20,
      "column": 74
    }
  ]
}

Exemplo de bloco válido:

{
  "success": true,
  "type": "banner_carousel",
  "file": "Blocks/banner_carousel.html"
}

Layout exclusivo por URL no ambiente local

O Design Studio de produção resolve o layout por URL: uma URL pode ter um
layout exclusivo, desvinculado do template. O ambiente local não reproduz esse
comportamento.

No modo local, o layout é lido de um único arquivo por template:

Layouts/<nome-do-template>.json

Ou seja, ao navegar localmente por /calca, /camiseta ou /blazer — todas
atendidas pelo mesmo template — você verá sempre o mesmo layout, que é o
conteúdo desse arquivo. A URL acessada não altera qual arquivo de layout é
carregado.

Isso vale também para as ações do dashboard:

Como simular um layout exclusivo localmente

Para conferir como uma URL específica vai ficar quando estiver desvinculada do
template, edite temporariamente o Layouts/<template>.json com o conteúdo que
você espera daquela URL e use o Preview. Como o LiveReload observa a pasta
Layouts/, a alteração aparece imediatamente.

Lembre-se de restaurar o arquivo depois: ele representa o layout do template, e
é ele que o Importar Publicado sobrescreve.

Regra prática: use o ambiente local para validar blocos, schemas e o
layout de template. A validação de layouts exclusivos por URL — e do
comportamento de desvincular/revincular — precisa ser feita no Design Studio
do Admin, em um ambiente com o CMS de verdade.

Audiências no ambiente local

Blocos com variação por audiência (varyByAudience: true no schema) funcionam no ambiente local, mas a audiência do visitante não é resolvida contra o Wake Experience: quem escolhe é o desenvolvedor.

Simulando audiências

Há duas formas, e a query string tem prioridade sobre o cookie:

Ao usar a query string, o valor também é gravado no cookie sf_segments_local para as navegações seguintes. Chamar /cms/segments sem audiências na query remove o cookie — é assim que se volta à versão padrão.

A query string manda de propósito: sem essa regra, um cookie esquecido de um teste anterior explicaria sozinho por que a página "não muda".

O que o local não reproduz

• Não há catálogo nem projeção. Qualquer identificador informado é aceito como válido. No ambiente real, uma audiência ausente do catálogo da loja é descartada e o cliente cai na versão padrão.
• Não há login nem consulta por e-mail. Em produção a audiência só é resolvida para cliente autenticado; no local basta a query string.
• Não há criptografia do cookie, nem a validade de 60 minutos como bound de defasagem que existe em produção.
• Não há validação de limite comercial. O teto de audiências por bloco e o gate do add-on são aplicados no salvamento pelo Design Studio do Admin.

Regra prática: use o local para conferir se o bloco renderiza corretamente cada variação. Comportamento de identificação do cliente, precedência entre audiências reais, cache e limites precisam ser validados no Design Studio do Admin, em uma loja com o add-on ativo.

Fluxo recomendado de desenvolvimento

1. Crie o arquivo Blocks/meu_bloco.schema.json com as configurações do bloco.
2. Crie o arquivo Blocks/meu_bloco.html com o template Scriban do bloco.
3. Acesse o Dashboard (/design-studio/dashboard) e verifique se ambos aparecem com status OK.
4. Use Gerar Layout no template desejado para visualizar o bloco com conteúdo mockado.
5. Acesse o Preview para ver o resultado renderizado no browser.
6. Se o bloco declara varyByAudience: true, repita o Preview com ?audiences=<identificador> para conferir cada variação, e sem o parâmetro para conferir a versão padrão.
7. Quando satisfeito, faça o deploy normalmente e use Importar Publicado para confirmar que o layout de produção está correto.

Dica: Se algum bloco existente já está publicado e você quer usá-lo como referência, use Importar Publicado antes de começar as alterações.