Common Flag Patterns
Marketing site / pre-signup
Section titled “Marketing site / pre-signup”Flags work for visitors who have never logged in. The SDK persists an anonymous ID, so each visitor gets stable bucketing across sessions — variant A on Monday is variant A on Friday.
<script lang="ts"> import { useFlag } from '@nebulr-group/bridge-svelte/flags';
const hero = useFlag('landing_hero', 'classic'); // string variant</script>
{#if hero.value === 'product-led'} <ProductHero />{:else} <ClassicHero />{/if}For GDPR-conservative sites, choose the tracking mode at init: session (per-tab stickiness, nothing persisted across sessions) or none (in-memory only). See anonymous targeting.
A/B test
Section titled “A/B test”Use a string- or JSON-valued flag for the variant, with a percentage split in the rule. Because assignment is a deterministic hash of identity, the same visitor always lands in the same bucket — including across the login boundary if you call identify():
<script lang="ts"> import { useFlag } from '@nebulr-group/bridge-svelte/flags';
const cta = useFlag('checkout_cta', 'Submit'); // admin serves "Pay now" to 50%</script>
<button>{cta.value}</button>When a visitor signs up, identify(userId) links their anonymous history to the new account, so your experiment attribution stays continuous.
Measure with the built-in observability: per-flag value distribution shows the split is hitting target, and eval volume shows exposure.
Percentage rollout
Section titled “Percentage rollout”Roll a risky change out gradually — 10% → 50% → 100% — by adjusting one input on the rule. No redeploys; each step propagates live.
Frontend: works automatically — the SDK always has an identity (anonymous or known) to hash.
Backend: there’s no ambient identity, so you must pass one. Choose what “10%” should mean:
// 10% of usersthis.flags.flag('new_pipeline', false, { identity: req.user.id });
// 10% of tenants — every request for the same tenant behaves the samethis.flags.flag('new_pipeline', false, { identity: tenantId });If a rollout rule is active and you pass no identity, the SDK refuses the rollout and returns the safe default with a warning — it will not silently randomize per call. This is deliberate: random-per-call bucketing makes a “10% rollout” flicker per request.
Kill switch
Section titled “Kill switch”Every flag has a one-click kill: it overrides any rule and forces the flag to the safe value for everyone, immediately, over the live channel. In an incident you stop the bleeding first and untangle targeting later.
Declare defaults accordingly — the default value in code is your safe value, and it’s also what every client uses if Bridge is ever unreachable:
// default = the safe, boring pathconst useNewRanking = this.flags.flag('ranking_v2', false);Configuration flags
Section titled “Configuration flags”Number- and JSON-valued flags replace “deploy to change a constant”:
const maxUploads = this.flags.flag('max_uploads', 10);const rateLimit = this.flags.flag('rate_limit', { window: 60, max: 100 });Change the value in the admin; every instance picks it up live. Combine with a rule to give specific tenants raised limits — see Targeting.