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 |
weltenwort
left a comment
There was a problem hiding this comment.
Quite a challenging undertaking, but aside from a few suggestions below it looks quite good to me.
| * under the License. | ||
| */ | ||
|
|
||
| interface IInjector { |
There was a problem hiding this comment.
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.
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).
| }); | ||
|
|
||
| // Wait for the initial fetch and render to happen | ||
| await timeout(150); |
There was a problem hiding this comment.
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.
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.
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.
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.
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-ignores?
| queryFilter: QueryFilter; | ||
| } | ||
|
|
||
| export type RequestHandler = (vis: Vis, params: RequestHandlerParams) => any; |
There was a problem hiding this comment.
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.
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 |
ppisljar
left a comment
There was a problem hiding this comment.
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:
visualizeLoadertovisualizeLoader.renderVisualizeLoadertimeRangeis set before applying it as a filter.fetchAndRendermultiple times we now force a fetch as long as a single one of those calls was aforceFetchcall. Previously we always used the parameter passed to the last call before debounce was triggered.timeRangein date_histogram if it isn'tundefined.