Skip to content
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

Merged
merged 8 commits into from
May 31, 2024

Conversation

JiaweiWu
Copy link
Contributor

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:

  1. Run the branch with yarn start --run-examples
  2. Navigate to http://localhost:5601/app/triggersActionsUiExample/rule_definition

And you should be able to play around with the components in this PR:

Screenshot 2024-05-13 at 10 10 51 AM

Checklist

@JiaweiWu JiaweiWu added release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.15.0 labels May 13, 2024
@JiaweiWu JiaweiWu requested a review from a team as a code owner May 13, 2024 17:16
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

Copy link
Member

@cnasikas cnasikas left a 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:

Screenshot 2024-05-15 at 3 09 28 PM

<RuleSchedule
interval={'30s'}
minimumScheduleInterval={{
enforce: true,
Copy link
Member

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Member

@cnasikas cnasikas May 22, 2024

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?

Copy link
Contributor Author

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

Copy link
Member

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?

Copy link
Contributor Author

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

isInvalid={errors.alertDelay?.length > 0}
append={ALERT_DELAY_TITLE_SUFFIX}
onChange={onAlertDelayChange}
onKeyDown={onKeyDown}
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

@cnasikas cnasikas left a 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.

Copy link
Member

@cnasikas cnasikas left a 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.

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
alerting 181 196 +15
observability 534 546 +12
securitySolution 5496 5508 +12
triggersActionsUi 735 747 +12
total +51

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/alerting-types 33 161 +128
@kbn/alerts-ui-shared 98 183 +85
total +213

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
alerting 92.6KB 96.0KB +3.4KB
observability 296.9KB 300.5KB +3.5KB
securitySolution 15.2MB 15.2MB +3.4KB
total +10.4KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id before after diff
@kbn/alerts-ui-shared 2 4 +2

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
alerting 24.9KB 25.0KB +4.0B
observability 152.2KB 152.3KB +107.0B
triggersActionsUi 121.1KB 124.7KB +3.6KB
total +3.7KB
Unknown metric groups

API count

id before after diff
@kbn/alerting-types 33 161 +128
@kbn/alerts-ui-shared 110 196 +86
total +214

References to deprecated APIs

id before after diff
@kbn/alerting-types 0 24 +24
alerting 116 96 -20
total +4

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@JiaweiWu JiaweiWu merged commit dc3f76b into elastic:main May 31, 2024
35 checks passed
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label May 31, 2024
JiaweiWu added a commit that referenced this pull request Jun 5, 2024
## 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.15.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants