-
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
[RAM] Make RuleStatusDropdown shareable #130205
[RAM] Make RuleStatusDropdown shareable #130205
Conversation
Pinging @elastic/response-ops (Team:ResponseOps) |
@@ -55,34 +56,55 @@ const COMMON_SNOOZE_TIMES: Array<[number, SnoozeUnit]> = [ | |||
[1, 'd'], | |||
]; | |||
|
|||
const PREV_SNOOZE_INTERVAL_KEY = 'previousSnoozeInterval'; |
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.
Should we prefix this key with our plugin name or something?
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 foresee there being a use case where the consumer might need to pass their own key? if not feel free to disregard this comment.
edit: nevermind, chris already mentioned this in another comment
@@ -227,6 +230,9 @@ export class Plugin | |||
getAlertsTable: (props: AlertsTableProps) => { | |||
return getAlertsTableLazy(props); | |||
}, | |||
getRuleStatusDropdown: (props: RuleStatusDropdownProps) => { |
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.
Perhaps we want to give consumers a choice if they want to inherit the previous history or start a new history for just their use case? Right now, it's all shared without choice
const interval = localStorage.getItem(PREV_SNOOZE_INTERVAL_KEY); | ||
const [previousSnoozeInterval, setPreviousSnoozeInterval] = useState<string | null>(interval); | ||
const storeAndSetPreviousSnoozeInterval = (newInterval: string) => { | ||
localStorage.setItem(PREV_SNOOZE_INTERVAL_KEY, newInterval); |
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.
So local storage never expires - do we care/want to manage that somehow? I'm not sure - this is a small amount of data
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'm not too worried about storing a single string indefinitely but if it's a blocker I can add an expiration system
Not sure why the functional test is failing on CI, it's passing on local fine. Will investigate and see if I can get it to be more reliable. |
@Zacqary Great! I tested out the use of RuleStatusDropdown component in Observability and works fine with one extra change I had to do in the |
import React, { useState } from 'react'; | ||
import { getRuleStatusDropdownLazy } from '../../../common/get_rule_status_dropdown'; | ||
|
||
export const InternalShareableComponentsSandbox: React.FC<{}> = () => { |
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.
So for the components that I'm working on, I am rebasing off of this branch since I also need to E2E test the components. I'm wondering if we could maybe move the rule status dropdown rendering to its own file? so I can add my components in this sandbox as well
maybe something like?
return (
<div>
<RuleStatusDropdownSandbox />
<OtherSandboxes />
</div>
);
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.
Can do
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.
awesome!
…atus-dropdown # Conflicts: # x-pack/plugins/triggers_actions_ui/public/types.ts
…atus-dropdown # Conflicts: # x-pack/plugins/triggers_actions_ui/public/plugin.ts
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.
Aside from Chris's comments, this LGTM!
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.
LGTM!
@elastic/kibana-operations I upped the |
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.
onRuleChanged: () => void; | ||
enableRule: () => Promise<void>; | ||
disableRule: () => Promise<void>; | ||
snoozeRule: (snoozeEndTime: string | -1, interval: string | null) => Promise<void>; | ||
unsnoozeRule: () => Promise<void>; | ||
isEditable: boolean; | ||
previousSnoozeInterval: string | null; | ||
previousSnoozeInterval?: string | null; |
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 need this prop? I feel like we should not have this prop anymore, am I missing something?
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.
@chrisronline requested we keep it: #130205 (comment)
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.
Hmm. I might have missed how this ended up. I think we can provide consumers with the choice to change the key used in local storage so they don't need to inherit previously stored intervals for other solutions
const usePreviousSnoozeInterval: (p?: string | null) => [string | null, (n: string) => void] = ( | ||
propsInterval | ||
) => { | ||
const intervalFromStorage = localStorage.getItem(PREV_SNOOZE_INTERVAL_KEY); |
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 am wondering if we should allow different SNOOZE_INTERVAL_KEY
for different solutions, maybe let's see if we get this requirement in the future.
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.
match with this comment #130205 (comment)
Maybe in the future we can try to investigate to test our shareable components like that https://github.com/elastic/kibana/blob/main/x-pack/test/plugin_functional/plugins/timelines_test/public/plugin.ts to avoid dead code in our plugin. what do you think @chrisronline @JiaweiWu @Zacqary ? |
💚 Build SucceededMetrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
async chunk count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
@XavierM sorry didn't realize there was an established convention for writing tests like this, we can port that over. Might help with the bundle size issue anyway |
Yea I can work on creating a separate plugins for testing purposes, since I'm gonna be writing more of these tests. |
Update: I just saw your change! Thx |
@@ -57,6 +57,8 @@ export { enableRule } from './application/lib/rule_api/enable'; | |||
export { disableRule } from './application/lib/rule_api/disable'; | |||
export { muteRule } from './application/lib/rule_api/mute'; | |||
export { unmuteRule } from './application/lib/rule_api/unmute'; | |||
export { snoozeRule } from './application/lib/rule_api/snooze'; |
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.
@Zacqary Oops somehow I missed it! Thanks I can now reuse your component. Thanks a ton!
* Add shareable e dropdown and move snooze interval to localstorage * Add internal components sandbox page and status dropdown test * Remove components sandbox tab * Fix typecheck * Fix typechecks and tests * Attempt to deflake tests * Reenable previousSnoozeInterval from props and prefix storage key * Export missing apis * Fix tooltip for indefinite snooze * Attempt to deflake functional test * Modularize Sandbox * Up triggersActionsUi package limit
Summary
Closes #129774 and #128956
Adds a lazy loadable
getRuleStatusDropdown
function to thetriggersActionsUI
root. It can be shared with other plugins in a similar manner to the Alert Flyout, such as this use by the infra plugin.Moves
previousSnoozeInterval
logic into Localstorage, so that it can persist across plugins and page usages.Also adds an internal
__components_sandbox
route to TriggersActionsUI, which can only be enabled using an experimental feature flag intended only to be used by the functional testing suite. This enables us to run some rudimentary functional tests on just the RuleStatusDropdown by itself.Checklist