feat(textarea): ionChange will only emit from user committed changes

[sean-perkins]

Pull request checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
  • Some docs updates need to be made in the ionic-docs repo, in a separate PR. See the contributing guide for details.
• Build (npm run build) was run locally and any changes were pushed
• Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

Textarea emits ionChange each time the value is modified internally (e.g. user typing) or externally (e.g. value being set programmatically).

Issue URL: Internal

What is the new behavior?

• ionChange is only emitted when the inner textarea change event is fired.
• debounce applies to the ionInput event instead of ionChange

Does this introduce a breaking change?

• Yes
• No

Other information

[amandaejohnston]

How come? Wouldn't we just get rid of the TextValueAccessorDirective class/directive altogether and be done?

[sean-perkins]

Removing TextValueAccessorDirective would introduce a breaking change to the Angular package, which we don't need to make. The "new" value accessor only exists in the span of migrating the controls to using ionInput instead of ionChange, then it can assume the existing name.

[liamdebeasi]

Given <ion-textarea clear-on-edit="true" value="123"></ion-textarea>, ionChange does not emit when pressing backspace (After blurring).

ionInput does not fire either, but that seems to be the correct behavior since Ionic is clearing the input, not the user. The current textarea does this too. (might be worth mentioning in the docs) Should ionInput fire because the user pressed backspace?

[sean-perkins]

@liamdebeasi couple of call outs from the last changes + feedback to your questions.

Given <ion-textarea clear-on-edit="true" value="123"></ion-textarea>, ionChange does not emit when pressing backspace (After blurring).

This has been fixed. This appears to be a bug in the clearOnEdit implementation. It does not clear the textarea if the element has an initial value, unless it is focused, blurred, focused and then modified. I have modified this to clear on edit when the control has a value.

Should ionInput fire because the user pressed backspace?

I do not believe so. We aren't stopping event propagation here. The default behavior with a textarea without a value, when pressing backspace, is to not emit an input event: https://codepen.io/sean-perkins-ionic/pen/gOzxGGQ. With the input value being cleared on edit, we would have to manually emit an ionInput event.

---

Other misc call outs:

• clearOnEdit was mutable, even though its value was never internally modified (removed the mutable flag)
• Property documentation kept referring to type being specified, but it has no effect on the ion-textarea implementation - removed this incorrect documentation.

[liamdebeasi]

Great job!