feat(Scoping): use themeProvider for scoping - #1380
Draft
ragi96 wants to merge 1 commit into
Draft
Conversation
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
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.
feat(scoping): scope block CSS by marketplace app id via StyleProvider
Why
Every block scopes its generated CSS so it doesn't leak into the surrounding guideline. Until now that scope was kept in sync by hand in two disconnected places per block:
<div className="x-block">wrapper in the component, andscope: '.x-block'inpostcss.config.js.This is fragile —
glyphs-blockproved it by renderingclassName="glyps-block"(typo) while scoping to.glyphs-block, so its scoped styles never matched the element. The class names were also arbitrary and not tied to anything canonical.This PR makes the marketplace app id (
appIdfrom each block'smanifest.json) the single source of truth for scoping, used by both the runtime class and the PostCSS build scope, and centralizes the wrapper inStyleProvider.What changed
StyleProvidernow owns the scope element. It renders the wrapping<div>, applies theappIdas itsclassName, and forwardsref+ arbitrary DOM props (data-test-id,key, extra classes). It also passesappIdto Fondue'sThemeProviderclassName, which propagates the scope class to portaled content (Dropdown, Tooltip, Dialog), so overlays rendered atbodylevel are scoped natively.postcss.config.jsnow usesscope: `.${require('./manifest.json').appId}`instead of a hard-coded class.postcss/scope.js. Removed thegetModalExtensionshack (the hardcodedbody [data-overlay-container]/[role='dialog']/[data-is-underlay]/[role='toolbar']selectors) — Fondue'sThemeProviderpropagation now covers portals, so a plain${scope} ${selector}prefix suffices.<div className="x-block">wrapper is replaced by<StyleProvider appId={manifest.appId} …>with preserved props.glyphs-blockstyling bug for free (theglyps-blocktypo class is gone).Result
Generated CSS is now isolated per block, e.g. for
gradient-block:Since each block has a unique
appId, blocks no longer interfere with each other.Verification
pnpm typecheck,pnpm lint,pnpm prettier— all cleanpnpm test:unit— 243 passed.<appId>with no overlay extensionspnpm test:components(Cypress) not run — couldn't launch in the dev sandbox; please ensure CI runs itThings to fix
🤖 Generated with Claude Code