Testare il Custom Code GoodBarber con un utente connesso

Scritto da Mathieu Poli il Venerdì 26 Giugno 2026

Serve far comportare il proprio Custom Code di GoodBarber in modo diverso per un utente connesso — mostrare contenuti premium, salutare un membro per nome, nascondere una sezione ai visitatori anonimi? Che tu abbia scritto quel codice di tuo pugno o lo abbia generato con l'AI Extension Builder, esso chiede all'App API chi è connesso tramite gb.user.getCurrent(). Ma l'anteprima del back-office non ha un login reale, quindi per le app Membership quella chiamata finisce sempre nel percorso di errore. Questa guida spiega come si comporta l'utente corrente nell'anteprima per ogni tipo di app e offre un metodo copia-incolla per testare l'app come membro connesso.

Molto Custom Code ha bisogno di sapere chi sta usando l'app in questo momento: mostrare contenuti premium, salutare i membri per nome, nascondere una sezione ai visitatori anonimi, adattare un checkout. L'App API di GoodBarber fornisce l'utente corrente tramite gb.user.getCurrent().

E il Custom Code non è più soltanto qualcosa che si scrive a mano. Con l'AI Extension Builder di GoodBarber, descrivi in linguaggio naturale la sezione che desideri e l'assistente genera l'estensione al posto tuo — codice che si aggancia direttamente alla stessa App API di GoodBarber. Scritto a mano o generato dall'AI, chiama gb.user.getCurrent() allo stesso modo, e lo testi allo stesso modo. Quindi questa guida vale sia che tu abbia digitato il codice, sia che lo abbia richiesto con un prompt.

C'è però un dettaglio in cui ogni sviluppatore prima o poi si imbatte: dentro l'anteprima del back-office non c'è alcun utente connesso. L'anteprima è soltanto un rendering dell'app — non c'è una schermata di login, né una sessione, né nulla con cui autenticarsi.

Per la maggior parte dei tipi di app, GoodBarber risolve la cosa in modo trasparente, così testare "come utente connesso" funziona senza problemi. Per l'estensione Membership non è così — ed è voluto. Questo articolo illustra come si comporta l'utente corrente nell'anteprima per ciascun tipo di app e fornisce un modo semplice, copia-incolla, per testare il caso più ostico: un membro connesso.

Un breve ripasso: gb.user.getCurrent()

L'App API di GoodBarber permette al proprio Custom Code di chiedere "chi sta usando l'app in questo momento?" tramite un unico metodo:

gb.user.getCurrent(
    (user) => {
        // Un utente è connesso.// `user` è un oggetto GBUser — qui se ne leggono gli attributi.
        console.log(user.email);
    },
    (error) => {
        // Nessun utente è connesso.
        console.log(`Response status: ${error.code}`);
        console.log(`Response message: ${error.message}`);
    }
);

Accetta due callback: una di successo (richiamata con un oggetto GBUser quando qualcuno è connesso) e una di errore (richiamata quando non c'è nessun utente connesso). È basato su callback — non restituisce un valore né una Promise.

L'oggetto GBUser cambia forma a seconda del tipo di app

Il modello GBUser porta con sé una proprietà api_version che indica quale tipo di app lo ha prodotto:

`api_version`	Tipo di app
`1`	App Content + estensione Authentication
`2`	App eCommerce
`3`	App Content + estensione Membership

L'elenco degli attributi dipende da quella versione. Per un'app Membership (api_version: 3), un GBUser si presenta così:

{
    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"]   // 👈 il campo chiave per Membership
}

L'array access_levels è ciò che rende speciale Membership: elenca i livelli di accesso di cui l'utente dispone in quel momento. È quasi sempre il valore su cui il proprio Custom Code prende decisioni ("questo utente ha premium? allora mostra il contenuto bonus").

In pratica, il codice legge access_levels per decidere cosa mostrare:

gb.user.getCurrent(
    (user) => {
        if (user.access_levels.includes("premium")) {
            console.log("Il membro ha premium — mostra il contenuto premium");
        } else {
            console.log("Connesso, ma senza premium — mostra l'invito all'upgrade");
        }
    },
    (error) => {
        console.log("Nessun utente connesso — mostra l'invito al login");
    }
);

Vale la pena tenerlo a mente — è esattamente questo il codice che il mock qui sotto andrà ad alimentare.

Come si comporta l'utente corrente nell'anteprima

L'anteprima nel back-office è una sandbox. Esegue il rendering dell'app, ma non ha alcun meccanismo di login — al suo interno non c'è modo di autenticare davvero un utente reale.

Per rendere comunque comodo lo sviluppo, GoodBarber inietta un utente fittizio per alcuni tipi di app, in modo che getCurrent() restituisca qualcosa su cui lavorare:

Tipo di app	Nell'anteprima, `getCurrent()`…
Add-on Authentication (`api_version: 1`)	✅ Restituisce automaticamente un utente fittizio — la callback di successo viene richiamata.
App eCommerce (`api_version: 2`)	✅ Restituisce automaticamente un cliente fittizio — la callback di successo viene richiamata.
Estensione Membership (`api_version: 3`)	❌ Non restituisce nulla — viene richiamata la callback di errore con `"There's no user logged in the app."`

Quindi se l'app usa Authentication o eCommerce, è possibile testare subito la logica per utente connesso nell'anteprima — un utente fittizio viene fornito gratuitamente, senza alcuna configurazione.

Se invece l'app usa l'estensione Membership, le cose cambiano: non viene iniettato alcun utente fittizio. Se la callback di successo non viene mai richiamata nell'anteprima e si finisce sempre nel percorso di errore, è il comportamento previsto — semplicemente non c'è un utente corrente da restituire e, a differenza degli altri due tipi di app, nessuno viene simulato al posto vostro.

Il resto dell'articolo si concentra proprio sul caso Membership, perché è quello che richiede un po' di lavoro. Ci sono due modi per affrontarlo.

Opzione 1 — Testare nell'app MyGoodBarber (condizioni reali)

Il modo più fedele per testare è eseguire l'app dentro l'app MyGoodBarber (disponibile su iOS e Android). Carica l'app reale, con il vero flusso di login e il vero backend. Ci si connette come membro effettivo e getCurrent() restituisce il GBUser reale con i veri access_levels.

Da usare quando si vuole validare l'intero flusso end-to-end prima della pubblicazione. È la cosa più vicina alla produzione.

Lo svantaggio: il ciclo di feedback è più lento. Non si può iterare su una modifica CSS o su un ramo condizionale alla stessa velocità dell'anteprima. È qui che entra in gioco l'Opzione 2.

Opzione 2 — Simulare getCurrent() nell'anteprima

Per iterare rapidamente, si può sostituire temporaneamentegb.user.getCurrent con una versione propria che restituisce un membro fittizio a scelta. La logica reale resta identica — il proprio Custom Code continua a chiamare gb.user.getCurrent(success, error) come al solito. Si cambia soltanto ciò che fa il metodo durante i test.

Passaggio 1 — Inserire il mock all'inizio del codice

Aggiungere questo blocco proprio all'inizio del JavaScript del proprio Custom Code, prima di qualsiasi chiamata a getCurrent():

// ⚠️ SOLO PER TEST IN ANTEPRIMA — rimuovere (o impostare a false) prima di pubblicare!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"]   // 👈 modificare per testare casi diversi
        };
        successCallback(fakeUser);
    };
}

💡 "premium" è solo un esempio. Usare gli identificatori dei livelli di accesso realmente configurati nella propria app — altrimenti le condizioni non corrisponderanno a nulla.

Ci si potrebbe chiedere: il mio codice non potrebbe semplicemente rilevare l'anteprima e attivare il mock solo lì? Purtroppo no — non esiste alcun segnale affidabile esposto al Custom Code che dica "questa è l'anteprima" (gb.platform() restituisce "web" nell'anteprima, esattamente come una vera PWA in produzione) e, basandosi solo su getCurrent, l'anteprima è indistinguibile da un utente realmente disconnesso (entrambi finiscono nella callback di errore). Per questo si usa un flag da impostare a mano: è esplicito e non può attivarsi per sbaglio in produzione.

Tutto qui. D'ora in poi, ovunque nel proprio Custom Code si chiami:

gb.user.getCurrent(onUserFound, onNoUser);

…la callback onUserFound riceverà il membro fittizio qui sopra — esattamente come se fosse connesso un vero membro premium. Non si cambia in alcun modo la logica di business; si aggiunge soltanto il blocco mock in cima.

Passaggio 2 — Testare i casi che contano

Tutto il senso del codice Membership è reagire a utenti diversi. Basta modificare il mock per coprire ogni scenario:

Un membro con abbonamento (ha livelli di accesso):

access_levels: ["premium"]

Un utente connesso senza abbonamento:

access_levels: []

Più livelli di accesso contemporaneamente:

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

Nessun utente connesso — qui si simula il percorso di errore anziché quello di successo:

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

Alternando questi casi ci si assicura che il proprio Custom Code si comporti correttamente in ogni stato — non solo nel percorso ideale.

Passaggio 3 (opzionale) — Simulare anche gb.membership.getAccessLevels()

Una parte del codice Membership legge i livelli di accesso tramite il metodo dedicato di Membership anziché dall'oggetto utente:

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

Se lo si usa, va simulato allo stesso modo:

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

⚠️ Prima di pubblicare: disattivare il mock

Questa è l'unica regola che non si può saltare. Il mock è una stampella per lo sviluppo — non deve mai arrivare in produzione. Se lo si pubblica, ogni utente dell'app verrà trattato come il membro fittizio premium, indipendentemente da ciò che ha effettivamente pagato.

Due abitudini sicure:

Tenere tutto dietro l'unico flag PREVIEW_TESTING e impostarlo a false prima di pubblicare.
Meglio ancora, eliminare del tutto il blocco mock una volta finiti i test.

Quando PREVIEW_TESTING è false (o il blocco è stato rimosso), gb.user.getCurrent torna a usare l'implementazione reale di GoodBarber e il proprio Custom Code lavora con i membri effettivamente connessi.

Pronti a provarci? Aprire la sezione Custom Code nel proprio back-office GoodBarber, incollare il blocco mock all'inizio del JavaScript e impostare gli access_levels per il caso che si vuole testare. Quando tutto funziona, impostare PREVIEW_TESTING a false (o eliminare il blocco) e pubblicare. Per il riferimento completo, consultare la documentazione dell'App API.

E se preferisci non scrivere l'estensione a mano, è proprio qui che entra in gioco l'AI Extension Builder: descrivi in linguaggio naturale la sezione che desideri e l'assistente genera l'estensione, la aggancia alle API native di GoodBarber e la mostra dal vivo nella tua app. È costruito sulla stessa App API — così la tecnica vista sopra è sempre a portata di mano, ogni volta che vuoi vedere in anteprima come si comporta la tua estensione per un membro connesso.

Approfondimenti

gb.user.getCurrent — recupera l'utente attualmente connesso.
GBUser — il modello utente e come cambiano i suoi attributi per ogni api_version.
gb.membership.getAccessLevels — legge direttamente i livelli di accesso (disponibile solo con l'add-on Memberships).
GoodBarber per gli sviluppatori: più libertà e strumenti per power user — cosa puoi costruire oltre l'editor no-code.

Riepilogo

Nell'anteprima del back-office non esiste un login reale.
Per le app Authentication ed eCommerce, GoodBarber inietta automaticamente un utente fittizio, quindi testare come utente connesso funziona senza problemi.
Per l'estensione Membership, non viene fornito alcun utente fittizio — getCurrent() finisce nella callback di errore.
Per testare rapidamente nell'anteprima, sovrascrivere temporaneamente gb.user.getCurrent (e gb.membership.getAccessLevels se lo si usa) per restituire un membro fittizio con gli access_levels che si vogliono testare.
Per una verifica reale, end-to-end, eseguire l'app dentro l'app MyGoodBarber.
Rimuovere sempre il mock prima di pubblicare.

FAQ

Perché gb.user.getCurrent() restituisce un errore nell'anteprima per la mia app Membership?

Perché l'anteprima del back-office non ha un meccanismo di login e, per le app Membership (api_version: 3), GoodBarber non inietta un utente fittizio. Senza nessuno connesso, il metodo richiama la callback di errore con "There's no user logged in the app." — è un comportamento previsto, non un bug.

Perché lo stesso codice funziona nell'anteprima per un'app Authentication o eCommerce?

Per le app Authentication (api_version: 1) ed eCommerce (api_version: 2), GoodBarber inietta automaticamente un utente fittizio (o un cliente fittizio) nell'anteprima, quindi la callback di successo viene richiamata senza alcuna configurazione.

Come posso testare un membro connesso senza pubblicare l'app?

O si esegue l'app dentro l'app MyGoodBarber (iOS/Android) per testarla in condizioni reali, oppure si sovrascrive temporaneamente gb.user.getCurrent nel proprio Custom Code per restituire un membro fittizio con gli access_levels che si vogliono testare.

Cos'è access_levels nell'oggetto GBUser?

È un array dei livelli di accesso di cui un utente Membership dispone in quel momento (per esempio ["premium"]). Il proprio Custom Code di solito vi si basa per decidere quali contenuti mostrare. Un array vuoto ([]) indica un utente connesso senza alcun abbonamento attivo.

gb.user.getCurrent() restituisce una Promise?

No. È basato su callback: si passa una callback di successo e una di errore. Non restituisce un valore, quindi non si può usare await.

Cosa succede se dimentico di rimuovere il mock prima di pubblicare?

Ogni utente dell'app verrà trattato come il membro fittizio scritto a codice fisso — otterrebbero tutti, ad esempio, l'accesso premium indipendentemente da ciò che hanno effettivamente pagato. Impostare sempre PREVIEW_TESTING a false o eliminare il blocco mock prima di pubblicare.

#ComeFare