-
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
[Fleet] Create a new UIExtensionPoint
to replace the integration define step
#149653
Conversation
7ca8ded
to
105a50e
Compare
105a50e
to
2499179
Compare
export type PackagePolicyReplaceDefineStepExtensionComponentProps = ( | ||
| (PackagePolicyEditExtensionComponentProps & { isEditPage: true }) | ||
| (PackagePolicyCreateExtensionComponentProps & { isEditPage: false }) | ||
) & { | ||
validationResults?: PackagePolicyValidationResults; | ||
agentPolicy?: AgentPolicy; | ||
packageInfo: PackageInfo; | ||
integrationInfo?: RegistryPolicyTemplate; | ||
}; |
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.
since this extension replaces the first step entirely, and it slightly differs between edit
and create
, i've used the same props from the relevant existing extension points.
the added props are from the actual props StepDefinePackagePolicy
receives, so any functionality it does inside an be replicated.
if (replaceDefineStepView && extensionView) { | ||
// eslint-disable-next-line no-console | ||
console.warn( | ||
"'package-policy-create' is ignored when 'package-policy-replace-define-step' is defined" | ||
); | ||
} |
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.
not sure logging here is good enough, we could add useUIExtensions
which would be typed to not allow this combination
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 I think useUIExtensions
or adding an overload to useUIExtension
that takes an array of extensions would be the path forward here. Agree that logging is not enough to prevent this, as we should prevent it entirely at compile time.
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.
thought about this again and i believe we shouldn't overload useUIExtension
, because:
- registration is not really constrained, so we could narrow the types but that won't make them true
- we can't fully limit registration with static types, as it can be done multiple times.
- we can make
registerExtension
take an array and type-check against invalid combinations, and run a full sweep on other plugins, which would somewhat mitigate possible future risk of misuse
- there is actually not much to do with that information. we still need to account for both cases, and when doing those we don't need the other extension anyway. after making the types work, i noticed the distinction wasn't really used
- overloading wasn't pretty
let me know what you think is best here/follow ups:
- add/iterate on overloading commit
- just drop/keep the comments
- work on
registerExtension
- something else?
thanks!
also note i'd still want to merge #149137 as soon as we can because there are other PRs depending on 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.
Following up on our chat offline:
Let's just throw
an error when we encounter this case. This should result in the Fleet UI's error boundary being displayed and should catch the "incompatible UI extension" state during development. I don't want to silently ignore a UI extension with a browser console log/warning because it will be non-obvious to someone developing in this situation.
if (replaceDefineStepView && extensionView) {
throw new Error(
"'package-policy-create' and 'package-policy-replace-define-step' cannot both be registered as UI extensions"
)
}
Thanks for investigating here and following up.
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.
added this with some test updates that were needed
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.
No real issues for me on this - think things look pretty standard alongside the other UI extensions. The only wrinkle is the exclusivity between package-policy-create
and package-policy-replace-define-step
which I think we should solve via TypeScript assertions as you've suggested.
Once that's addressed I'd be more than happy to +1 this and ship. Awesome work! 🚀
if (replaceDefineStepView && extensionView) { | ||
// eslint-disable-next-line no-console | ||
console.warn( | ||
"'package-policy-create' is ignored when 'package-policy-replace-define-step' is defined" | ||
); | ||
} |
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 I think useUIExtensions
or adding an overload to useUIExtension
that takes an array of extensions would be the path forward here. Agree that logging is not enough to prevent this, as we should prevent it entirely at compile time.
Pinging @elastic/fleet (Team:Fleet) |
if (replaceDefineStepView && extensionView) { | ||
// eslint-disable-next-line no-console | ||
console.warn( | ||
"'package-policy-create' is ignored when 'package-policy-replace-define-step' is defined" | ||
); | ||
} |
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.
Following up on our chat offline:
Let's just throw
an error when we encounter this case. This should result in the Fleet UI's error boundary being displayed and should catch the "incompatible UI extension" state during development. I don't want to silently ignore a UI extension with a browser console log/warning because it will be non-obvious to someone developing in this situation.
if (replaceDefineStepView && extensionView) {
throw new Error(
"'package-policy-create' and 'package-policy-replace-define-step' cannot both be registered as UI extensions"
)
}
Thanks for investigating here and following up.
💚 Build Succeeded
Metrics [docs]Async chunks
Public APIs missing exports
History
To update your PR or re-run it, just comment with: |
Summary
adds a new extension point to replace a package installation first step entirely.
Checklist
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers