Change `emitted().someEvent` to `emitted('someEvent')`

[lmiller1990]

Hi,

Sorry for a lot of issues lately. vue test utils is getting heavy use in my project (that's good!).

I often have tests that check if an event was emitted with the correct arguments. For example, I click a button, and it emits some updated text. In that case, at the moment I do

wrapper.find('#caption-input').element.value = 'New caption')
wrapper.find('#caption-button').trigger('input')
expect(wrapper.emitted().captionChanged[0][0]).toBe('New caption')

Especially the [0][0] is a awkward to type and know what is going on.

What I would like to be able to do:

expect(wrapper.emitted('customEvent').toBeTruthy()

// and something like this for checking the emitted payload, not sure if payload is the right word here though
expect(wrapper.emitted('customEvent').payload.toEqual('newCaption')

If accepted I will make the PR.

[vouill]

I like this emitted('customEvent'), its fairly easy to implement and maybe more intuitive. However [a][b] notation is pretty standard.

you can create an helper to achieve what you want:

expect(hasPayload(wrapper.emitted('customEvent'), 'newCaption').toBeThruthy()
 

const hasPayload = (calls, payload) => {
// search trough your calls arrays to find your payload
} 

I honestly would not recommend it because you want your components to always emit the same and brake if something change. Here, the payload detection is unaware of when he has been called

eg

wrapper.vm.$emit('foo')
wrapper.vm.$emit('foo', 123)
expect(hasPayload(wrapper.emitted('foo'), '123').toBeThruthy() // true

Then one of your dev mess up and actually change the order of emits

wrapper.vm.$emit('foo', 123)
wrapper.vm.$emit('foo')
expect(hasPayload(wrapper.emitted('foo'), '123').toBeThruthy() // still be true

==> No tests breaks while the behavior has changed

wdyt ?

That's my 2 cents :)

[lmiller1990]

Hm, I did not think about the order. Say I want to have multiple emits, I guess it would look like:

// emit an event w/o payload
expect(wrapper.emitted('customEvent')[0]).toBeTruthy 

// emit an event w/ payload
expect(wrapper.emitted('customEvent')[0].payload).toEqual('new caption')

I didn't know [a][b] notation was standard. For this case, I can see what we have [a] - there could be many emits. However for emits, do people ever have more than one arg? I tend to always emit an object in that case, with all the properties. I can't imagine a situation where you would do wrapper.emitted[0][1] - would that ever contain anything?

I still would prefer wrapper.emitted('foo')[0].payload to wrapper.emitted().foo[0][1], I think it's more intuitive. If there is a common notation like [a][b] though, convention > opinion.

[vouill]

$emit takes multiple arguments :).
Check jest.fn and sinon.spy , they also represent function calls this way ( and its super awesome to use it w/ .toMatchSnapthot() if you use jest ).

As i said i like your .emitted('foo'), its pretty intuitive and practical. A PR for it maybe ? wdyt @eddyerburgh

[lmiller1990]

Will get started on a PR if @eddyerburgh is okay with this feature :)

[eddyerburgh]

The reasoning behind the array is that you can tell what order the events were emitted in.
We can have both syntax, so I'd be happy for a PR that implements emitted('customEvent')

[lmiller1990]

Hey, just an update, have made start, hopefully get a first PR up by this weekend.

[lmiller1990]

#181 add this feature. :party: