-
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
[App Arch] [Cleanup] Saved object migrations from kibana plugin to new platform #64289
Conversation
context: SavedObjectMigrationContext | ||
) => SavedObjectUnsanitizedDoc; | ||
export type SavedObjectMigrationFn< | ||
TInputDoc extends SavedObjectUnsanitizedDoc | SavedObjectSanitizedDoc = SavedObjectUnsanitizedDoc, |
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 think we need to add two generics cause it allow us to avoid a lot of casting in future.
Like e.g. here: src/plugins/dashboard/server/saved_objects/dashboard_migrations.ts
Also using this approach we can guarantee that all Doc's extended from SavedObjectUnsanitizedDoc
or SavedObjectSanitizedDoc
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.
To follow our slack discussion:
This is an alternative of #63943
However on #63943 we choose to only generify the attributes
property of SavedObjectUnsanitizedDoc
, as we didn't see any (valid) reasons plugin migration functions should be able to superseed/override the root SO type. This could also be dangerous as it may cause developer errors trying to push changes/properties not defined in the schema.
Do you have any usages where you would need to use type override on the whole SavedObjectUnsanitizedDoc
type?
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.
At least in version 7.0.0 references
were added. And we should somehow handle it.
Also who knows what will be added in future?
From the other hand if someone wants to add something into doc we have at least 2 options: use JS without typings, just cast object to needed type =) So, validation should be implemented in a different way
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.
Currently there's an index signature so anything goes, but we should definitely remove that
[rootProp: string]: any; |
Root properties cannot be added by plugins, so if we ever add them in Core, we can update this type at the same time like we recently did for the new namespaces
root property.
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.
💚 Build SucceededTo update your PR or re-run it, just comment with: |
Pinging @elastic/kibana-app-arch (Team:AppArch) |
Summary
This PR fixed problem described in #59044 (comment)
Originally posted by @tylersmalley in #59044
Checklist
Delete any items that are not applicable to this PR.
For maintainers