refactor: use calciteInternal prefix for internal events

[Elijbet]

Related Issue: #2256

Summary

Renaming internal events to use calciteInternal prefix and stopping them from propagating when handled (where propagation is not needed).

List of Internal Events revised:

calciteAccordionItemKeyEvent
calciteAccordionItemSelect
calciteAccordionItemClose
calciteItemRegister
calciteAlertSync
calciteAlertRegister
calciteComboboxOpen
calciteComboboxClose
calciteDayHover
calciteDatePickerHover
calciteDatePickerMouseOut
calciteDropdownItemChange
calciteDropdownItemSelect
calciteDropdownItemKeyEvent
calciteDropdownCloseRequest
calciteInlineEditableEnableEditingChange
stop and check if all green first
calciteInputFocus
calciteInputBlur
calciteInputDatePickerOpen
calciteInputDatePickerClose
calciteInternalLabelClick
calciteOptionChange
calciteOptionGroupChange
calciteListItemPropsChange
calciteListItemValueChange
calciteInternalRadioButtonBlur
calciteInternalRadioButtonCheckedChange
calciteInternalRadioButtonFocus
calciteRadioGroupItemChange
calciteStepperItemChange
calciteStepperItemKeyEvent
calciteStepperItemSelect
calciteStepperItemRegister
calciteTabRegister
calciteInternalTabChange
calciteInternalTabsActivate
calciteTabsFocusNext
calciteTabsFocusPrevious
calciteTabTitleRegister
calciteTabTitleRegister
calciteTimePickerBlur
calciteTimePickerChange
calciteTimePickerFocus
calciteTreeItemSelect

[driskull]

Looks good! 💯

[driskull]

These open/close ones might be useful for users at some point.

[driskull]

#1688

[Elijbet]

Should we be removing @internal from Open/Close events then and making them public? Or did you mean specifically for combobox?

[eriklharper]

I concur with @driskull on this one too. Open/Close events should probably be publicly exposed. Especially since this is a top-level component that isn't emitting this event for another Calcite component to listen for. In that case, just removing the @internal label on it and restoring the original event name should suffice.

[driskull]

I'm just questioning why these are internal. We may want to expose them at some point but we can do so later if needed.

[Elijbet]

Should there be a follow-up issue for all top-level components to publicly expose Open/Close events, or does this need to be discussed for all components, including nested?

[eriklharper]

I like the idea of starting a pattern discussion on open/close events and if places that use them should expose them publicly if they aren't already. Let's create a discussion for this here: https://github.com/Esri/calcite-components/discussions

[jcfranco]

For context, these and others were made internal because it wasn't clear if they were meant to be public and there are a few that could be consolidated into a generic calcite<Event>.

[eriklharper]

I'm actually trying to remember why these two events are actually labeled @internal. These seem like public events that consumers should have access to. @driskull @jcfranco what do you all think?

[driskull]

I'm not sure about the inputblur. That native event should bubble up.

The open/close ones seem like they should be public.

[eriklharper]

Should shadowed <input> element events bubble up when there are calciteInput* event equivalents? Seems redundant to allow both, but this is probably why these were labeled @internal in the first place because we were relying on the native events to bubble.

[driskull]

I don't think there can be equivalents because CustomEvents aren't the same as Keydown, Click, Blur, etc.

I think we should let the native events bubble out.

I don't like how we're passing the native events in some Custom events either. Seems kind of odd to do that.

[eriklharper]

I guess I'm trying to understand the distinction between the native events and the custom events. What are the custom "Input" and "Change" events really there for if the native ones are already bubbling out and usable?

[eriklharper]

I'm actually trying to remember why these two events are actually labeled @internal.

I think I remember now. It is most likely for other Calcite components that consume Calcite Input in their shadow DOM for styling or other purposes.

[eriklharper]

I don't like how we're passing the native events in some Custom events either. Seems kind of odd to do that.

I guess if we chose to stop bubbling the native events, this would be the way to still expose them to listeners via the custom event.

[eriklharper]

FYI, created a discussion for this here: https://github.com/Esri/calcite-components/discussions/4546

[eriklharper]

I don't think there can be equivalents because CustomEvents aren't the same as Keydown, Click, Blur, etc.

Should we then ditch redundant custom events like calciteInputBlur and calciteInputFocus (and potentially many others) and just rely on native bubbled events?

[jcfranco]

I'm actually trying to remember why these two events are actually labeled @internal.

From #1705:

Note: focus/blur events were made internal to allow for more general calciteFocus/calciteBlur events.

[gpbmike]

Just leaving a note, I think this change should have been called out in the breaking changes section of the release notes.

I was using calciteInputFocus and calciteInputBlur. 😢

[jcfranco]

Those props were marked as internal and omitted from the doc for quite a while now, hence why we didn't mark them as breaking. On the other hand, I understand the need for these events and will look into this in upcoming sprints (see #4611 (comment)).

[gpbmike]

Those props were marked as internal and omitted from the doc for quite a while now

Fair enough. I'm working on upgrading from beta.43 to beta.86. Not sure if the internal tag was there before, if so apologies. Thanks.