Testar o Custom Code GoodBarber com um membro ligado

Escrito por Mathieu Poli na Sexta-Feira 26 Junho 2026

Precisa que o seu Custom Code do GoodBarber se comporte de forma diferente para um utilizador autenticado — mostrar conteúdo premium, saudar um membro pelo nome, esconder uma secção dos visitantes anónimos? Quer tenha escrito esse código por si próprio ou o tenha gerado com o AI Extension Builder, ele pergunta à App API quem está ligado através de gb.user.getCurrent(). Mas a pré-visualização do back-office não tem login real, por isso, em apps com Membership, essa chamada cai sempre no caminho de erro. Este guia explica como o utilizador atual se comporta na pré-visualização para cada tipo de app e dá-lhe uma forma de copiar e colar para testar como um membro autenticado.

Muito Custom Code precisa de saber quem está a usar a app neste momento: mostrar conteúdo premium, saudar membros pelo nome, esconder uma secção dos visitantes anónimos, adaptar um checkout. A App API do GoodBarber dá-lhe acesso ao utilizador atual através de gb.user.getCurrent().

E o Custom Code já não é apenas algo que se escreve à mão. Com o AI Extension Builder do GoodBarber, descreve em linguagem natural a secção que pretende e o assistente gera a extensão por si — código que se liga diretamente à mesma App API do GoodBarber. Escrito à mão ou gerado por IA, ele chama gb.user.getCurrent() da mesma forma, e você testa-o da mesma forma. Por isso, este guia aplica-se tanto se escreveu o código como se o pediu por prompt.

Mas eis o obstáculo com que todo o programador acaba por se deparar: dentro da pré-visualização do back-office, não existe nenhum utilizador autenticado. A pré-visualização é apenas uma renderização da sua app — não há ecrã de login, não há sessão, não há nada contra o qual autenticar.

Para a maioria dos tipos de app, o GoodBarber contorna isto discretamente por si, de modo que testar "como um utilizador autenticado" simplesmente funciona. Para a extensão Membership, não funciona — e isso é intencional. Este artigo percorre como o utilizador atual se comporta na pré-visualização para cada tipo de app e dá-lhe uma forma simples, de copiar e colar, de testar o caso mais complicado: um membro autenticado.

Uma revisão rápida: gb.user.getCurrent()

A App API do GoodBarber permite ao seu Custom Code perguntar "quem está a usar a app neste momento?" através de um único método:

gb.user.getCurrent(
    (user) => {
        // Há um utilizador autenticado.// `user` é um objeto GBUser — leia os seus atributos aqui.
        console.log(user.email);
    },
    (error) => {
        // Não há nenhum utilizador autenticado.
        console.log(`Response status: ${error.code}`);
        console.log(`Response message: ${error.message}`);
    }
);

Recebe dois callbacks: um callback de sucesso (chamado com um objeto GBUser quando alguém está autenticado) e um callback de erro (chamado quando ninguém está autenticado). É baseado em callbacks — não devolve um valor nem uma Promise.

O objeto GBUser muda de forma consoante o tipo de app

O modelo GBUser carrega uma propriedade api_version que indica que tipo de app o produziu:

`api_version`	Tipo de app
`1`	App de conteúdo + extensão Authentication
`2`	App eCommerce
`3`	App de conteúdo + extensão Membership

A lista de atributos depende dessa versão. Para uma app Membership (api_version: 3), um GBUser tem este aspeto:

{
    id: 123,
    api_version: 3,
    login: "member@example.com",
    email: "member@example.com",
    username: "John Doe",
    firstname: "John",
    lastname: "Doe",
    picture_url: "https://example.com/picture.jpg",
    access_levels: ["premium"]   // 👈 o campo-chave para Membership
}

O array access_levels é o que torna o Membership especial: lista os níveis de acesso que o utilizador detém no momento. É quase sempre com base nisto que o seu Custom Code se ramifica ("este utilizador tem premium? então mostra o conteúdo bónus").

Na prática, o seu código lê access_levels para decidir o que mostrar:

gb.user.getCurrent(
    (user) => {
        if (user.access_levels.includes("premium")) {
            console.log("O membro tem premium — mostrar o conteúdo premium");
        } else {
            console.log("Autenticado, mas sem premium — mostrar a sugestão de upgrade");
        }
    },
    (error) => {
        console.log("Ninguém autenticado — mostrar o prompt de login");
    }
);

Tenha isto em mente — é exatamente este código que o mock abaixo vai alimentar.

Como o utilizador atual se comporta na pré-visualização

A pré-visualização no back-office é um sandbox. Renderiza a sua app, mas não tem mecanismo de login — não há forma de autenticar realmente um utilizador real dentro dela.

Para que o desenvolvimento continue a ser confortável mesmo assim, o GoodBarber injeta um utilizador fictício para alguns tipos de app, de modo que getCurrent() devolva algo com que possa trabalhar:

Tipo de app	Na pré-visualização, `getCurrent()`…
Add-on Authentication (`api_version: 1`)	✅ Devolve automaticamente um utilizador fictício — o seu callback de sucesso é executado.
App eCommerce (`api_version: 2`)	✅ Devolve automaticamente um cliente fictício — o seu callback de sucesso é executado.
Extensão Membership (`api_version: 3`)	❌ Não devolve nada — o seu callback de erro é executado com `"There's no user logged in the app."`

Assim, se a sua app usar Authentication ou eCommerce, pode testar a sua lógica de utilizador autenticado na pré-visualização de imediato — é-lhe entregue um utilizador fictício gratuitamente, sem qualquer configuração.

Se a sua app usar a extensão Membership, é diferente: não é injetado nenhum utilizador fictício. Se o seu callback de sucesso nunca é executado na pré-visualização e cai sempre no caminho de erro, isso é o esperado — simplesmente não há utilizador atual para devolver e, ao contrário dos outros dois tipos de app, nenhum é simulado por si.

O resto deste artigo foca-se nesse caso do Membership, porque é o que precisa de algum trabalho. Tem duas formas de o resolver.

Opção 1 — Testar na app MyGoodBarber (condições reais)

A forma mais fiel de testar é executar a sua app dentro da app MyGoodBarber (disponível em iOS e Android). Ela carrega a sua app real, com o fluxo de login real e o backend real. Você autentica-se como um membro verdadeiro e getCurrent() devolve o seu GBUser real com os seus access_levels reais.

Use isto quando quiser validar o fluxo completo de ponta a ponta antes de publicar. É o mais próximo possível da produção.

A desvantagem: é um ciclo de feedback mais lento. Não consegue iterar sobre um ajuste de CSS ou sobre uma ramificação condicional tão depressa como na pré-visualização. É aí que entra a Opção 2.

Opção 2 — Simular (mock) getCurrent() na pré-visualização

Para iterar rapidamente, pode substituir temporariamentegb.user.getCurrent por uma versão sua que devolve um membro fictício à sua escolha. A sua lógica real permanece exatamente igual — o seu Custom Code continua a chamar gb.user.getCurrent(success, error) como sempre. Está apenas a trocar o que o método faz enquanto testa.

Passo 1 — Inserir o mock no topo do seu código

Adicione este bloco mesmo no início do JavaScript do seu Custom Code, antes de qualquer chamada a getCurrent():

// ⚠️ APENAS PARA TESTE NA PRÉ-VISUALIZAÇÃO — remova (ou defina como false) antes de publicar!const PREVIEW_TESTING = true;

if (PREVIEW_TESTING && typeof gb !== "undefined" && gb.user) {
    gb.user.getCurrent = function (successCallback, errorCallback) {
        const fakeUser = {
            id: "123",
            api_version: 3,
            login: "member@example.com",
            email: "member@example.com",
            username: "Test Member",
            firstname: "Test",
            lastname: "Member",
            picture_url: "",
            access_levels: ["premium"]   // 👈 altere isto para testar casos diferentes
        };
        successCallback(fakeUser);
    };
}

💡 "premium" é apenas um exemplo. Use os identificadores de níveis de acesso reais configurados na sua app — caso contrário, as suas condições não vão corresponder a nada.

Pode perguntar-se: o meu código não consegue detetar a pré-visualização e simular apenas aí? Infelizmente, não — não existe nenhum sinal fiável exposto ao seu Custom Code que diga "isto é a pré-visualização" (gb.platform() devolve "web" na pré-visualização, exatamente como uma PWA real em produção) e, só a partir de getCurrent, a pré-visualização é indistinguível de um utilizador genuinamente desconectado (ambos caem no callback de erro). É por isso que usamos uma flag que se alterna à mão: é explícita e não pode ser acionada por acidente em produção.

E é tudo. A partir de agora, em qualquer ponto do seu Custom Code onde chame:

gb.user.getCurrent(onUserFound, onNoUser);

…o seu callback onUserFound recebe o membro fictício acima — exatamente como se um membro premium real estivesse autenticado. Não altera nada da sua lógica de negócio; apenas acrescentou o bloco de mock por cima.

Passo 2 — Testar os casos que importam

Todo o objetivo do código de Membership é reagir a utilizadores diferentes. Basta editar o mock para cobrir cada cenário:

Um membro subscrito (com níveis de acesso):

access_levels: ["premium"]

Um utilizador autenticado sem subscrição:

access_levels: []

Vários níveis de acesso ao mesmo tempo:

access_levels: ["free", "premium", "vip"]

Ninguém autenticado — aqui simula o caminho de erro em vez do de sucesso:

gb.user.getCurrent = function (successCallback, errorCallback) {
    errorCallback({ code: 1, message: "There's no user logged in the app." });
};

Alterne entre estes casos para garantir que o seu Custom Code se comporta corretamente em todos os estados — e não apenas no caminho feliz.

Passo 3 (opcional) — Simular também gb.membership.getAccessLevels()

Algum código de Membership lê os níveis de acesso através do método dedicado do Membership em vez de o fazer pelo objeto do utilizador:

gb.membership.getAccessLevels(
    (access_levels) => { console.log(access_levels); },
    (error) => { console.log(error.message); }
);

Se o usar, simule-o da mesma forma:

if (PREVIEW_TESTING && typeof gb !== "undefined" && gb.membership) {
    gb.membership.getAccessLevels = function (successCallback, errorCallback) {
        successCallback(["premium"]);
    };
}

⚠️ Antes de publicar: desligue o mock

Esta é a única regra que não pode saltar. O mock é uma muleta de desenvolvimento — nunca pode chegar à produção. Se o publicar, todos os utilizadores da app serão tratados como o seu membro premium fictício, independentemente daquilo que realmente pagaram.

Dois hábitos seguros:

Mantenha tudo por trás da única flag PREVIEW_TESTING e defina-a como false antes de publicar.
Melhor ainda, elimine completamente o bloco de mock assim que terminar de testar.

Quando PREVIEW_TESTING é false (ou o bloco desaparece), gb.user.getCurrent volta à implementação real do GoodBarber e o seu Custom Code passa a funcionar com membros realmente autenticados.

Pronto para experimentar? Abra a secção Custom Code no seu back-office do GoodBarber, cole o bloco de mock no topo do seu JavaScript e defina os access_levels para o caso que quer testar. Quando tudo se comportar como esperado, mude PREVIEW_TESTING para false (ou elimine o bloco) e publique. Para a referência completa, consulte a documentação da App API.

E se preferir não escrever a extensão à mão, é aí que entra o AI Extension Builder: descreva em linguagem natural a secção que pretende e ele gera a extensão, liga-a às próprias APIs do GoodBarber e renderiza-a ao vivo na sua app. Assenta na mesma App API — por isso a técnica acima está logo à mão sempre que quiser pré-visualizar como a sua extensão se comporta para um membro autenticado.

Leitura adicional

gb.user.getCurrent — obter o utilizador autenticado atual.
GBUser — o modelo do utilizador e como os seus atributos mudam consoante o api_version.
gb.membership.getAccessLevels — ler os níveis de acesso diretamente (disponível apenas com o add-on Memberships).
GoodBarber para programadores: mais liberdade e ferramentas para utilizadores avançados — o que pode construir para além do editor no-code.

Recapitulação

Na pré-visualização do back-office, não há login real.
Para apps Authentication e eCommerce, o GoodBarber injeta automaticamente um utilizador fictício, por isso testar como um utilizador autenticado simplesmente funciona.
Para a extensão Membership, não é fornecido nenhum utilizador fictício — getCurrent() cai no callback de erro.
Para testar rapidamente na pré-visualização, substitua temporariamente gb.user.getCurrent (e gb.membership.getAccessLevels, se o usar) para devolver um membro fictício com os access_levels que quer testar.
Para uma verificação real, de ponta a ponta, execute a sua app dentro da app MyGoodBarber.
Remova sempre o mock antes de publicar.

FAQ

Porque é que gb.user.getCurrent() devolve um erro na pré-visualização para a minha app Membership?

Porque a pré-visualização do back-office não tem mecanismo de login e, para apps Membership (api_version: 3), o GoodBarber não injeta um utilizador fictício. Sem ninguém autenticado, o método chama o seu callback de erro com "There's no user logged in the app." — é o comportamento esperado, não um bug.

Porque é que o mesmo código funciona na pré-visualização para uma app Authentication ou eCommerce?

Para apps Authentication (api_version: 1) e eCommerce (api_version: 2), o GoodBarber injeta automaticamente um utilizador fictício (ou cliente fictício) na pré-visualização, por isso o seu callback de sucesso é executado sem qualquer configuração.

Como testo um membro autenticado sem publicar a minha app?

Pode executar a sua app dentro da app MyGoodBarber (iOS/Android) para testar em condições reais, ou substituir temporariamente gb.user.getCurrent no seu Custom Code para devolver um membro fictício com os access_levels que quer testar.

O que é access_levels no objeto GBUser?

É um array dos níveis de acesso que um utilizador Membership detém no momento (por exemplo ["premium"]). O seu Custom Code normalmente ramifica-se com base nele para decidir que conteúdo mostrar. Um array vazio ([]) significa um utilizador autenticado sem subscrição ativa.

gb.user.getCurrent() devolve uma Promise?

Não. É baseado em callbacks: passa um callback de sucesso e um callback de erro. Não devolve um valor, por isso não pode usar await.

O que acontece se eu me esquecer de remover o mock antes de publicar?

Todos os utilizadores da sua app serão tratados como o membro fictício que codificou diretamente — todos receberiam, por exemplo, acesso premium independentemente do que realmente pagaram. Defina sempre PREVIEW_TESTING como false ou elimine o bloco de mock antes de publicar.

#Como Fazer