OptionalappliesWhich styles or contexts the knob works in. A string rather than a fixed union so each
module can choose its own vocabulary — styling uses 'any-style' | 'tomtom-styles'.
OptionalavailableWhether the knob has anything to work on in the loaded style. Omitted by modules whose knobs
are always applicable; set to false by modules where a knob can be present in the catalogue
but do nothing on the current style.
The value in force now.
The value in force when nothing has been configured.
One-line description of what turning this knob does.
Stable, dotted identifier, e.g. labels.sizeFactor. Treat these as public API: they are what
a caller stores, diffs and passes back.
What kind of value the knob takes.
OptionaloptionsThe allowed values, for enum knobs; the names accepted besides CSS colours, for colors knobs.
Whether KnobDescriptor.current came from configuration rather than the default.
OptionalrangeInclusive bounds, for factor and number knobs.
A single, machine-readable description of one display knob.
Remarks
The point of describing knobs as data is that a caller — increasingly a coding agent rather than a person reading docs — can ask what a module actually exposes instead of guessing layer ids from training data. Three things follow from having it:
A visual editor cannot do any of those: it cannot be read, diffed, or put in a pull request.
Modules narrow this shape with their own descriptor type — e.g.
StylingKnobDescriptorrequiresavailableandappliesTo, while a module whose knobs are always applicable omits them.