Components: Introduce portal-based slot / fill alternative, render Popover as slot / fill #2966
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2966 +/- ##
=========================================
- Coverage 33.15% 32.9% -0.25%
=========================================
Files 200 202 +2
Lines 5836 5883 +47
Branches 1031 1040 +9
=========================================
+ Hits 1935 1936 +1
- Misses 3293 3330 +37
- Partials 608 617 +9
Continue to review full report at Codecov.
|
components/dropdown/test/index.js
Outdated
| @@ -8,6 +8,8 @@ import { mount } from 'enzyme'; | |||
| */ | |||
| import Dropdown from '../'; | |||
|
|
|||
| jest.mock( '../../slot-fill/fill' ); | |||
There was a problem hiding this comment.
I'm surprised it works :)
My experience so far was that Jest expected absolute paths everywhere. The nice thing is that it warns when it isn't able to locate a file that it should mock.
a2e813a to
6b54119
Compare
|
Rebased to resolve conflicts. I started toying locally to see whether the custom implementation would work well for our other use of Slot / Fill and for the most part it does. One issue was if a fill is rendered before the slot is mounted. The updated implementation now tracks all fills and forces a re-render should a slot become registered for that name. Further, I made the provider context optional for slot and fills, avoiding the need to mock tests on Fill (default behavior will render children verbatim in-place). Finally, since I did the work... I decided to just finish dropping |
Hmm, this appears to be problematic, since for something like block inspector, if the sidebar panel isn't opened, the inspector controls will render adjacent the preview, rather than not render at all. Probably need to revert this specific change. |
|
This grew a bit larger than I would have liked, but it should be pretty well settled now. In recent changes:
|
|
Still working great 👍 |
Components: Track fill registration Since slot isn't guaranteed to be mounted at time of initial fill render, track fills so that when slot does become available, we can re-render each fill Components: Remove provider requirement for Slot Fill Render children verbatim if no context available Components: Avoid rendering fill if no slot context
Components: Check popover context before rendering to Fill
bdbb2a6 to
1fbb24f
Compare
|
Nice work here, @aduth. |
This pull request seeks to refactor Popover to simplify rendering as a slot / fill pair, rather than require a custom context provider providing a DOM node render target.
Implementation notes:
Originally I sought to implement this using
react-slot-fillas we use elsewhere, but quickly encountered similar issues as discovered in #2734 where lifecycle of slot content is not always predictable since component updates are reflected only after a subsequent state change.Recognizing that React 16's portals feature provides the tools for a Slot / Fill implementation, I sought to explore what would be necessary for a first-party implementation. Happily it seemed to work quite well, needing only a context provider to register, unregister, and retrieve
refnodes of the renderedSlots to which aFillcan create a portal. The first-party portal implementation does not suffer from the same lifecycle issues asreact-slot-fill. Further encouraging is that such an approach appears advocated by Dominic Gannaway, a React core team member.We should decide whether this is worth using as a substitute to
react-slot-fill. It may be worthwhile to split this pull request into two, where the first would convert existing usage to the new WordPress-specificslot-fill.Testing instructions:
Verify that there are no regressions in Popover usage, particularly: