ionic-team / ionic-framework

A powerful cross-platform UI toolkit for building native-quality iOS, Android, and Progressive Web Apps with HTML, CSS, and JavaScript.
https://ionicframework.com
MIT License
50.93k stars 13.51k forks source link

bug: range ionInput event behavior inconsistent with documentation #29619

Open bodinaren opened 3 months ago

bodinaren commented 3 months ago

Prerequisites

Ionic Framework Version

v7.x, v8.x

Current Behavior

The onIonInput event behavior isn't consistent with the documentation for the event. This is the current description:

The ionInput event is fired for <ion-range> elements when the value is modified. Unlike ionChange, ionInput is fired continuously while the user is dragging the knob.

The actual behavior is that the event is triggered whenever the knob is moved a single pixel (after an initial "sticky" behavior) instead of it triggering whenever the actual value is modified, causing a lot of events being triggered for absolutely no reason. The second part "is fired continously" is ambivalent and could match either expectation.

Expected Behavior

I would expect the event to trigger only when the value is modified rather than when the knob is moved.

Steps to Reproduce

  1. Open the reproduction Stackblitz link.
  2. Open the browsers developer console.
  3. Drag the slider a short distance until the first ionInput event is triggered, then keep moving the knob a short distance and see how the event continues to be logged even without the value changing.

Code Reproduction URL

https://stackblitz.com/edit/umlmf6?file=src%2Fmain.tsx

Ionic Info

Ionic:

Ionic CLI : 7.2.0.

Utility:

cordova-res : not installed globally native-run : not installed globally

System:

NodeJS : v20.9.0 npm : 10.1.0 OS : Windows 10 (actual version 11)

Additional Information

As I see it there's 3 possible solutions:

  1. Only trigger the event when the value has changed from it's previous value as the documentation says.
  2. Same as 1 but only when snaps: true.
  3. Update the documentation to not specify when the value is modified but rather something like when the knob is moved.

I believe 1 is the preferable solution, but it might be considered a breaking change and so 2 is a reasonable compromise as there's no practical nor visual updates between value-changes when snaps: true making it a non-breaking change.

3 is by far the least preferable solution in my opinion as this issue is not only a documentation error but the current implementation also carries an unnecessary performance impact (again, at least when snaps: true).

brandyscarney commented 3 weeks ago

Thank you for the issue! I agree that the best solution would be to match the behavior of native input ranges and only emit the event when the value changes from the previous one. I’ve marked this as a bug, which adds it to our internal issue tracker for further work.