-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apply a StyleProvider around fills that can be used inside the iframe #31073
Conversation
What do you think @ellatrix @sarayourfriend I'm personally hesitant but I feel this is better than having to rely on a custom emotion for the components. |
Interesting challenges to solve 😄 I think there is also a Fill for the dropdown menu items in the block toolbar to cover if you decide to go this path. |
Size Change: +40 B (0%) Total Size: 1.47 MB
ℹ️ View Unchanged
|
I'd rather this than relying on a custom wrapper. If for some reason this becomes too much we can always revisit the custom wrapper just like we said we'd revisit vanilla emotion the other way around. iframe support should only get better in vanilla emotion though 🤷♀️ |
packages/block-editor/README.md
Outdated
_Related_ | ||
|
||
- <https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/block-settings-menu-controls/README.md> | ||
Undocumented declaration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops, why did this happen?
function BlockSettingsMenuControls( { ...props } ) { | ||
return ( | ||
<StyleProvider iframeDocument={ document }> | ||
<Fill { ...props } /> | ||
</StyleProvider> | ||
); | ||
} | ||
|
||
BlockSettingsMenuControls.Slot = BlockSettingsMenuControlsSlot; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're missing the default export now I believe.
@@ -13,7 +16,11 @@ const { Fill, Slot } = createSlotFill( name ); | |||
|
|||
function InspectorAdvancedControls( { children } ) { | |||
const { isSelected } = useBlockEditContext(); | |||
return isSelected ? <Fill>{ children }</Fill> : null; | |||
return isSelected ? ( | |||
<StyleProvider iframeDocument={ document }> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if we changed iframeDocument
to just be document
? At this point it's not just for iframes 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it makes sense :)
Sounds good to me. It would be nice if it somehow automatically looked at the |
ca0af65
to
06790fd
Compare
Nice, I hope we didn't miss any fills. What is rendered inside the iframe? I was thinking about all plugins that integrate with the sidebar or the publish sidebar. |
these are ok, the issue is when the elements are rendered inside the iframe for slots that appear outside the iframe. |
In theory, you could render all plugins inside |
closes #31070
#31010 fixed CSS-in-JS inside the iframe but it broken the styles applied to components rendered inside portals inside the iframe. These portals actually render the elements outside the iframe.
This means we need to wrap these portals with a style provider referring to the parent document.