Description
Validate the config object against configAttributes and warn on anything that does not match. Do not change the value.
Why should this feature be added?
Config is the only user-facing input plotly.js never checks. Plotly.validate takes data and layout only. A typo like edits: { shapePositon: true } does nothing, reports nothing, and costs the user an afternoon.
plotly.py already wants this. plotly/offline/offline.py warns on unknown keys from a hardcoded tuple, with the comment: "we don't have code generation logic in place yet to guarantee that the config options in plotly.py are up to date". Schema-driven validation in plotly.js gives every port the list.
Notes
- An unknown key gets dropped with no notice
- A value that fails its
valType doesn't get stopped
- We should warn on invalid values. Coercion would replace bad values with defaults and silently change charts that work today.
- Utilize the existing
Lib.validate and Lib.warn
- Skip the five attributes whose
valType is any. Lib.validate accepts anything for them.
- This should only validate the incoming config, not the resolved
_context
- This might be noisy for users until configs are corrected
Description
Validate the config object against
configAttributesand warn on anything that does not match. Do not change the value.Why should this feature be added?
Config is the only user-facing input plotly.js never checks.
Plotly.validatetakesdataandlayoutonly. A typo likeedits: { shapePositon: true }does nothing, reports nothing, and costs the user an afternoon.plotly.py already wants this.
plotly/offline/offline.pywarns on unknown keys from a hardcoded tuple, with the comment: "we don't have code generation logic in place yet to guarantee that the config options in plotly.py are up to date". Schema-driven validation in plotly.js gives every port the list.Notes
valTypedoesn't get stoppedLib.validateandLib.warnvalTypeisany.Lib.validateaccepts anything for them._context