Bug: Expander Events Naming

I noticed that expander has two events: Expanding and Collapsed that are named differently.

https://github.com/microsoft/microsoft-ui-xaml/blob/4208a01f744690329f6cd326e722d9c78e2358e8/dev/Expander/Expander.idl#L30-L31

Expanding implies the event is fired before the control is expanded and Collapsed implies after. Therefore, a difference in naming here concerned me so I went to check the code. Sure enough, there seems to be a mismatch. According to the code below all events are fired BEFORE the is expanded state is applied meaning both events should be named with a ‘ing’ suffix. Is my understanding correct here? If so this is actually a bug.

https://github.com/microsoft/microsoft-ui-xaml/blob/4208a01f744690329f6cd326e722d9c78e2358e8/dev/Expander/Expander.cpp#L104-L115

The differences in naming is actually quite important as in the future four events should be added to cancel expanding/collapsing. https://github.com/microsoft/microsoft-ui-xaml/issues/3279#issuecomment-752845151. There should be four total events in the end:

1. Expanding <- Can cancel
2. Expanded
3. Collapsing <- Can cancel
4. Collapsed

[StephenLPeters]

Microsoft should not artificially constrain what controls can do just because they can’t imagine what may be possible. I like to leave what is possible and what makes sense for their unique use cases up to app developers and their design teams.

The problem is that API’s have costs, not only in terms of not only implementing, maintaining, and documenting, but also package size as well as a tiny bit of performance, additionally every added api makes the process of a developer learning the proper way to use a control a little bit harder. So we don’t want to add APIs that could go unused, luckily we are developing in the open and can see hugely valuable feedback, like the expanding and collapsing events which you’ve outlined above, that will point out our mistakes and let us update our controls to best serve the community 😃

[robloo]

@StephenLPeters

I think we should even wait until the storyboard has concluded to raise the event?

That’s certainly the most correct solution. However, it was a larger tear-up than I wanted to do so decided against it. Not only are you connecting and managing event handlers to the four storyboards (more template parts and boilerplate), but the Collapsed event would easily not get fired if the control was re-templated without the specific storyboard named template part. I’m not sure any other controls have such an error-prone restriction that could cause a fundamental event not to fire? (I don’t follow the code that closely to know. I also avoid C++/WinRT whenever possible.)

Also don’t forget AutomationPeer should be updated at the same time we raise the event; however, the AutomationPeer is currently handled inside UpdateExpandState().

https://github.com/microsoft/microsoft-ui-xaml/blob/4208a01f744690329f6cd326e722d9c78e2358e8/dev/Expander/Expander.cpp#L164-L172