Send context from your code

When to send your own context

Every flag check runs against an eval context: the identity and attributes a flag rule evaluates against. Bridge already supplies some of that data for free. If the account is signed in, user.role and tenant.plan are already in every evaluation with zero code on your part (see Target by plan or role).

Send your own context when the thing you want to target on is something only your app knows: a business fact that lives in your own data, not in Bridge. For example: “only show the new dashboard to users with more than 3 projects.” Bridge has no idea how many projects a user has, so you tell it:

const dashboard = useFlag('new_dashboard', false, {
  attributes: { project_count: projects.length },
});

With project_count flowing in, an admin can add a rule in Control Center (your admin dashboard at app.thebridge.dev) such as project_count greater than 3 without you touching this code again. That’s the pattern: send whatever app-specific fact the targeting decision depends on, once, and every future rule change is a Control Center edit, not a redeploy.

There are two ways to send it, depending on how widely it applies.

Per-call context

The optional third argument supplies identity/attributes for one call site. Use this for a value that’s only meaningful to that particular flag check, like cart_size on a checkout flag. Per-call attributes win over everything else on key collision:

const checkout = useFlag('new_checkout', false, {
  attributes: { cart_size: cart.items.length },
});

<FeatureFlag> takes the same context as a context prop instead of a third argument; see Show or hide UI for the component form.

Framework note: In React, both forms take plain values: the hook and the component re-evaluate on every render, so the context stays current with no getter function needed.

App-wide attributes (bridge.attributes)

Use this instead when a value should be available to every flag evaluation across your app, not just one call site, so you don’t have to remember to pass it into every useFlag call that might eventually want it. A good example is something set once at sign-in or app start, like membership in a beta group, that several unrelated flags might target on over time:

import { bridge } from '@nebulr-group/bridge-nextjs/client';

bridge.attributes.set('beta_cohort', true);                    // static value
bridge.attributes.bind('cart_size', () => cart.items.length); // re-read on every eval
bridge.attributes.bindMany(() => ({ theme, locale }));         // bulk getter

Precedence on key collision: per-call context > bridge.attributes > Bridge-managed providers. The bridge: namespace is reserved; writes to it are rejected with a console warning. See the Live Updates guide for the full bridge.attributes API.