-
Notifications
You must be signed in to change notification settings - Fork 669
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
Better API to trigger custom events #1588
Comments
FYI @arsenaultk9 |
While it is possible to do this on the VueWrapper, I am not 100% sure it is correct. If you list to a In Vue 3 and hence VTU 2, we can do this, as there is no @lmiller1990 any opinions? |
Oh right, I forgot to mention I use |
I think the main problem we will run into is I can see why this is confusing, but a component emitting an event is pretty difficult to a DOM event getting triggered; I am not sure how much sense this change makes 🤔 Regarding not testing implementation details; that means you should not do In this case of |
Interesting! To me, as soon as an event is triggered on a component it means the user interacted with your app. No matter if this is something as low level as a And as a user of that It is even more true if the component is from an external library that I should not know how it is implemented so it can evolve without breaking my app. As long as the contract is not broken. About the fragile test problem, here is another example: let's say I have a component using a <template>
<div>
<button @click="$emit('rainbows')" data-test-id="button">Click me</button>
</div>
</template> With the following test (with the wrapper being shallow mounted): it('emits rainbows', () => {
const button = wrapper.find('[data-test-id="button"]')
const button.trigger('click')
expect(wrapper.emitted('rainbows')).toBeTruthy()
} It will work and you'll get 🌈. But as soon as you change the In this case, I know I could use |
I see what you mean. I have one comment, and then we can move on and discuss the original issue (improving the API):
Sure, but what if
Anyway, opinions aside, I assume you have some kind of extremely complex component tree where you cannot use wrapper.find(Tweet).vm.$emit('like', { likedByUserId: 1, totalLikes: 5 })
await wrapper.trigger('click', {
ctrlKey: true // For testing @click.ctrl handlers
}) It may be difficult to combine these, since they both take an object of options as the second argument, but the usage is very different. One alternative could be |
I think we should not combine the two, as they serve different purpose in Vue 2, as I explained earlier. But I also think adding |
I like |
So |
You would just call emit('click', payload). As long as your component emits that, should be fine |
Hm, I feel introducing this API would set the direction for people to trigger events programatically, instead of interacting with the component "manually". While it is true that some cases w/ shallow mount may require a test to trigger a custom event, I'd say anyway, my two cents 😃 |
You could write this in VTU next with the plugin system. Maybe we should just backport this feature to this codebase as well. Another alternative is add it yourself: import { VueWrapper } from '@vue/test-utils'
VueWrapper.prototype.emit = (evt, ...rest) => {
this.vm.$emit(evt, ...rest)
} (not tested). Considering how trivial this (should) be to add, I think we just let the people who want it add it. I personally have a lot of util methods I use for my various Vue projects. Lean core + build your own abstractions seems like the way to go for maximum flexibility. I thought about this a little more and am leaning towards @afontcu's side - although you save a few keystrokes, I think mostly it's better to be more explicit - |
What problem does this feature solve?
Currently, when you want to emit an event on a custom component, you have to access the vm of that component and manually trigger the event. But when it is a DOM event, you can simply
trigger
that event.For example:
It is confusing (especially for beginners) to have two different ways of triggering an event.
And also, as the test should not know implementation details, it makes the test more fragile.
In my opinion, as the expected outcome is the same in both cases, the end user should not have to think about that and should be able to use the same API.
What does the proposed API look like?
If it's ok for you, I can open a PR to fix this.
The text was updated successfully, but these errors were encountered: