ScaleBun
Book a Demo
Skip to article

Debug

react-nativeDeveloperv0.1.0-alpha.4

The ScaleBun.debug namespace — 4 members.

Updated Reviewed

Debug utilities namespace. All methods are no-op if debug is not enabled.

TypeScript
import ScaleBun from '@scalebun/react-native';
ScaleBun.debug.<method>(…);

Members#

MemberSignature
addBreadcrumbaddBreadcrumb(message: string, data?: Record<string, unknown>)
pingping()
isEnabledisEnabled()
sendMetricsendMetric(name: string, value: number, unit?: string, tags?: Record<string, string>)

Reference#

addBreadcrumb#

TypeScript
ScaleBun.debug.addBreadcrumb(message: string, data?: Record<string, unknown>)

ping#

TypeScript
ScaleBun.debug.ping()

isEnabled#

TypeScript
ScaleBun.debug.isEnabled()

sendMetric#

TypeScript
ScaleBun.debug.sendMetric(name: string, value: number, unit?: string, tags?: Record<string, string>)

Notes#

Four members, and they serve two different purposes that are worth separating.

ping() and isEnabled() are integration checks. ping() exercises the transport end to end; isEnabled() reports whether debug mode is currently on. Together they answer "is anything I do reaching the server?", which is the first question of every failed integration.

addBreadcrumb() and sendMetric() are production instrumentation. Despite living under debug, breadcrumbs are one of the most valuable things you can add — they are the trail attached to a crash report, and they are what turns "it threw here" into "here is what the user did first".

Breadcrumbs are for crash investigation, not analytics#

A breadcrumb is a short note in a ring buffer, attached to whatever error or crash happens next. It is not an event: nothing aggregates it, and you cannot query it.

Use them where a failure is plausible and context is scarce — before a network call, on a screen transition, around a state machine change. Ten well-placed breadcrumbs make a crash report readable.

Ordering#

  1. ping() first on a new integration

    Before you debug your own instrumentation, confirm the transport works. It separates "my code is wrong" from "nothing is reaching the server", which are very different afternoons.

  2. Enable debug mode only in development

    Debug mode is verbose by design. Ship it enabled and you pay for the noise in bandwidth and in usage.

  3. Add breadcrumbs where the next failure will need them

    Not everywhere. The buffer is bounded, so a breadcrumb on every render pushes out the ones that mattered.

Limits and edge cases#

  • Breadcrumbs only surface alongside an error or crash. Nothing appears if nothing fails.

  • The buffer is bounded and oldest-first. High-frequency breadcrumbs evict the useful ones.

  • sendMetric is not the analytics event pipeline. For product analytics use events.

  • ping() succeeding proves transport, not correctness. Your events can still be malformed — check SDK Health.

  • These calls do not throw and are silent in release builds.

Related#