Input+Backspace event for TextField

[Mwni]

This is a proposal for an additional event on TextFields and editable TextViews that triggers both on text change and on backspace even when the field is empty. This new hybrid event could co-exist with the existing textChange event, or replace it.

The name of the event is to be determined. Existing proposals are:

Event Name	Pro	Con
input	simple & familiar	Browser input events do not fire on backspace when empty
keyDown	familiar	Missing keyUp event; Does not fire on arrow keys as expected
key	simple	Not very descriptive
deleteTap	descriptive	Introduces an extra event just for this one edge case

The fourth option, proposed by @NathanWalker, is to add a modifier to the existing textChange to not break existing code. E.g.:

<TextField (textChange)="handle($event)" [backspaceEnabled]="true" ...

By the way, a functional patch that implements the deleteTap event is available at https://gist.github.com/Mwni/4ee9c71199f12c599c0848d52881e7fa

[NathanWalker]

I guess the main con for using the existing textChange would be that it could be considered a breaking change if some app developers had specific logic wired to textChange currently which would cause unexpected app behavior when fired on backspace (even when empty).

[mahmoudajawad]

Agree. I would like to have this feature, but without breaking current logic implemented as workaround for the intended use-case of the suggested feature.

[NathanWalker]

I was thinking another options would be to provide a flag on the event emitted from textChange or a binding alongside it, eg:

<TextField (textChange)="handle($event)" [backspaceEnabled]="true" ...

But I also like your suggestion of new input event and just implement it exactly to web spec:
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/input_event

[Mwni]

Well, the thing is, if the input event was to be implemented exactly to web spec, it wouldn't fire on backspace when empty. I actually like the backspaceEnabled modifier the most.

[Sarfaraaz]

I'd prefer to have a separate event that behaves in a more predictable manner for apps rather than try to add a flag to an existing one which was intended for a different use case (and is named as such). Adding that flag pretty much invalidates the textChange event. Pressing backspace (or whatever key, which is the preferred solution), doesn't necessarily mean a textChange.

As this is a very trivial feature that is surprisingly not already exposed in NativeScript, I'd love to see an implementation that makes things more predictable and allows for whatever use case within this constraint to be serviced.

How about an event that gets triggered on both keyUp and keyDown. It's easy for the developer to then filter out the exact eventName they'd like to hook into and call whatever function(s) they want for them. Similar to how the touch event is behaving right now. Of course you can also add explicit events for both keyUp and keyDown, but IMO that's not necessary.

[mahmoudajawad]

I like this approach. This preserves expected behaviour for someone with web-background, while making sure it doesn't break current apps.