jobTypeChanged was removed here because it caused extra renders of the component that prevented the includedFields table on the Regression job page not to be automatically populated when dependentVariable was selected. This occurred because this condition was detecting a job change when there wasn't one.

Instead of _SingleRangeChangeEvent, would it be possible to use EuiRangeProps['onChange'], like in https://github.com/elastic/kibana/blob/56e45b19c57371599ca0e164bfec1b417f1aa91a/x-pack/plugins/maps/public/classes/sources/es_geo_grid_source/resolution_editor.tsx?

Unfortunately not because of the syntax used. onSigmaChange is using function onSigmaChange() {} as opposed to const onSigmaChange = () => {}, and cannot be typed to a function type (EuiRangeProps['onChange']) the same way as consts can (at least, I couldn't find a way to accomplish this in my google journeys - I'd love to be wrong on this, please tell me if you know of a way to do so!)

I also attempted to use Parameters<EuiRangeProps['onChange']>[0] but unfortunately Typescript couldn't figure that out - I think possibly due to some bizarre combination of reaching into an interface for a key and that key being optional/potentially undefined.

Importing the event type directly was the easiest way I could figure out to update typings without changing your source code, but if you're okay with changing your syntax - sure, we can make that change :)

Tested this by getting the range slider control into a no-data state, and it looks the same as it did before. 👌

Is there anything we can do on our side to get rid of these complex types? Maybe a forward ref? Or some other way of getting a handle on the class?

Honestly? Without knowing exactly why you're calling the internal EuiDualRange's internal onResize class method... my recommendation is to not do that 😅 (which removes the need for the ref entirely, and thus the ref typing shenanigans).

If we ever convert EuiRange/EuiDualRange to functional non-class components as a tech debt item, you'd lose access to this API entirely (it's not something we're deliberately exposing or documenting as a consumer API). I did create a regression test to ensure we continued exposing onResize via ref, just for this specific Kibana usage of it, but honestly, we'd prefer y'all not reach for it at all, or figure out what problem it's solving and have us try to solve it in a less technically hacky way.

I don't have the context as to why that original call was added or what it's doing - but it's definitely a code smell that makes me think either this usage of it is trying to do things EuiDualRange is not meant to do, or is super custom and undoing things EuiDualRange does and then re-doing them later (also not great).

If I remember correctly, this usage is due to us not being able to use EuiInputPopover, but still wanting to have the popover to be tied to the width of the input. I can't exactly remember why we couldn't use EuiInputPopover though.

I wonder if we would run into any regressions by removing that call entirely? @cqliu1, do you remember why we had to use EuiPopover?

What exactly changed here requiring the addition of the KeyboardEvent type?

A slightly younger and far more naive version of me was looking at the EuiRange types and was like, "keyboard users / keyboard events on the input are also a thing! Let me modify our event types to add that, surely there won't be that many Kibana usages for us to update, right?"

Narrator: There were that many Kibana usages.

So yeah, that change is squarely my fault. The type change didn't really have to happen and was just me going "hm this is probably nice to have" and not realizing it would affect so many downstream Kibana consumers 😭 On the plus side, 6f1dfd2 dried out statically copied types for multiple instances/usages, so for most cases (except this one, where I couldn't extend EuiRangeProps['onChange'] for whatever arcane Typescript reason - see an earlier comment about Parameters<>), this was generally a very small net cleanup.