-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[investigate] Copy changes from POC #187936
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
Pinging @elastic/obs-ux-management-team (Team:obs-ux-management) |
register: (callback) => { | ||
const registrationPromise = Promise.race([ | ||
callback(this.widgetRegistry.registerWidget), | ||
new Promise<void>((resolve, reject) => { | ||
setTimeout(() => { | ||
reject(new Error('Timed out running registration function')); | ||
}, 30000); | ||
}), | ||
]).catch((error) => { | ||
this.logger.error( | ||
new Error('Encountered an error during widget registration', { cause: error }) | ||
); | ||
return Promise.resolve(); | ||
}); | ||
|
||
this.registrationPromises.push(registrationPromise); | ||
}, | ||
}; |
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.
There is an opportunity here for a race condition: register
is asynchronous, but getWidgetDefinitions
is not. In practice you will probably never run into it, but it might become an issue for tests. You could consider making an Observable out of getWidgetDefinitions
but there are some implications for code downstream.
@@ -20,15 +20,17 @@ import type { | |||
export type { InvestigatePublicSetup, InvestigatePublicStart, OnWidgetAdd, WidgetRenderAPI }; | |||
|
|||
export { | |||
type InvestigateTimeline, | |||
type Investigation, |
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 am wondering why we export these types from both public and common folders? I was looking into the consumer side where it is imported from and in some places we import it from common '@kbn/investigate-plugin/common';
, where as in others from public '@kbn/investigate-plugin/public';
nit: Maybe we can keep only one place where we export/import from, unless there is a restriction I am not aware of.
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.
this is for other plugins to import it (without extra config, other plugins cannot import from /common
). the difference that you see might be based on type imports vs code imports.
export interface Investigation { | ||
id: string; | ||
'@timestamp': number; | ||
user: AuthenticatedUser; |
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.
Once we have the concept of more users participating in one investigation, do we consider having here an array of authenticated users? Or possibly we could have an extra field invitedUsers. This is definitely not part of version 1, but I am trying to think about what we might introduce in the future that could shape the Investigation interface.
defaultMessage: 'New investigation', | ||
}), | ||
revision: revisionId, | ||
revisions: [revision], |
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.
Do I understand correctly that we add to the revisions array only the latest revision? I thought we might want to have a list of all revisions. Do I miss something here?
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.
there is an Investigation, and an InvestigationRevision, the former contains the latter. (eg. investigation.revisions)
> { | ||
onWidgetAdd: (create: InvestigateWidgetCreate) => Promise<void>; | ||
blocks: { | ||
publish: (blocks: WorkflowBlock[]) => UnregisterBlocksFunction; |
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.
Just weird that a publish function returns an unregisterBlocksFunction.
Maybe not as part of this PR, but let's think more about WorkflowBlock interface and map it to the mock up designs.
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.
it's so you can use it in a useEffect hook
|
||
const InvestigateWidgetApiContext = createContext<UseInvestigateWidgetApi | undefined>(undefined); | ||
|
||
export const InvestigateWidgetApiContextProvider = InvestigateWidgetApiContext.Provider; |
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.
@dgieselaar Is this actually used anywhere? I was looking into the inital PR of how it is being used, but I didn't find any use of it, other than being exported here. If it is not being used, then we could remove it.
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.
it isn't, but I did discuss it with Kevin & Bena: I think context in this case is better than prop drilling, so I would use this API instead
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.
Look like investigate plugin changes were properly copied from the initial POC to this new PR. I just left a few clarification questions.
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Module Count
Public APIs missing comments
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
cc @kdelemme |
Summary
Copy
investigate/
plugin changes from #183293 into this PR.Will follow up with the new plugin
investigate_app/
Nothing to test here, it's just a public plugin exposing some hook and registry. Not used yet