-
Notifications
You must be signed in to change notification settings - Fork 548
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
@click.outside to handle clicks outside an element #167
Comments
How would you then register a normal Example <button @click="onClick" @click.away="onClickAway" /> |
Hmm, great question. You should be able to register both, just like that, depending on if Vue's internals will allow that to happen. Because: the |
I like the idea and I have used the package you mentioned myself in numerous occasions, but I think this would be better if it was included as a directive and not a modifier to the Lets see what others say about this. Thanks for the rfc, I think it will spike up some good discussion :) |
I like the idea. But, I'm also unsure about it because On the other hand, I find I'd also add, having this functionality built in probably makes sense with the new built-in <teleport to="#endofbody" v-if="showModal">
<div id="content" v-click-outside="showModal = false">
<p>
this will be moved to #endofbody.<br />
Pretend that it's a modal
</p>
<Child />
</div>
</teleport> |
@aztalbot good points 😄. I agree that I'd often write this logic myself vs pulling in a third-party library. I actually did it this morning in a Vue 3 (Beta) project. For me, it's definitely less about the amount of characters, or even library weight (since vue-click-outside is @bangjelkoski I don't really love using a directive for this, because this use-case is so close to being the same as handling a normal click event. We've already got a way to manage events, and we've already got modifiers. In my mind this is a valid use-case of an event+modifier. |
The idea sounds nice but I'm not sure it's worth it.
|
@jods4 you're last comment is interesting. Do you think it might make more sense to provide a basic building block then, like a |
@aztalbot That's an interesting primitive to have! In the realm of "interesting ideas": Vue compiler is extensible you can create plugins.
|
I was also thinking what about a For focus/blur specifically, there's the caveat that I think this RFC brings up interesting things to solve:
I agree that That said, there's an obvious need to be able to register events outside the DOM of your component in order to even begin to solve these types of issues. I could see it being a core feature since it's something that every component of a certain type of component would need to care about. Like every dialog/modal/tooltip/dropdown component should care about this.. and if my dialog component is using one lib and dropdown another and tooltip makes up its own solution then that bloats my final app with 3 solutions for the same thing. There may also be missed performance opportunities... is it better to register a single event handler on the body and iterate through which callbacks it needs to fire or better to register one per callback? I believe jquery still does the former so I assume that's still the better option. Perhaps a low-level core solution is to simply allow adding event handlers to the body (I don't believe I've seen anything for this as of yet)... and the "filtering" of whether they're inside or outside of your component is up to the implementation so userland could build on top of it to provide inside/outside functionality or likely other useful things as well (game controls come to mind). I'm also wondering if we'd need to add event handlers to things other than body, but I'm not having a use case come to mind for it. |
I'm divided. Like many others, I'm using v-click-outside. And a But my main concern is that the modifiers are supposed to alter the event that is attached to the element.
But |
FWIW I'd love to see someones implementation of |
@9mm are you in discord? Nag me over there and I'll share what I have with you when I'm at work. |
1 and half years later and this is still open? IMHO this modifier should definitely exist. Using Alpinejs for this is super handy and I really miss this in Vue. I don't like to install small packages like that in real applications even though they do a really good job on this, but I don't want to have one more tiny package to audit against security rules in a company for open source projects and dependencies, especially in a growing hostile environment for npm packages. I can't see a package with Vue that doesn't use such a feature. This is simply needed for dropdown elements and floating menus which basically EVERY application has. I'd love to contribute, but unfortunately, I have no idea where to start and don't have enough time for this right now. But I'd like to leave my feedback on this issue. By the way, thank you for the awesome framework. 👍🏻 🚀 |
I don't like installing too many packages either, but it's not a great argument. v-click-outside can be so small that if you don't want to take a dep. on a package, you could just write the code directly in your app. I raised the concern before that the semantics of a useful click-outside might be not so well defined for core inclusion. For this to make it into core Vue, I think the first step is to discuss the specifications of what we want |
Proposal
I would love to be able to write either
@click.outside
to handle any click outside of an element. This is a common use-case for things like modals or dropdowns that should close when you click away from them. The demand for this has already been proved by v-click-outside which has 60,000 weekly downloads on NPM.This seems like a trivial thing, but I think it would improve the DX of working with Vue.
Naming
I think
@click.outide
is the most intuitive API. Alpine.js went with@click.away
but when I asked the author why, he said he wasn't sure and that "outside might honestly be better" (source)API
I think a simple API like
@click.outside="handleOuterClick"
makes sense. I'm not sure if there's enough value in adding some of the options that v-click-outside has to warrant the larger API surface area, and kinda awkward API. For more advanced/complex use-cases people can alwaysPrior Art
@click.away
: https://github.com/alpinejs/alpine#x-onv-click-outside
: https://github.com/ndelvalle/v-click-outsideIf this gets support, core team members are okay with it, then I'm happy to take a crack at an implementation and PR it!
The text was updated successfully, but these errors were encountered: