-
-
Notifications
You must be signed in to change notification settings - Fork 32.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
[ClickAwayListener] Expose a hook API #18689
Comments
@Izhaki You are right, I have just tested it, it doesn't work, we need to use the document owner. At least, I had to make the change to have it work inside an iframe. diff --git a/packages/material-ui/src/ClickAwayListener/ClickAwayListener.js b/packages/material-ui/src/ClickAwayListener/ClickAwayListener.js
index c689731b6..45ee7b22c 100644
--- a/packages/material-ui/src/ClickAwayListener/ClickAwayListener.js
+++ b/packages/material-ui/src/ClickAwayListener/ClickAwayListener.js
@@ -95,11 +97,13 @@ const ClickAwayListener = React.forwardRef(function ClickAwayListener(props, ref
React.useEffect(() => {
if (mouseEvent !== false) {
+ const doc = ownerDocument(nodeRef.current);
const mappedMouseEvent = mapEventPropToEvent(mouseEvent);
- document.addEventListener(mappedMouseEvent, handleClickAway);
+ doc.addEventListener(mappedMouseEvent, handleClickAway);
return () => {
- document.removeEventListener(mappedMouseEvent, handleClickAway);
+ doc.removeEventListener(mappedMouseEvent, handleClickAway);
};
}
We use functions for the outermost scope.
I'm curious about this, what's your use case for requiring a hook?
We very likely want the user to be able to push a ref (instead of pulling the value). This API can support it, which is great.
Awesome! :D |
That's odd. Kind of implies not a single person out there used the component inside Cosmos v1... hard to believe. And yes, that patch is exactly what I had in mind.
Why?
A component forces me to compose it using HOC. Although I'm not 100% sure how this adventure will end up, you can get an idea of what's happening looking at this code - lots of opt-in features only two of which are HOCs (which I'm trying to phase out). Some questions: What's your preferred implementation with regards to keeping propTypes for these? Using a hook, Also - a stylistic choice alright - but what's your view on changing this: const movedRef = React.useRef(false);
const nodeRef = React.useRef(null); To: const { current } = React.useRef({
moved: false,
node: null
}); Lastly, extracting a hook will not require changes to tests. But the Perhaps this should be done in two PRs? |
What's Cosmos v1?
A pure convention.
Awesome, thanks for sharing, this composition approach of hooks looks interesting.
We haven't been using prop-types for hooks so far. I think that you can keep them for the component. TypeScript can cover this problem, for people that value it.
I'm not sure you can change it in this context, it seems that it would break
I'm not aware we have any test for iframe, I don't think that we really need them, it's very niche. |
Thanks. Will attempt a PR tonight. |
Better dev tools support most of the time and convention from other languages. Lambdas are usually used for anonymous/inline/"small" functions. A component or hook is neither one of these. |
I'm going to wait with a PR for this until #18586 concludes. |
@Izhaki +1 for the preliminary iframe support patch :) |
Sure. Any reason your patch above only covers mouse events (and not touch events): React.useEffect(() => {
if (touchEvent !== false) {
const mappedTouchEvent = mapEventPropToEvent(touchEvent);
document.addEventListener(mappedTouchEvent, handleClickAway);
document.addEventListener('touchmove', handleTouchMove);
return () => {
document.removeEventListener(mappedTouchEvent, handleClickAway);
document.removeEventListener('touchmove', handleTouchMove);
};
} |
@Izhaki This was only for brevity. It's very likely that we need the same for touch events. |
Closing due to inactivity and as there much more valuable tasks in the backlog. |
I have added the |
I needed ClickAwayListener, but a hook rather than a component.
So I went ahead and extracted it from this repo, and now considering a PR here. A hook will shrink the component code to this:
Before, a couple of questions:
document vs ownerDocument
Event subscription happens on
document
, whereas the contain check happens on ownerDocument.I guess as no bugs were filed this works alright. But in more than a few DnD libraries out there subscription happens on
ownerDocument
(eg, to support iframe).So why subscribe on
document
ratherownerDocument
?Why function and not arrow function?
As in with:
Is there some convention in the code regarding when to use one or the other?
The text was updated successfully, but these errors were encountered: