Demo type · 19

Editor feature flags — toggles and what they switch on

Use this when the reader needs to feel how settings depend on each other — a panel of switches where turning one on quietly requires another, and the screen warns you the moment the set is inconsistent.

This is a copyable exemplar. Lift the <section id="toggle-it"> stage into a real lesson built from assets/lesson-template.html, keeping the design tokens verbatim.

1

What this format does

A feature flag is just an on/off switch for a piece of your product — flip it on and a feature appears, flip it off and it's gone, with no code change. The catch is that features lean on each other. The shiny new checkout only makes sense if the new cart is already running underneath it. Turn the checkout on while the cart is off and you've shipped a button that leads nowhere.

The job of this panel is to make that mistake impossible to miss. The instant you switch on a flag whose support is turned off, a red warning slides in under it telling you exactly what's missing — and a summary line at the bottom always reads back the set of features that are actually live.

Think of it like… the light switches in a new house. Flipping on the porch light does nothing if the main breaker for that wing is off. A good panel doesn't just sit there dark — it puts a little tag on the switch: "needs the breaker on first."

Under the hood

Each flag is a boolean keyed by a stable id (new_checkout, new_cart, …). A separate dependency map records, for each flag, the ids it requires: new_checkout → [new_cart]. After every toggle the editor recomputes, for each enabled flag, whether all of its required flags are also enabled. Any flag that is on but has an off dependency is unsatisfied and renders an inline warning.

The active set that the summary reads is not simply "every flag that is on" — it's the set the system would honour. A flag with a broken dependency is shown as on in the editor (you did toggle it) but flagged as not delivered, because shipping it without its support would be the bug. The "Enable dependency" fix is a convenience that flips the missing requirement on so the warning clears in one click.

2

Toggle it yourself

Flip the switches. Turn new-checkout on while new-cart is off and watch the warning appear. The summary line at the bottom always tells you which features are actually live.

new-cart

Rebuilt shopping cart with live price updates. The foundation everything else sits on.

requires: nothing — base feature
new-checkout

One-page checkout flow. Reads its line items straight out of the new cart.

requires: new-cart
express-pay

One-tap wallet payment. Lives inside the new checkout, so it needs that on first.

requires: new-checkout
gift-receipts

Hide prices on a printable receipt. Stands on its own — no dependencies.

requires: nothing — base feature

Active feature set

One map drives every warning

The flags are a flat boolean record; a second object lists the requirements. After any toggle the editor checks each enabled flag against its requires list. A flag that is on but missing a requirement is unsatisfied — it draws the inline warning and is excluded from the active set the summary reads back.

const flags = { new_cart:false, new_checkout:false, express_pay:false, gift_receipts:false };

const requires = {
  new_cart:      [],                  // base feature
  new_checkout:  ['new_cart'],        // needs the cart underneath
  express_pay:   ['new_checkout'],    // lives inside checkout
  gift_receipts: []
};

function missingDeps(id) {
  return requires[id].filter(dep => !flags[dep]);   // off requirements
}

function activeSet() {
  // on AND all requirements satisfied = actually delivered
  return Object.keys(flags).filter(id => flags[id] && missingDeps(id).length === 0);
}