-
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
[Response Ops][Rule Form V2] Rule Form V2: Rule Definition #183325
Conversation
Pinging @elastic/response-ops (Team:ResponseOps) |
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.
Thank you for this! Based on the talk we had offline some of my comments are not relevant any more 🙂. Please let me know when that's the case. I know that a lot of code was there from before and we moved things around. Now that we rewrite the rule form I think it is a good opportunity to enhance the types and the code when possible. Please let me know if the work of doing it is too much and is outside the scope of this PR. Also I noticed that most of components are not memoized (React.memo(MyComponent)). What do you think about that? Finally, what is the effort (not on this PR) of not exporting the types from:

packages/kbn-alerts-ui-shared/src/rule_form/rule_definition/rule_definition.tsx
Outdated
Show resolved
Hide resolved
<RuleSchedule | ||
interval={'30s'} | ||
minimumScheduleInterval={{ | ||
enforce: true, |
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.
Is it possible for a minimumScheduleInterval
to not be enforced?
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.
Yes
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.
And what exactly mean if it is not enforced?
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.
Then it means you can have any interval
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 we have any test for that?
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 will come in a future PR, since nothing is enforcing this right now
packages/kbn-alerts-ui-shared/src/rule_form/rule_definition/rule_schedule.tsx
Outdated
Show resolved
Hide resolved
packages/kbn-alerts-ui-shared/src/rule_form/rule_definition/rule_schedule.tsx
Outdated
Show resolved
Hide resolved
packages/kbn-alerts-ui-shared/src/rule_form/rule_definition/rule_schedule.tsx
Show resolved
Hide resolved
isInvalid={errors.alertDelay?.length > 0} | ||
append={ALERT_DELAY_TITLE_SUFFIX} | ||
onChange={onAlertDelayChange} | ||
onKeyDown={onKeyDown} |
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.
The logic with the onKeyDown
and the regex validation is the same between the RuleAlertDelay
and RuleSchedule
. What about creating a new component called NumbericInput
or similar that will have the common logic and the RuleAlertDelay
and RuleSchedule
components will use?
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 the similarities between the 2 components is not worth abstracting out. I don't think we have another input that will use this ATM. My usual guideline is if something is repeated 3 times then I will abstract it out.
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.
Code LTGTM! I left some comments and questions on existing threads. I am wondering if we should merge on a feature branch instead of main? The reason is that it will help me in the end to see the whole picture of the architecture of the components, test it holistically, be able to add comments, and fix bugs if we find any.
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.
As we discussed offline we will merge on main as the feature is behind a feature flag.
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
References to deprecated APIs
History
To update your PR or re-run it, just comment with: |
## Summary Issue: #179105 Related PR: #180539 Part 1: #183325 Part 2 of 3 PRs of new rule form. This PR depends on the code from part 1, so only merge this when part 1 has been merged. This PR extracts the last section of the rule form, the rule details, from the original PR. The design philosophy in the PR is to create components that are devoid of any fetching or form logic. These are simply dumb components. I have also created a example plugin to demonstrate this PR. To access: 1. Run the branch with yarn start --run-examples 2. Navigate to http://localhost:5601/app/triggersActionsUiExample/rule_details And you should be able to play around with the components in this PR: <img width="1281" alt="Screenshot 2024-05-13 at 9 44 14 PM" src="https://github.com/elastic/kibana/assets/74562234/7ca900e3-ca9a-4810-8b24-7c3ea41055d6"> ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Zacqary <zacqary.xeper@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Summary
Issue: #179105
Related PR: #180539
Part 1 of 3 PRs of new rule form. This PR extracts the first section of the rule form, the rule definition, from the original PR. The purpose is to fix a few bugs (Such as improving the alert delay and the rule schedule input validation), and also try to make the PR much smaller for review. The design philosophy in the PR is to create components that are devoid of any fetching or form logic. These are simply dumb components.
I have also created a example plugin to demonstrate this PR. To access:
yarn start --run-examples
http://localhost:5601/app/triggersActionsUiExample/rule_definition
And you should be able to play around with the components in this PR:
Checklist