-
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
[Rules migration] Post merge feedback followups #202815
[Rules migration] Post merge feedback followups #202815
Conversation
Pinging @elastic/security-solution (Team: SecuritySolution) |
Pinging @elastic/security-threat-hunting (Team:Threat Hunting) |
...k/plugins/security_solution/public/siem_migrations/rules/components/header_buttons/index.tsx
Outdated
Show resolved
Hide resolved
...k/plugins/security_solution/public/siem_migrations/rules/components/header_buttons/index.tsx
Outdated
Show resolved
Hide resolved
...gins/security_solution/public/siem_migrations/rules/components/rule_details_flyout/index.tsx
Outdated
Show resolved
Hide resolved
...gins/security_solution/public/siem_migrations/rules/components/rule_details_flyout/index.tsx
Show resolved
Hide resolved
...gins/security_solution/public/siem_migrations/rules/components/rule_details_flyout/index.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/siem_migrations/rules/components/rules_table/index.tsx
Outdated
Show resolved
Hide resolved
* use `RuleMigrationsStats` * remove styled components and use only default ones
x-pack/plugins/security_solution/public/siem_migrations/rules/pages/index.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/siem_migrations/rules/pages/index.tsx
Outdated
Show resolved
Hide resolved
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.
Thanks Zhenia! 💯
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
History
cc @e40pud |
Starting backport for target branches: 8.x https://github.com/elastic/kibana/actions/runs/12163685105 |
## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](elastic#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](elastic#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](elastic#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate? (cherry picked from commit 4d8f711)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
) # Backport This will backport the following commits from `main` to `8.x`: - [[Rules migration] Post merge feedback followups (#202815)](#202815) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Ievgen Sorokopud","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-12-04T16:06:10Z","message":"[Rules migration] Post merge feedback followups (#202815)\n\n## Summary\r\n\r\nThese are the followup updated to address feedback from my previous PRs:\r\n\r\n* Make sure to use descriptive names specific to the `siem_migrations`\r\nsubdomain\r\n([comment](https://github.com/elastic/kibana/pull/200978#pullrequestreview-2454582368)):\r\n\r\n> Make sure you use descriptive names specific to the siem_migrations\r\nsubdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way\r\ntoo generic and conflict with the rule management terminology, which\r\nwould make code search more difficult.\r\n\r\n\r\n* Export the memo component directly everywhere\r\n([comment](https://github.com/elastic/kibana/pull/201597#discussion_r1858069127)):\r\n\r\n> Could we export the memo component directly everywhere? It's shorter\r\nand it makes it easier to find the references in the IDE.\r\n\r\n\r\n* Use one hook to access APIs instead of two\r\n([comment](https://github.com/elastic/kibana/pull/202494#discussion_r1867967135)):\r\n\r\n> I see that for every API request we have to implement 2 separate\r\nhooks. Why don't we add error handling to the same hook that does the\r\nuseQuery? so we have everything in one hook. Or is there a reason to\r\nhave them separate?","sha":"4d8f7111d0f8c330aab2c8347cf6d131570ff665","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","Team:Threat Hunting","Team: SecuritySolution","backport:prev-minor"],"title":"[Rules migration] Post merge feedback followups","number":202815,"url":"https://github.com/elastic/kibana/pull/202815","mergeCommit":{"message":"[Rules migration] Post merge feedback followups (#202815)\n\n## Summary\r\n\r\nThese are the followup updated to address feedback from my previous PRs:\r\n\r\n* Make sure to use descriptive names specific to the `siem_migrations`\r\nsubdomain\r\n([comment](https://github.com/elastic/kibana/pull/200978#pullrequestreview-2454582368)):\r\n\r\n> Make sure you use descriptive names specific to the siem_migrations\r\nsubdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way\r\ntoo generic and conflict with the rule management terminology, which\r\nwould make code search more difficult.\r\n\r\n\r\n* Export the memo component directly everywhere\r\n([comment](https://github.com/elastic/kibana/pull/201597#discussion_r1858069127)):\r\n\r\n> Could we export the memo component directly everywhere? It's shorter\r\nand it makes it easier to find the references in the IDE.\r\n\r\n\r\n* Use one hook to access APIs instead of two\r\n([comment](https://github.com/elastic/kibana/pull/202494#discussion_r1867967135)):\r\n\r\n> I see that for every API request we have to implement 2 separate\r\nhooks. Why don't we add error handling to the same hook that does the\r\nuseQuery? so we have everything in one hook. Or is there a reason to\r\nhave them separate?","sha":"4d8f7111d0f8c330aab2c8347cf6d131570ff665"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/202815","number":202815,"mergeCommit":{"message":"[Rules migration] Post merge feedback followups (#202815)\n\n## Summary\r\n\r\nThese are the followup updated to address feedback from my previous PRs:\r\n\r\n* Make sure to use descriptive names specific to the `siem_migrations`\r\nsubdomain\r\n([comment](https://github.com/elastic/kibana/pull/200978#pullrequestreview-2454582368)):\r\n\r\n> Make sure you use descriptive names specific to the siem_migrations\r\nsubdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way\r\ntoo generic and conflict with the rule management terminology, which\r\nwould make code search more difficult.\r\n\r\n\r\n* Export the memo component directly everywhere\r\n([comment](https://github.com/elastic/kibana/pull/201597#discussion_r1858069127)):\r\n\r\n> Could we export the memo component directly everywhere? It's shorter\r\nand it makes it easier to find the references in the IDE.\r\n\r\n\r\n* Use one hook to access APIs instead of two\r\n([comment](https://github.com/elastic/kibana/pull/202494#discussion_r1867967135)):\r\n\r\n> I see that for every API request we have to implement 2 separate\r\nhooks. Why don't we add error handling to the same hook that does the\r\nuseQuery? so we have everything in one hook. Or is there a reason to\r\nhave them separate?","sha":"4d8f7111d0f8c330aab2c8347cf6d131570ff665"}}]}] BACKPORT--> Co-authored-by: Ievgen Sorokopud <[email protected]>
## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](elastic#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](elastic#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](elastic#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate?
## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](elastic#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](elastic#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](elastic#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate?
## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](elastic#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](elastic#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](elastic#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate?
## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](elastic#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](elastic#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](elastic#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate?
## Summary These are the followup updated to address feedback from my previous PRs: * Make sure to use descriptive names specific to the `siem_migrations` subdomain ([comment](elastic#200978 (review))): > Make sure you use descriptive names specific to the siem_migrations subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way too generic and conflict with the rule management terminology, which would make code search more difficult. * Export the memo component directly everywhere ([comment](elastic#201597 (comment))): > Could we export the memo component directly everywhere? It's shorter and it makes it easier to find the references in the IDE. * Use one hook to access APIs instead of two ([comment](elastic#202494 (comment))): > I see that for every API request we have to implement 2 separate hooks. Why don't we add error handling to the same hook that does the useQuery? so we have everything in one hook. Or is there a reason to have them separate?
Summary
These are the followup updated to address feedback from my previous PRs:
siem_migrations
subdomain (comment):