--- title: "Probar tu Custom Code de GoodBarber con un usuario conectado" description: "¿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 s" canonical_url: "https://es.goodbarber.com/blog/probar-tu-custom-code-de-goodbarber-con-un-usuario-conectado-a1087/" lang: es date: 2026-06-26 last_updated: 2026-07-17 --- # Probar tu Custom Code de GoodBarber con un usuario conectado [Atrás](/blog/make-it-r8/) # Probar tu Custom Code de GoodBarber con un usuario conectado Escrito por [Mathieu Poli](https://es.goodbarber.com/blog/author/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. ![](https://cmsphoto.ww-cdn.com/superstatic/81328/art/grande/97133648-67674225.jpg?v=1782463729.1243932) 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](https://es.goodbarber.com/blog/ai-extension-builder-crea-secciones-con-ia-sin-programar-a1038/)** 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](https://es.goodbarber.com/blog/%C2%A1las-membresias-estan-aqui-a792/)** 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 temporalmente** `gb.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: 1. Mantén todo detrás del único flag `PREVIEW_TESTING` y ponlo en `false` antes de publicar. 2. 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](https://app.goodbarber.dev/v2/documentation/). 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`](https://app.goodbarber.dev/v2/documentation/#tag/user-methods/operation/gb.user.getCurrent) — recupera el usuario conectado actual. - [`GBUser`](https://app.goodbarber.dev/v2/documentation/#tag/user-models/operation/GBUser) — el modelo de usuario y cómo cambian sus atributos según el `api_version`. - [`gb.membership.getAccessLevels`](https://app.goodbarber.dev/v2/documentation/#tag/membership-methods/operation/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](https://es.goodbarber.com/blog/goodbarber-open-mas-libertad-para-desarrolladores-y-usuarios-expertos-a941/) — 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. ![Mathieu Poli](https://blog.goodbarber.com/_public/profile/65/6553d00ecdbe15f8aac2da7dddcff47648fdd791-default.jpg) Sobre el autor[Mathieu Poli](https://es.goodbarber.com/blog/author/mathieu-poli/)Head of Frontend Engineering Soy Head of Frontend Engineering en GoodBarber Superviso los equipos que diseñan los motores de renderizado en el corazón de nuestra plataforma no-code: son ellos los que dan vida a los proyectos de nuestros usuarios y los convierten en aplicaciones nativas, fluidas y cuidadas. Todo lo que se ve y se manipula en pantalla pasa por sus manos. Pionero del no-code móvil, apasionado de la arquitectura de software y del diseño de producto, también doy clases en universidades y escuelas privadas. Aquí escribo sobre ingeniería frontend, diseño de producto e IA — y sobre todo lo que ocurre cuando esos tres mundos se encuentran. [Leer más](https://es.goodbarber.com/blog/author/mathieu-poli/) [![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/hellomathieup)[![X](https://portal.ww-cdn.com/portal_static/svg/base2021/x.820492c586dd.svg)](https://x.com/hellomathieup/)