[FxMS Infra] No shared, maintained catalog of screen content properties (Spotlight/Feature Callout)
Categories
(Firefox :: Messaging System, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox156 | --- | fixed |
People
(Reporter: mjung, Assigned: sachung)
References
(Blocks 1 open bug)
Details
(Whiteboard: [omc])
Attachments
(1 file)
Messaging System renders Spotlight and Feature Callout messages from a content.screens[] model that is shared with about:welcome onboarding. this screen model exposes a large/growing set of content properties, but there is currently no discoverable, authoritative catalog of what those properties are. The closest being feature-callout.md which is thorough but covers only the FC surface and is hand maintained (so it can drift and doesn't document the Spotlight/about:welcome split-screen properties like layout, split_content_justify_content, hide_secondary_section, reverse_split, ..)
- nimbus mega schema (
MessagingExperiment.schema.json) validates messages againstSpotlight.schema.json, but that schema declaresscreensas an untyped array ({ "type": "array" }) withadditionalProperties: true, so no screen/tile property is documented or validated (which I believe is deliberate choice and not what this bug is proposing to change) - There are no
PropTypeson the screen renderer components inMultiStageProtonScreen.jsx,MultiStageAboutWelcome.jsx
As a result, the only practical sources of truth are the renderer JSX and copy pasting from existing messages. Because there is no index, naming is sometimes inconsistent (snake_case vs camelCase, like no_rdm vs no-rdm). I've found myself adding a new property that already existed and I was unaware of and I suspect this will get worse with the additional squad split, as more people author screens without shared context.
Opening this up for discussion/feedback, but some options:
- Add PropTypes to the screen renderer components, documenting each prop in place and surfacing dev-time warnings when messages use unknown or malformed properties. This is the more durable fix.
- Optionally maintain a non-enforcing "documentation" screen schema
Updated•2 months ago
|
Updated•2 months ago
|
| Assignee | ||
Comment 1•2 months ago
|
||
Updated•1 month ago
|
| Assignee | ||
Updated•1 month ago
|
Comment 3•1 month ago
|
||
| bugherder | ||
Updated•22 days ago
|
Description
•