Clean up or at least document slider events for ease of (advanced) use

[rreusser]

@alexcjohnson and I stumbled upon a nasty little subtlety in advanced usage of slider events. There are two types of sliderchange events:

1. an event caused by direct user input (dragging the slider)
2. an event caused by a detected change (play button changes the frame the slider controls)

There's an obscure little flag (eventData.interaction) that denotes whether the source was an interaction or not and it's critical to use this to distinguish what caused the event if you're hooking into the events directly instead of using the builtin API… API. If you don't, you get infinite loops because a frame change triggers a frame change.

This should be very clearly documented or maybe (tbh probably not) the event could be split into two so that it's actually difficult to make this error which right now, by default, causes infinite loops and is very tricky to catch if you didn't… ahem… write the slider code in the first place.

[rreusser]

Or maybe the eventData flag should be {eventSource: 'internal' | 'interaction'} instead.

[gvwilson]

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson