-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Portals with provider #3544
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
Portals with provider #3544
Conversation
9e0a170 to
1d8c2a4
Compare
kyledurand
left a comment
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.
🎩 and code looks good. This should work really well with #3550 so that nested portals don't render custom properties if they match the parent, now that they're nested within the main theme provider
| ### Enhancements | ||
|
|
||
| Updated `Textfield` with a `type` of `number` to not render a spinner if step is set to `0` ([#3477](https://github.com/Shopify/polaris-react/pull/3477)) | ||
| - Updated Textfield with a type of number to not render a spinner if step is set to 0 ([#3477](https://github.com/Shopify/polaris-react/pull/3477)) |
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.
This can be 🔥 right? Should be captured in changelog already
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.
It hasn't been released so it can stay until we release an actual version ( not a beta )
| ### Bug fixes | ||
|
|
||
| Fixed `Filters` overflow ([#3532](https://github.com/Shopify/polaris-react/pull/3532)) | ||
| - Fixed `Filters` overflow ([#3532](https://github.com/Shopify/polaris-react/pull/3532)) |
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.
Same with this
| ); | ||
|
|
||
| expect(modal.find(Portal).prop('idPrefix')).toBe('modal'); | ||
| expect(modal.find(Portal)).toHaveLength(1); |
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.
✨
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.
![]()
I can't tophat in web at the moment because of an issue with my build. But looks good!
|
|
||
| const {setContainerNode} = portalsManagerContext; | ||
|
|
||
| return <div id="PolarisPortalsContainer" ref={setContainerNode} />; |
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.
Should this always be rendered @alex-page?
I'm working on updating from Polaris 5.8.4 to 5.10.1 https://github.com/Shopify/online-store-web/pull/8774
But seeing this error on buildkite for one of our tests

The component should be returning null if not rendered. But with this Polaris update, Polaris seems to always insert this div into the DOM.
Component being tested https://github.com/Shopify/online-store-web/blob/master/app/sections/Themes/ThemeIndex/ThemeIndex.tsx#L324
Failing test https://github.com/Shopify/online-store-web/blob/master/app/sections/Themes/ThemeIndex/tests/ThemeIndex.test.tsx#L107
Based on skimming this PR quickly, seems like portalsManagerContext would always exist in this component so would never render null. So seems like it is always rendered, but maybe this is necessary for supporting the Modal's/Portal's
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.
Hey @MLDimitry. Yep, you are correct. The way the portals work now this container is always rendered. Your test makes the assumption that none of the providers also output markup (not just your component). I would like to make this more automatic but for now you could update your test to something like expect(wrapper.find(ThemeIndex).html()).toBe(''); to be a bit more specific.
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.
Thanks for confirming what I figured + the context, I'll update the test to be more specific then 👍
Co-authored-by: Daniel Leroux <daniel.leroux@shopify.com>
WHY are these changes introduced?
This is an alternative approach to #3465.
WHAT is this pull request doing?
It changes the portals to use a provider that passes context for the container to render into instead of relying on all the manual DOM manipulation we have currently.
How to 🎩
🖥 Local development instructions
🗒 General tophatting guidelines
📄 Changelog guidelines
Copy-paste this code in
playground/Playground.tsx:🎩 checklist
README.mdwith documentation changes