-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Components: Port Popover to use withViewportMatch #5316
Conversation
Relevant Slack discussion on the options for resolving a circular dependency: https://wordpress.slack.com/archives/C02QB2JS7/p1519849919000163 One option proposed here was to move the
|
Isn't this what the distinction between containers and components is about? I get that this distinction can sometimes create more work than it is worth, but in this scenario, it looks like there is a clear use-case.
|
@atimmer This distinction is what has led to this situation, as The issue arises when we consider whether purely visual components should ever need to share their own internal state. This is what was tentatively proposed in early iterations of But then... should we not want other plugins or internal code to be able to leverage this data? For behaviors like collapsing sidebars when the viewport shrinks? It's an interesting question because in all cases it's clearly state, regardless of whether it's tracked in a component instance or as a store in the data module. Further, here it's state which is not strictly within the realm of the application; viewport is not domain-specific data. We could certainly create a rigid divide where UI components are strictly forbidden from using Personally, I don't find the distinction to be very helpful, and in fact I'd suggest it could introduce some confusion (when would |
Responsiveness seems like a presentation-level concern, and if we except that, I think it is reasonable to consider viewport state in the implementation of presentational components. It may even be useful as an explicit statement on how this set of components responds to viewport changes. Personally, I like the clarity of importing from a Note: I have a personal interest in this for adding a |
Just noting that both solutions solve the issue with I still think there is a value in extracting a |
This can probably be revisited again now that #7948 is merged to resolve some of the foundational issues blocking this one. |
@aduth -- is this still relevant or should we close? |
@catehstn It's still relevant in that Popover manages its own "is mobile" state without using the canonical viewport module. However, at a glance, I can't see if/how this is managed in the component, so it could also very well be dead code. It needs investigation. I'll plan to take a look sometime today. https://github.com/WordPress/gutenberg/blob/master/packages/components/src/popover/index.js |
Ah, it's not dead code, but it is still an ad hoc solution which should be brought in line with the rest of the application.
|
@@ -2,7 +2,25 @@ | |||
* WordPress dependencies | |||
*/ | |||
import { compose, getWrapperDisplayName } from '@wordpress/element'; |
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 is no longer an issue since we extracted compose package.
@aduth do you plan to update this PR? 😃 Edit: it still introduces the dependency on |
I spent a bit of time the other day trying to bring it back up to date. It required a bit of refactoring since |
Noting that this doesn't build with |
I am, yes. I've been neglectful of it, since it's more of a code quality item, and thus been hard to justify bringing priority to it. |
I'm labeling this issue as |
Closing as:
|
This pull request seeks to port the
Popover
component to use the newly-introducedwithViewportMatch
higher-order component. Currently,Popover
manages its own internal state value for considering anisMobile
state. This also causes some unnecessary calls tosetOffset
when setting theisMobile
state.However, this effort has surfaced an alarming concern with our current approach to modules, as the
viewport
module already depends oncomponents
for itsifCondition
higher-order component. The changes here introduce a circular dependency between the two modules, withPopover
now creating a dependency back toviewport
.This warrants some discussion on how we might alleviate this issue.
Some options to consider:
viewport
into thecomponents
module, while still allowing it to declare its own store. Or, if we want a single store, consider how we might accumulate components state into a single components store.ifCondition
higher-order component used byifViewport
to be part of an abstract compositional language of components, should these be separated from the rest ofcomponents
? We already loosely establish a separation via a nestedcomponents/higher-order
subdirectory.Testing instructions:
Verify there are no regressions in the behavior of mobile popover behaviors, particularly that the Inserter on mobile displays stretches to the bounds of the viewport and displays a close button.