-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeScriptify visualize loader #21025
Conversation
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
Jenkins, test this |
💔 Build Failed |
💔 Build Failed |
i think the failiure is relevant, but just to be sure: jenkins, test this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quite a challenging undertaking, but aside from a few suggestions below it looks quite good to me.
@@ -17,8 +17,13 @@ | |||
* under the License. | |||
*/ | |||
|
|||
interface IInjector { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you considered using auto.IInjectorService
from https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a2a659c351b611398fd2f3f577fd545dab335306/types/angular/index.d.ts#L132 instead? The @types/angular
package is already a dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The auto
namespace is not exported, so unfortunately we can't use that typing (I have no idea why the typing doesn't export that type, since it's a legit service to inject).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point
const handler = loader.embedVisualizationWithSavedObject(newContainer()[0], createSavedObject(), { | ||
timeRange: { from: 'now-7d', to: 'now' } | ||
}); | ||
|
||
// Wait for the initial fetch and render to happen | ||
await timeout(150); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sure there is a reason for using these timeouts here, but I can't not comment on it. It looks like a flaky test in the making. 😉 Is there no way to synchronously force the "fetch and render to happen"? Maybe the time mocking functionality of sinon can be of use?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately we currently cannot (I think I left a comment in the timeout below), since we use a too old lodash
version. Basically we need to wait for the debounce
to happen. Lodash prior 4, does not properly work together with jest or sinon fake timers, so that's the most reasonable way to trigger it imho. Also since we don't wait for something "arbitrary long" I don't think that will ever introduce flakyness, but we just need the debounce to be triggered. As soon as we update to lodash 4, we can use sinon.useFakeTimers()
instead to make this sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you know that the debounce has always happened after 150ms? That looks suspiciously arbitrary. 😇 waiting for the "next tick" like in the prior test cases is not sufficient?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately that's not enough, since in that case we actually need to wait for the debounce to be done, while the above doesn't care about that. After an update to lodash 4 that might be better, since we don't need to give it an arbitrary number here anymore, but can "flush" all pending debounce operations.
*/ | ||
import { isEqual } from 'lodash'; | ||
|
||
// @ts-ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about adding stub .d.ts
files with any
exports for these registries and similar imports in this file to avoid masking other problems with blanket @ts-ignore
s?
queryFilter: QueryFilter; | ||
} | ||
|
||
export type RequestHandler = (vis: Vis, params: RequestHandlerParams) => any; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be helpful to add a generic type argument for the return value?
private previousRequestHandlerResponse: any; | ||
|
||
constructor(private readonly vis: Vis, Private: IPrivate) { | ||
const { requestHandler, responseHandler } = vis.type; |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
*/ | ||
|
||
import chrome from '../../chrome'; | ||
// @ts-ignore implicit-any |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about adding that export to the type in the corresponding query_filter.d.ts
?
Adressed all issues and merged master to include #20863 |
💚 Build Succeeded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, tested on chrome linux
💔 Build Failed |
Jenkins, test this |
💚 Build Succeeded |
* TypeScriptify Vis loaders * Fix issue with undefined timeRange * Fix chrome typing * Fix unit tests * Fix this issue * Add missing uiState to request handler * Implement Felix's suggestions * Add timefilter listener
How do we test this PR @timroes? Thanks! |
@bhavyarm Ideally this PR should not have changed any functionality, so it cannot be tested from a functional point. But all visualizations (everywhere) should still work. |
This PR also refactores and improves a couple of minor issues:
visualizeLoader
tovisualizeLoader.render
VisualizeLoader
timeRange
is set before applying it as a filter.fetchAndRender
multiple times we now force a fetch as long as a single one of those calls was aforceFetch
call. Previously we always used the parameter passed to the last call before debounce was triggered.timeRange
in date_histogram if it isn'tundefined
.