feat(simple-combo/combo): add selectionChanged event

[georgianastasov]

Closes #16655

Additional information (check all that apply):

• Bug fix
• New functionality
• Documentation
• Demos
• CI/CD

Checklist:

• All relevant tags have been applied to this PR
• This PR includes unit tests covering all the new code (test guidelines)
• This PR includes API docs for newly added methods/properties (api docs guidelines)
• This PR includes feature/README.MD updates for the feature docs
• This PR includes general feature table updates in the root README.MD
• This PR includes CHANGELOG.MD updates for newly added functionality
• This PR contains breaking changes
• This PR includes ng update migrations for the breaking changes (migrations guidelines)
• This PR includes behavioral changes and the feature specification has been updated with them

[Copilot]

Pull request overview

Adds a new selectionChanged output to IgxSimpleComboComponent so consumers can react after a selection has been applied (as requested in #16655).

Changes:

• Introduces ISimpleComboSelectionChangedEventArgs and a new selectionChanged @Output().
• Emits selectionChanged after applying selection updates inside setSelection(...).
• Adds unit tests for selectionChanged behavior and documents the feature in CHANGELOG.md.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
projects/igniteui-angular/simple-combo/src/simple-combo/simple-combo.component.ts	Adds selectionChanged API and emits it after selection is applied.
projects/igniteui-angular/simple-combo/src/simple-combo/simple-combo.component.spec.ts	Adds unit tests for the new selectionChanged event.
CHANGELOG.md	Notes the new selectionChanged event under IgxSimpleCombo.

[wnvko]

Also, it will be great if we can add same event and to the igxComponent.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 7 comments.

---

You can also share your feedback on Copilot code review. Take the survey.

[wnvko]

One general question here. Do we have specification for this event? What should this new event do?
The workflow now is like this:

• end user makes new selection
• selection changing is emitted.
• developer may handle changing event. At this point event could be canceled and nothing will happen. However, event arguments could be changed including old selection, new selection and so on.
• if event is not cancelled selection should be changed base on the update values of event arguments.
• event changed should fire. I am not sure this event should be skipped but it is now in some cases. IMO if changing fired then and changed should fire. What values should be put in event argument should be described the specification. For example we may have at first place selection made by end user, then selection updated in changing event and finally selection actually applied to the component after some validation. Which of these three is the new selection changed event should fire with?
  Without specification this feature cannot be done!

[georgianastasov]

One general question here. Do we have specification for this event? What should this new event do? The workflow now is like this:

• end user makes new selection
• selection changing is emitted.
• developer may handle changing event. At this point event could be canceled and nothing will happen. However, event arguments could be changed including old selection, new selection and so on.
• if event is not cancelled selection should be changed base on the update values of event arguments.
• event changed should fire. I am not sure this event should be skipped but it is now in some cases. IMO if changing fired then and changed should fire. What values should be put in event argument should be described the specification. For example we may have at first place selection made by end user, then selection updated in changing event and finally selection actually applied to the component after some validation. Which of these three is the new selection changed event should fire with?
  Without specification this feature cannot be done!

We don't have a specification and exact requirements for what the new event should do. When I initially picked this up, it was just a small requested feature for the simple combo, so I started working on it while waiting for review and clarification. However, now that we are looking at adding these events for both the simple and the combo components, plus handling cancelability, the scope has definitely expanded. You are completely right we absolutely cannot proceed without a clear specification for this!

[wnvko]

Update also the README.md files for both combos.

[wnvko]

no need of this check. If shouldEmitSelectionEvents is false we will never end up here.

[georgianastasov]

This check is actually needed because shouldEmitSelectionEvents is false when newSelection === oldSelection then selectionChanging.emit(args) is skipped, but args.cancel stays false so we still enter if (!args.cancel) then.. _onChangeCallback(this.value) still runs and without the inner check, selectionChanged would fire even though selection did not actually change.. So shouldEmitSelectionEvents === false does not mean we never reach this block.. but it means we should not emit the selection change events. I tested this, and when I remove the check, selectionChanged is fired even when the selection stays the same.