.png%3Falt%3Dmedia%26token%3Db44692e5-25a4-4ca0-b9e0-75a83780c05d)
.png%3Falt%3Dmedia%26token%3Db44692e5-25a4-4ca0-b9e0-75a83780c05d)
Comment on page
Logic
Once you've defined a feature flag in your schema, you can add targeting rules to define when the flag should be on.
You build these rules in Hyperlang, our visual, functional, statically-typed configuration language.
Since Hyperlang is a full programming language, you can insert arbitrarily complex rules.
When building rules, you can reference targeting attributes that you defined on the input types in your schema, e.g.
context.user.id, context.environment or context.organization.plan.This lets you create user segments, e.g. a list of beta user IDs, that you can reuse across the logic of different flags.
So you can have a single feature flag with rules to enable the feature for specific users, e.g. employees, QA, beta users, etc, and a final default rule to A/B test the feature on everyone else.
It also means you can reuse a single A/B test across the logic of different feature flags to roll out and test related features in sync.
This lets you:
- See drop-off rates between different event types
- Compare conversion rates across different arms of an A/B test or machine learning loop
- Set goals for machine learning loops
Live counts are overlaid on your flag targeting logic so you can see how often different targeting rules are evaluated and passed in realtime.
You can add a comment to any Hyperlang expression, e.g. to explain a feature flag, a specific targeting rule, a list of IDs or a specific ID.
You can set permissions on any Hyperlang expression.
This lets you safely empower nontechnical teammates to update specific parts of your flag logic. For example, you could let product managers edit a list of user IDs for a specific flag targeting rule, but not the structure of the rule, or the other rules on the flag.
The Hyperlang logic builder interface is "type-directed". This means it only lets you insert expressions that satisfy the required type of the hole in the logic tree. So for a
Boolean feature flag defined in your schema, you can insert a primitive Boolean expression or an If / Else expression that returns a Boolean. If you insert an If / Else expression, more holes appear.This results in an intuitive interface such that nontechnical users don't need to know any syntax and can't get into invalid states.
Hyperlang is statically-typed and your logic is type-checked against your schema. Since the logic builder interface is type-directed, you typically won't encounter any type errors.
However, if you make a breaking change to your schema, e.g. by removing or renaming a flag, you'll see a type error that you'll need to fix.
Since your schema and logic are saved and deployed together in a single commit, you won't be able to save your changes if there are any type errors that need fixing.
Last modified 1mo ago