zeekay
10e6fec4c0
The rule table mapped HOG_ -> FN_ ahead of any POSTHOG rule, so POSTHOG_FOO split into POST + HOG_ and came out POSTFN_FOO. Nothing sets that. The live pods set INSIGHTS_SKIP_MIGRATION_CHECKS, which bin/migrate-check reads on the container entrypoint, so the misspelling does not degrade a feature -- it runs migrate --check against a database whose history this tree does not share and the container never starts. Both replacements are measured against the shipped tree rather than chosen: every HOG_ name with a counterpart there is spelled INSIGHTS_ (HOG_QL -> INSIGHTS_QL, HOG_FUNCTION_TEMPLATES -> INSIGHTS_FUNCTION_TEMPLATES, 12 of 12 determinate cases), and FN_ appears in it nowhere. Upstream carries 95 HOG_ tokens and zero FN_ ones, so repairing FN_ back out is exactly the inverse of the bad rule and cannot collide with an upstream name. The rule is fixed for the next convergence, and the tree it already produced is repaired in the same commit -- the codemod is idempotent against its own output, so it cannot undo this itself.
4.4 KiB
name, description
| name | description |
|---|---|
| setting-feature-flags-in-storybook | Use when writing a Storybook story for a component gated on a feature flag — boolean flags or multivariate/experiment-arm variants. Covers the `featureFlags` story parameter and why imperatively setting flags renders the flag-off branch in visual-regression snapshots while passing in jest. |
Setting feature flags in Storybook
Warning
Never call
featureFlagLogic.actions.setFeatureFlags(...)from a story. It silently no-ops in the visual-regression runtime (rendering the flag-OFF branch) while passing in jest — so unit tests stay green and the snapshot is wrong. Use thefeatureFlagsstory parameter instead.
Mental model: boolean flags always work (they ride the always-merged baseline);
variant values need a gate that only the featureFlags parameter opens correctly.
How to use it
This is the stable contract — prefer it over anything in "Under the hood" below.
Boolean flags (flag is simply on)
const meta: Meta = {
title: 'Scenes/MyScene',
parameters: {
featureFlags: [FEATURE_FLAGS.MY_FLAG, FEATURE_FLAGS.OTHER_FLAG],
},
}
Array entries are flags that evaluate to true. This is the common case.
Multivariate flags (pin a specific variant)
For a flag whose value is a variant string (experiment arms, multivariate rollouts), use
the record form — the array form can only express true:
// meta-level: applies to every story in the file
parameters: { featureFlags: { [FEATURE_FLAGS.THEME_OVERRIDE]: 'intent_plus' } }
// per-story: a different arm per story
export const ControlArm: Story = {
parameters: { featureFlags: { [FEATURE_FLAGS.THEME_OVERRIDE]: 'control' } },
}
export const TreatmentArm: Story = {
parameters: { featureFlags: { [FEATURE_FLAGS.THEME_OVERRIDE]: 'intent_plus' } },
}
You can mix booleans and variants in one record: { 'some-bool-flag': true, 'my-experiment': 'test_b' }.
Important
A story's
parametersreplace the meta's (shallow merge), so a per-storyfeatureFlagsdrops every flag set at the meta level. Re-list any meta flags you still need — silently losing one renders the flag-off branch and is easy to miss.
Why the obvious approach fails
Setting flags imperatively (featureFlagLogic.actions.setFeatureFlags) works in jest
(NODE_ENV==='test') but not in the built visual-regression Storybook. insights-js loads
flags and fires onFeatureFlags with an empty set, which dispatches setFeatureFlags
and wipes whatever you set imperatively — so the unit test passes while the snapshot
renders the flag-OFF branch. The featureFlags parameter avoids this by writing flags to
the always-merged baseline instead (below), so the empty callback can't clobber them.
Do not try to fix this by disabling insights-js flags (e.g.
advanced_disable_feature_flags). The app shell (appLogic.showApp) only renders oncereceivedFeatureFlagsis true, which is set by that sameonFeatureFlagscallback — suppress it and everyScenes-App/*story stalls behind a 3s timeout and flakes.
Under the hood (implementation detail — may drift)
This explains why the parameter works, for trust and for anyone extending the harness. Treat "How to use it" above as the contract, not this.
withFeatureFlags → setFeatureFlags (frontend/src/mocks/browser.tsx) writes the
flags (array or record) straight to window.INSIGHTS_APP_CONTEXT.persisted_feature_flags.
getPersistedFeatureFlags (frontend/src/lib/logic/featureFlagLogic.ts) reads that as
featureFlagLogic's initial value and spyOnFeatureFlags always merges it as the
baseline — so both booleans and pinned variants survive the empty onFeatureFlags
callback. The only production-side support this needs is getPersistedFeatureFlags
accepting the record form (variant values) in addition to the server's array form.
You should not need to touch any of this. If you're extending the harness, that's the seam.
See also
The featureFlags parameter only controls the flag. If a component's render also depends
on other runtime state (localStorage, an APP_CONTEXT field, a kea logic that resolves an
entry), stage that state too — typically in a small wrapper the story renders that sets it
and mounts the logic before rendering the component. Keep that wrapper in the story file;
don't add test-only props to the production component to make it renderable.