eui icon indicating copy to clipboard operation
eui copied to clipboard

[EuiDualRange] Should only fire change events when user lets go of endpoint

Open thomasneirynck opened this issue 4 years ago • 6 comments

Raised here https://github.com/elastic/kibana/pull/99661

The EuiDualRange component fires change-events, while the user is still holding on to the end-points. This causes unnecessary updates.

thomasneirynck avatar May 18 '21 18:05 thomasneirynck

Hey! I understand that this is coming from the timeslider work and am wondering if a throttle or debounce would resolve your concern?

Some background: The dual range slider was intended to be as close to a native <input type=range> form element as possible. In fact, EuiDualRange slider is underpinned by a single <input type=range> and all events defer to native behavior with a few exceptions. So the click+move/drag behavior is that of the native element, as well as the subsequent rate of update eventing. And again, these were intentional choices because we see the component as an extension of an HTML form element.

thompsongl avatar May 19 '21 16:05 thompsongl

hi @thompsongl - we actually already debounce (https://github.com/elastic/kibana/pull/99661/files#diff-4cbfb50b9310d9acca14cead304178d2512cffa3952bce338c2269754c57b3c3R115) but the effect remains the same: we get intermediate updates.

Maybe I should rephrase: onchange does not necessarily have to change as-is, but it is it possible

  • introduce a new event, with this new behavior?
  • add argument to the onchange event-handler with additional info (e.g. whether mouse/touch is down), ...?

thomasneirynck avatar May 19 '21 16:05 thomasneirynck

Thanks for clarifying. I think it would make the most sense to add an onMouseUp/onDragEnd callback prop that fires after the interaction is complete. Note that onChange would still be required and would still update at the same rate; EuiDualRange relies on the value -> onChange -> value update cycle to perform thumb movement.

thompsongl avatar May 24 '21 17:05 thompsongl

@thompsongl thanks for the feedback! yes, I think a new event would work great for the timeslider use-case (e.g. onDragEnd).

As for the onChange still being a required-event, I think that is perfectly fine.

thomasneirynck avatar May 24 '21 18:05 thomasneirynck

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

github-actions[bot] avatar Dec 07 '21 00:12 github-actions[bot]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

github-actions[bot] avatar Jun 05 '22 16:06 github-actions[bot]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

github-actions[bot] avatar Dec 03 '22 16:12 github-actions[bot]

❌ We're automatically closing this issue due to lack of activity. Please comment if you feel this was done in error.

github-actions[bot] avatar Dec 10 '22 16:12 github-actions[bot]