Refactor: Audit custom event payload for consistency

[jcfranco]

Summary

We have inconsistencies when it comes to emitting custom events:

1. Emitting with a value

• with an object, e.g., this.calciteFoo.emit({ foo: "foo" })
• with a value, e.g., this.calciteFoo.emit("foo")

2. Typing the event – EventEmitter is not typed consistently

• typed based on the types from 1, e.g., calciteFoo: EventEmitter<FooDataObject>;
• untyped calciteFoo: EventEmitter

For 1, we should emit an object for future-proofing, regardless of how many props are included.
For 2, we should always provide a type on EventEmitter. void should be used if there is no event payload. We can even add an ESLint rule to catch this.

Additionally, our conventions should be updated with this information and to also review whether it makes sense to introduce a prop instead of being part of an event's payload (to avoid cases where a prop from the event's detail ends up being a prop in the future and therefore redundant).

cc @benelan @samMatenaer

Additional resources

#2854
#2858
#3163

[driskull]

Here are some events I found that could deprecate their event payload or clean it up to be consistent.

• calciteComboboxFilterChange
• calciteDatePickerRangeChange
• calciteDropdownSelect
• calciteRatingChange
• calciteTabChange
• calciteTreeSelect
• calcitePaginationChange
• calciteDatePickerChange
• calciteDatePickerActiveDateChange
• calciteDatePickerSelect
• calciteRadioGroupChange
• calciteTabsActivate
• calciteListChange
• calciteListOrderChange

Some of them may require introducing a public property in order to remove the event payload.

@geospatialem should we make this a list for us to divvy up the work?

[driskull]

This one should be good now.

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verification

• 1. Event values with an object
  • All events have objects, confirmed on master branch
  • Note: There are a few private events and methods that use values such as toggleExpand (action-bar, action-pad), openHandler (multiple components), etc. Maybe something we could consider refactoring post-1.0?
• 2. Event typings
  • All events verified on master branch