Probar tu Custom Code de GoodBarber con un usuario conectado

Escrito por Mathieu Poli el Viernes 26 Junio 2026

¿Necesitas que tu Custom Code de GoodBarber se comporte de forma distinta cuando hay un usuario conectado —mostrar contenido premium, saludar a un miembro por su nombre, ocultar una sección a los visitantes anónimos? Tanto si escribiste ese código tú mismo como si lo generaste con el AI Extension Builder, le pregunta a la App API quién está conectado a través de gb.user.getCurrent(). Pero la vista previa del back-office no tiene un login real, así que en las apps con Membership esa llamada siempre cae en la rama de error. Esta guía explica cómo se comporta el usuario actual en la vista previa para cada tipo de app, y te ofrece una forma lista para copiar y pegar de probar como un miembro conectado.

Mucho código de Custom Code necesita saber quién está usando la app en este momento: mostrar contenido premium, saludar a los miembros por su nombre, ocultar una sección a los visitantes anónimos, adaptar un proceso de compra. La App API de GoodBarber te da el usuario actual a través de gb.user.getCurrent().

Y el Custom Code ya no es solo algo que escribes a mano. Con el AI Extension Builder de GoodBarber, describes en lenguaje natural la sección que quieres y el asistente genera la extensión por ti: un código que se conecta directamente a la misma App API de GoodBarber. Escrito a mano o generado por IA, llama a gb.user.getCurrent() de la misma forma, y lo pruebas de la misma forma. Así que esta guía vale tanto si escribiste el código como si lo pediste con un prompt.

Pero aquí está el detalle con el que todo desarrollador acaba topando: dentro de la vista previa del back-office no hay ningún usuario conectado. La vista previa no es más que una representación de tu app: no hay pantalla de inicio de sesión, no hay sesión, no hay nada contra lo que autenticarse.

Para la mayoría de los tipos de app, GoodBarber resuelve esto de forma transparente, de modo que probar "como un usuario conectado" simplemente funciona. Con la extensión Membership no es así, y es algo intencionado. Este artículo repasa cómo se comporta el usuario actual en la vista previa para cada tipo de app, y te ofrece una forma sencilla, lista para copiar y pegar, de probar el caso más delicado: un miembro conectado.

Un repaso rápido: gb.user.getCurrent()

La App API de GoodBarber permite que tu Custom Code pregunte "¿quién está usando la app en este momento?" a través de un único método:

gb.user.getCurrent(
    (user) => {
        // Hay un usuario conectado.// `user` es un objeto GBUser: aquí puedes leer sus atributos.
        console.log(user.email);
    },
    (error) => {
        // No hay ningún usuario conectado.
        console.log(`Response status: ${error.code}`);
        console.log(`Response message: ${error.message}`);
    }
);

Recibe dos callbacks: un callback de éxito (que se invoca con un objeto GBUser cuando alguien está conectado) y un callback de error (que se invoca cuando no hay nadie conectado). Está basado en callbacks: no devuelve un valor ni una Promise.

El objeto GBUser cambia de forma según el tipo de app

El modelo GBUser lleva una propiedad api_version que indica qué tipo de app lo ha generado:

`api_version`	Tipo de app
`1`	App de contenido + extensión Authentication
`2`	App eCommerce
`3`	App de contenido + extensión Membership

La lista de atributos depende de esa versión. Para una app con Membership (api_version: 3), un GBUser tiene este aspecto:

{
    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"]   // 👈 el campo clave para Membership
}

El array access_levels es lo que hace especial a Membership: enumera los niveles de acceso que el usuario tiene actualmente. Casi siempre es ahí donde tu Custom Code toma decisiones ("¿este usuario tiene premium? entonces muestra el contenido extra").

En la práctica, tu código lee access_levels para decidir qué mostrar:

gb.user.getCurrent(
    (user) => {
        if (user.access_levels.includes("premium")) {
            console.log("El miembro tiene premium — mostrar el contenido premium");
        } else {
            console.log("Conectado, pero sin premium — mostrar la invitación a mejorar");
        }
    },
    (error) => {
        console.log("Nadie conectado — mostrar la invitación a iniciar sesión");
    }
);

Tenlo presente: es exactamente este código el que alimentará el mock que veremos más abajo.

Cómo se comporta el usuario actual en la vista previa

La vista previa del back-office es un entorno aislado. Representa tu app, pero no tiene ningún mecanismo de login: no hay forma de autenticar a un usuario real dentro de ella.

Para que el desarrollo siga siendo cómodo de todos modos, GoodBarber inyecta un usuario falso en algunos tipos de app, de manera que getCurrent() devuelva algo con lo que puedas trabajar:

Tipo de app	En la vista previa, `getCurrent()`…
Complemento Authentication (`api_version: 1`)	✅ Devuelve un usuario falso automáticamente: se invoca tu callback de éxito.
App eCommerce (`api_version: 2`)	✅ Devuelve un cliente falso automáticamente: se invoca tu callback de éxito.
Extensión Membership (`api_version: 3`)	❌ No devuelve nada: se invoca tu callback de error con `"There's no user logged in the app."`

Así que si tu app usa Authentication o eCommerce, puedes probar tu lógica de usuario conectado en la vista previa de inmediato: se te entrega un usuario falso gratis, sin necesidad de configurar nada.

Si tu app usa la extensión Membership, la cosa cambia: no se inyecta ningún usuario falso. Si tu callback de éxito nunca se invoca en la vista previa y siempre acabas en la rama de error, es lo esperado: sencillamente no hay un usuario actual que devolver y, a diferencia de los otros dos tipos de app, aquí no se simula ninguno por ti.

El resto de este artículo se centra en ese caso de Membership, porque es el que requiere algo de trabajo. Tienes dos formas de abordarlo.

Opción 1 — Probar en la app MyGoodBarber (condiciones reales)

La forma más fiel de probar es ejecutar tu app dentro de la app MyGoodBarber (disponible en iOS y Android). Carga tu app real, con el flujo de login real y el backend real. Inicias sesión como un miembro de verdad y getCurrent() devuelve tu GBUser real con tus access_levels reales.

Usa esta opción cuando quieras validar el flujo completo de principio a fin antes de publicar. Es lo más parecido a producción.

El inconveniente: el ciclo de feedback es más lento. No puedes iterar sobre un ajuste de CSS o sobre una rama condicional tan rápido como en la vista previa. Ahí es donde entra la Opción 2.

Opción 2 — Simular getCurrent() en la vista previa

Para iterar rápido, puedes reemplazar temporalmentegb.user.getCurrent por tu propia versión que devuelva un miembro falso a tu elección. Tu lógica real se mantiene exactamente igual: tu Custom Code sigue llamando a gb.user.getCurrent(success, error) como siempre. Solo cambias lo que hace el método mientras pruebas.

Paso 1 — Coloca el mock al principio de tu código

Añade este bloque al inicio absoluto del JavaScript de tu Custom Code, antes de cualquier llamada a getCurrent():

// ⚠️ SOLO PARA PRUEBAS EN LA VISTA PREVIA — ¡elimínalo (o ponlo en 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"]   // 👈 cambia esto para probar diferentes casos
        };
        successCallback(fakeUser);
    };
}

💡 "premium" es solo un ejemplo. Usa los identificadores de nivel de acceso reales configurados en tu app; de lo contrario, tus condiciones no coincidirán con nada.

Quizá te preguntes: ¿no puede mi código detectar la vista previa y simular solo ahí? Por desgracia, no: no existe ninguna señal fiable expuesta a tu Custom Code que diga "esto es la vista previa" (gb.platform() devuelve "web" en la vista previa, exactamente igual que una PWA real en producción) y, partiendo solo de getCurrent, la vista previa es indistinguible de un usuario que de verdad ha cerrado sesión (ambos caen en el callback de error). Por eso usamos un flag que activas a mano: es explícito y no puede dispararse por accidente en producción.

Eso es todo. A partir de ahora, en cualquier parte de tu Custom Code donde llames a:

gb.user.getCurrent(onUserFound, onNoUser);

…tu callback onUserFound recibirá el miembro falso de arriba, exactamente como si hubiera un miembro premium real conectado. No cambias en absoluto tu lógica de negocio; solo has añadido el bloque del mock por encima.

Paso 2 — Prueba los casos que importan

Todo el sentido del código de Membership es reaccionar ante usuarios distintos. Basta con editar el mock para cubrir cada escenario:

Un miembro suscrito (con niveles de acceso):

access_levels: ["premium"]

Un usuario conectado sin suscripción:

access_levels: []

Varios niveles de acceso a la vez:

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

Nadie conectado en absoluto: aquí simulas la rama de error en lugar de la de éxito:

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

Alterna entre estos casos para asegurarte de que tu Custom Code se comporta correctamente en todos los estados, no solo en el camino feliz.

Paso 3 (opcional) — Simula también gb.membership.getAccessLevels()

Parte del código de Membership lee los niveles de acceso a través del método dedicado de Membership en lugar de hacerlo desde el objeto de usuario:

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

Si lo usas, simúlalo de la misma forma:

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

⚠️ Antes de publicar: desactiva el mock

Esta es la única regla que no puedes saltarte. El mock es una muleta de desarrollo: nunca debe llegar a producción. Si lo publicas, todos los usuarios de la app serán tratados como tu miembro premium falso, sin importar lo que realmente hayan pagado.

Dos buenos hábitos:

Mantén todo detrás del único flag PREVIEW_TESTING y ponlo en false antes de publicar.
Mejor aún: elimina por completo el bloque del mock una vez que hayas terminado de probar.

Cuando PREVIEW_TESTING está en false (o el bloque ha desaparecido), gb.user.getCurrent vuelve a la implementación real de GoodBarber, y tu Custom Code trabaja contra miembros conectados de verdad.

¿Listo para probarlo? Abre la sección Custom Code en tu back-office de GoodBarber, pega el bloque del mock al principio de tu JavaScript y define los access_levels para el caso que quieras probar. Cuando todo funcione como esperas, pon PREVIEW_TESTING en false (o elimina el bloque) y publica. Para la referencia completa, consulta la documentación de la App API.

Y si prefieres no escribir la extensión a mano, ahí es justo donde entra el AI Extension Builder: describe en lenguaje natural la sección que quieres y él genera la extensión, la conecta a las propias APIs de GoodBarber y la muestra en vivo en tu app. Está construido sobre la misma App API, así que la técnica de arriba está ahí a tu disposición siempre que quieras previsualizar cómo se comporta tu extensión con un miembro conectado.

Lecturas adicionales

gb.user.getCurrent — recupera el usuario conectado actual.
GBUser — el modelo de usuario y cómo cambian sus atributos según el api_version.
gb.membership.getAccessLevels — lee los niveles de acceso directamente (disponible solo con el complemento Memberships).
GoodBarber para desarrolladores: más libertad y herramientas para power users — lo que puedes construir más allá del editor no-code.

Resumen

En la vista previa del back-office no hay un login real.
Para las apps con Authentication y eCommerce, GoodBarber inyecta un usuario falso automáticamente, de modo que probar como usuario conectado simplemente funciona.
Para la extensión Membership, no se proporciona ningún usuario falso: getCurrent() cae en el callback de error.
Para probar rápido en la vista previa, reemplaza temporalmente gb.user.getCurrent (y gb.membership.getAccessLevels si lo usas) para que devuelva un miembro falso con los access_levels que quieras probar.
Para una comprobación real, de principio a fin, ejecuta tu app dentro de la app MyGoodBarber.
Elimina siempre el mock antes de publicar.

Preguntas frecuentes

¿Por qué gb.user.getCurrent() devuelve un error en la vista previa para mi app con Membership?

Porque la vista previa del back-office no tiene ningún mecanismo de login y, para las apps con Membership (api_version: 3), GoodBarber no inyecta un usuario falso. Al no haber nadie conectado, el método invoca tu callback de error con "There's no user logged in the app." — es el comportamiento esperado, no un fallo.

¿Por qué el mismo código sí funciona en la vista previa para una app con Authentication o eCommerce?

Para las apps con Authentication (api_version: 1) y eCommerce (api_version: 2), GoodBarber inyecta automáticamente un usuario falso (o un cliente falso) en la vista previa, de modo que tu callback de éxito se invoca sin necesidad de configurar nada.

¿Cómo pruebo un miembro conectado sin publicar mi app?

O bien ejecutas tu app dentro de la app MyGoodBarber (iOS/Android) para probar en condiciones reales, o bien reemplazas temporalmente gb.user.getCurrent en tu Custom Code para que devuelva un miembro falso con los access_levels que quieras probar.

¿Qué es access_levels en el objeto GBUser?

Es un array con los niveles de acceso que un usuario de Membership tiene actualmente (por ejemplo ["premium"]). Tu Custom Code suele tomar decisiones a partir de él para decidir qué contenido mostrar. Un array vacío ([]) indica un usuario conectado sin ninguna suscripción activa.

¿gb.user.getCurrent() devuelve una Promise?

No. Está basado en callbacks: le pasas un callback de éxito y un callback de error. No devuelve ningún valor, así que no puedes usar await con él.

¿Qué pasa si me olvido de quitar el mock antes de publicar?

Todos los usuarios de tu app serán tratados como el miembro falso que has dejado fijado en el código: todos obtendrían, por ejemplo, acceso premium sin importar lo que realmente hayan pagado. Pon siempre PREVIEW_TESTING en false o elimina el bloque del mock antes de publicar.