feat(viewer): report resolved theme id + mode to the host on theme change#194
Merged
Conversation
…ange
`onThemeChange` handed the host only the resolved token VALUES, not which
theme/scheme produced them. That's enough for a host that paints its own
chrome from the tokens, but not for one that re-renders surfaces
out-of-band: the cloud's feed preview frames are opaque-origin sandboxes
served by `/s/:id`, which needs `?theme=&mode=` to reproduce the viewer's
exact look. Without the ids, cross-workspace previews (the org feed) fell
back to each source workspace's persisted theme instead of the viewer's.
Add a second `meta: { theme, mode }` argument carrying the resolved theme id
and light/dark scheme the engine already knows (it builds its own surface
URLs from them). Additive: the tokens argument is unchanged and the default
self-hosted host ignores it — parity preserved.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
onThemeChangehanded the embedding host only the resolved token values, not which theme/scheme produced them. That's enough for a host that paints its own chrome from the tokens, but not for a host that re-renders surfaces out-of-band.Concretely: the sideshow cloud's feed preview cards are opaque-origin sandbox iframes served by
/s/:id, which needs?theme=&mode=to reproduce the viewer's exact look. Without the ids, the host can only passmode(sniffed off the pinnedcolor-scheme), so cross-workspace previews (the org activity feed) fall back to each source workspace's persisted theme instead of the viewer's — the previews render in the wrong palette.What
Add a second
meta: { theme, mode }argument toonThemeChange, carrying the resolved theme id and light/dark scheme the engine already computes (it builds its own surface URLs from exactly these).tokensargument is unchanged; the default self-hosted host omitsonThemeChangeentirely, so self-hosted parity is preserved.viewer/embed.d.tspublic declaration to match.e2e/embed-theme.spec.tsto assert the pushedmetaon mount ({ theme: "github", mode: "light" }) and after a theme switch (gruvbox).Test
npm run typecheck✓ ·npm run lint✓ ·npm test✓ (412)npm run build✓ ·npx playwright test embed-theme✓ (chromium; webkit skipped — missing system deps in this env)Changeset:
minor.