[vis/resizeChecker] swap out implemenation with ResizeObserver polyfill

[spalger]

Discovered the ResizeObserver spec and found a polyfill for it that is far faster than the polling done by the previous implementation

[spalger]

jenkins, test this

[ppisljar]

tests are failing, but it looks its not related to this PR ( broken master ? ):

FAIL: chrome on any platform - kibana - console app - console app - should show the default request (40675ms) expected
'GET _search\n  {\n    "query": { "match_all": {} }\n  }' to equal
'GET _search\n{\n  "query": {\n    "match_all": {}\n  }\n}'

[ppisljar]

funtionally everything seems to work fine

[spalger]

tests are failing, but it looks its not related to this PR

The console actually also uses the resize checker, so I moved it out of the vislib and updated the resize checker to support jQuery elements again to fix compatibility.

[ppisljar]

jenkins, test this

[ppisljar]

what do you think about moving this under ui/vis/components making it clear that its a component visualizations (even 3rd party) should use? (take a look at #9441 )

this way a visualization could then just
import {Tooltip, ResizeChecker, Colors} from 'ui/vis/components'

[spalger]

I don't feel strongly either way but the resize checker:

• exports a provider so it would be:

  import {Tooltip, ResizeCheckerProvider, Colors} from 'ui/vis/components'

• is not only used by visualizations, so console would be importing from ui/vis/components

• is not a visual component, which seems to conflict with the definition of "components" I'm most familiar with.

[ppisljar]

LGTM

[Bargs]

Could this trigger costly layout calculations? Why not use the values provided to the callback? http://rawgit.com/WICG/ResizeObserver/master/index.html#resizeobserverentry

[spalger]

I'm not sure, can it? I went this route because we need to calculate the size in modifySizeWithoutTriggeringResize() in order to correctly ignore subsequent resize events, and I didn't want to try to replicate the behavior necessary to calculate the width/height provided by the clientRect (see que-etc/resize-observer-polyfill#4)

[spalger]

Also, it's only called when we are trying to ignore a resize event (on load and in modifySizeWithoutTriggeringResize()) so I don't think it will be too costly.

[Bargs]

Ah, I was thinking it ran on every resize event. Maybe it's not too bad then. It looks like clientWidth and clientHeight do force layout. Not sure how else to implement this resize ignoring method though. Maybe it would be worth adding a comment on modifySizeWithoutTriggeringResize saying "This method can trigger forced layouts, use with caution"?

I think this is a great PR btw! The forced layout thing just jumped out at me because I've been dealing with the same problem elsewhere in the code.

[spalger]

👍 sounds good

[stacey-gammon]

Any reason this wasn't backported?

[spalger]

Perhaps just the size and lack of need, is there a reason we should?