-
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
[Automatic Import] Prepare to support more connectors #191278
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
/* | ||
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
* or more contributor license agreements. Licensed under the Elastic License | ||
* 2.0; you may not use this file except in compliance with the Elastic License | ||
* 2.0. | ||
*/ | ||
|
||
import type { IScopedClusterClient } from '@kbn/core-elasticsearch-server'; | ||
import type { CategorizationState, ChatModels } from '../../types'; | ||
|
||
export interface CategorizationBaseNodeParams { | ||
state: CategorizationState; | ||
} | ||
|
||
export interface CategorizationNodeParams extends CategorizationBaseNodeParams { | ||
model: ChatModels; | ||
} | ||
|
||
export interface CategorizationGraphParams { | ||
model: ChatModels; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As long as we do not want to separate graph compilation parameters we could reuse that yes, I don't have a strong opinion on this one. |
||
client: IScopedClusterClient; | ||
} |
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.
Can we not do it other way? Like
And reuse
BaseNodeParams
in all graphsThere 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.
We could yeah, however the issue with abstraction is that you would leave it very hard to perform changes on just one graph that might be model related etc.
At that point we start making a type that extends BaseNodeParams only for that graph, and later another one might appear etc.
I don't mind moving BaseNodeParams up to /server/types.ts, and reuse it for all the graphs, but we should be careful to not push the abstractions too wide, as it always makes changes later messier.
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.
Yeah... Just seen that state is being used alone and not model... So no point abstracting model.
Probably we leave it this way to be consistent and not make it complex