Skip to content

docs(slider): how to open your own app page and route to it in Nuxt - #357

Merged
IgorShevchik merged 4 commits into
mainfrom
claude/356-slider-nuxt-docs
Aug 21, 2026
Merged

IgorShevchik merged 4 commits into
mainfrom
claude/356-slider-nuxt-docs

Conversation

@IgorShevchik

Copy link
Copy Markdown
Collaborator

Closes #356.

From a production incident: the SDK delivered the parameter correctly, the middleware recognised it, and the slider still showed the app's main page — with no error raised by anything. The cause was Nuxt, not the SDK. But the docs are where a developer looks first when a slider shows the wrong screen, and today they cannot tell you that the SDK's half of the job succeeded.

Slider page

What the portal does with each argument — three things that each sent someone down a wrong path:

  • the portal re-opens your own registered handler URL, not a portal path. openPath is the one for portal paths, and pointing it at an application page 404s — which reads as "sliders cannot host app pages" and is a frequent wrong turn;
  • everything in the argument object arrives as PLACEMENT_OPTIONS, so place is an ordinary call parameter and needs no placement.bind;
  • bx24_width below your own mobile breakpoint silently renders the mobile layout.

The Nuxt routing half, stated as a warning because the failure is silent:

A redirect returned from route middleware does not survive the first navigation when the entry route is prerendered. The portal opens the frame with a query string; for a prerendered page Nuxt hydrates on the bare path and then restores the original URL on app:suspense:resolve by assigning router.currentRoute.value directly — bypassing guards, and overwriting the redirect.

Worth stressing that this is not just nuxt generate: nuxt build prerenders anything in nitro.prerender.routes, and with crawlLinks anything reachable by a link. The report measured it served both by nginx and by Nitro — identical failure, so what serves the page is irrelevant.

Includes the onNuxtReady variant, the measured table of where a navigation can be issued from, and the two details that each cost the reporting team a round: compare paths tolerating a trailing slash (a static server serves /app/, the router resolves /app, and a strict !== cancels every redirect), and take the query from location.search rather than to.query.

A troubleshooting checklist for the symptom, since several unrelated causes produce it and none raises an error. Including the point that steps 2–3 reproduce with no portal involved — serve the built app and open /<page>?place=<place>.

Placement page

PLACEMENT_OPTIONS can arrive as a JSON string, with key case not guaranteed across entry points — so options?.place can be undefined with no error, which is the same symptom as the parameter never arriving.

And isSliderMode is derived from PLACEMENT_OPTIONS.IFRAME, so it must not be used to decide whether placement data arrived at all. The original team gated slider diagnostics on it, so the log line went quiet exactly when the data it was diagnosing was missing.

Skill

b24jssdk-frame-ui carries the same guidance plus three anti-patterns, so generated code gets the variant that survives a prerendered route rather than the one that fails silently on it.

The one deliberate debt

The middleware example is built from Nuxt auto-imports and two app-level helpers, none of which exist in the isolated context docs:typecheck-blocks compiles in. It carries @check-ignore with that reason — un-checkable rather than unfixed.

That took the marker count from 50 to 51, one over the warning threshold, so CHECK_IGNORE_WARN_THRESHOLD moves to 51 and records why. The comment on that constant asks for exactly this — raise it deliberately, don't let it creep silently.

Out of scope, raised in the issue rather than dropped

  • An SSG variant of the Nuxt example belongs to b24sdk-examples, a different repository.
  • Adding placement.option('place') — a parsing accessor that tolerates the JSON-string and key-case variance — is an API change, not documentation, and should be decided on its own. The docs now describe the hazard so an app can defend itself today.

Verification

docs-lint --strict 0/0, docs-typecheck-blocks 153 blocks 0 errors, docs-link-check 0 broken, md-internal-links 0 broken, lint:md clean over 21 files, check-v3-method-refs clean, skills:typecheck passes, docs-lint's own 48 script tests pass.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F22e2ft66y7nuBJjzdThBr


Generated by Claude Code

claude added 4 commits August 21, 2026 03:15
From a production incident (#356): the SDK delivered the parameter correctly,
the middleware recognised it, and the slider still showed the app's main page —
with no error raised anywhere. The cause was Nuxt, not the SDK, but the docs are
where a developer looks first when a slider shows the wrong screen, and they
could not tell you the SDK's half had succeeded.

Slider page:
- what the portal does with each argument — it re-opens your own registered
  handler URL (openPath is the one for portal paths, and pointing it at an app
  page 404s, which reads as 'sliders cannot host app pages'); the whole argument
  object arrives as PLACEMENT_OPTIONS, so  needs no placement.bind; and
  bx24_width below your mobile breakpoint silently renders the mobile layout
- the Nuxt routing half, with the failure stated as a warning: a redirect
  RETURNED from route middleware is discarded when the entry route is
  prerendered, because Nuxt hydrates on the bare path and then restores the
  original URL past the guards. Not limited to nuxt generate — nitro.prerender
  .routes and crawlLinks reach it too, and it is unaffected by what serves the
  files. Includes the onNuxtReady variant and the measured table of where a
  navigation can be issued from
- the two details that each cost the reporting team a round: compare paths
  tolerating a trailing slash, and take the query from location.search rather
  than to.query
- a troubleshooting checklist for one symptom with several unrelated causes,
  including that steps 2-3 reproduce with no portal involved

Placement page: PLACEMENT_OPTIONS can arrive as a JSON string with unguaranteed
key case, so options?.place can be undefined with no error; and isSliderMode is
derived from PLACEMENT_OPTIONS.IFRAME, so it must not be used to decide whether
placement data arrived — gating diagnostics on it silences them precisely when
the data is missing.

Skill b24jssdk-frame-ui carries the same guidance plus three anti-patterns, so
generated code gets the variant that survives a prerendered route.

Refs #356

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F22e2ft66y7nuBJjzdThBr
…tely

The example is Nuxt auto-imports (defineNuxtRouteMiddleware, navigateTo,
useNuxtApp, onNuxtReady) plus two app-level helpers. None of them exist in the
isolated context docs:typecheck-blocks compiles in, so the block is
un-checkable rather than unfixed — which is what @check-ignore is for.

That took the marker count from 50 to 51, one over the warning threshold, so
the threshold moves with it and records why. The comment on that constant asks
for exactly this: raise it deliberately, do not let it creep silently.

Refs #356
…credential log

Review panel, security lens, twice — refuted both times as not-worsened-here,
and taken anyway, because both are places where our own documentation
contradicts our own rules.

The middleware carries the whole query into the redirect target, APP_SID
included. That is correct and necessary — the target screen needs the portal's
parameters — but it puts a session identifier into a router history entry and
into route.fullPath, and a reader sending fullPath to an error reporter would
never learn that from the page. Now stated, with what to do about it.

Troubleshooting step 1 said "Log $b24.placement.options". That object can carry
the portal's query parameters, and this repo forbids exactly that: AGENTS.md's
no-secrets-in-logs rule, enforced in SDK source by local/no-credential-in-logger.
Advising in documentation what we reject in code is not a defensible split, so
the step now asks for key names and the one value being diagnosed.

Also aligns the skill's copy of the middleware with the page's: it had dropped
the navigation-failure check, which teaches silently losing a failed redirect —
the exact bug class the page exists to explain.

Refs #356
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs: opening your own app page in a slider — the Nuxt routing half is undocumented and silently fails on a prerendered route

2 participants