-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Feat: Enable activated alert creation via alert rule form #68959
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
Conversation
); | ||
} | ||
|
||
renderMonitorTypeSelect() { |
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.
rather than following the render* pattern here, could we just create a new functional component instead?
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.
😢 was considering it...
but rather than having 2 render patterns, I figured we should keep it consistent.
hopefully we'll eventually rip this all out anyways
} | ||
> | ||
<strong>Continuous</strong> | ||
<div>Continuously monitor trends for the metrics outlined below</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.
nit: might be easier to add t
functions now vs later.
Monitor{' '} | ||
<SelectControl | ||
name="activationCondition" | ||
styles={{ |
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'd recommend pulling these styles out and creating a styled SelectControl instead of inlining them here.
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.
Ah
So this is a symptom of us creating our wild wacky components :(
In order to attach styles to the children elements, there's no easy way to do so other than utilizing SelectControls' dumb way of styling 💢
minWidth: 200, | ||
maxWidth: 300, |
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.
consts
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 may opt to ignore these nits 😬
for now, not trying to make things good, just make them work
I don't see any use case for reusability here :/
{ | ||
value: ActivationConditionType.RELEASE_CREATION, | ||
label: t('New Release'), | ||
}, | ||
{ | ||
value: ActivationConditionType.DEPLOY_CREATION, | ||
label: t('New Deploy'), | ||
}, |
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.
nit: move these to constants
onTimeWindowChange, | ||
project, | ||
monitorType, | ||
} = this.props; |
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.
we're using a lot of props here - i wonder if we could use hooks or reduce the prop drilling 🤔
@@ -1108,6 +1182,9 @@ class RuleFormContainer extends DeprecatedAsyncComponent<Props, State> { | |||
onTimeWindowChange={value => this.handleFieldChange('timeWindow', value)} | |||
disableProjectSelector={disableProjectSelector} | |||
isExtrapolatedChartData={isExtrapolatedChartData} | |||
monitorType={monitorType} | |||
activationCondition={activationCondition} | |||
onMonitorTypeSelect={this.handleMonitorTypeSelect} |
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.
unrelated to this change
we should make a tech debt item to completely refactor this form... 1200 lines and there's a lot of improvements we could do to this, from a technical standpoint alone.
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.
Oh yea absolutely.
I hate everything about this form :|
_onSubmitSuccess, | ||
_onSubmitError, |
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 optionally invoke these?
}; | ||
|
||
handleSubmit = async ( | ||
_data: Partial<MetricRule>, |
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 this because the ruleForm
isn't using the Form
class to maintain state?
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 have no idea why :/
I think this only changed because lint rules or something 🤷
3d3a911
to
83ebe8c
Compare
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 we include some tests to ensure we don't have any side effects with the new states? (and then maybe some around the new props?)
83ebe8c
to
54cf7ca
Compare
Bundle ReportChanges will increase total bundle size by 3.97kB ⬆️
|
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.
If possible, it'd be great to get some tests included here. feel free to treat the comments as options (i found a few other places where t
functions might be handy and added them as diffs for 1 click adds 😎)
}) | ||
} | ||
> | ||
<strong>Continuous</strong> |
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.
nit:
<strong>Continuous</strong> | |
<strong>{t('Continuous')</strong> |
<strong>Conditional</strong> | ||
{monitorType === MonitorType.ACTIVATED ? ( | ||
<ActivatedAlertFields> | ||
Monitor{' '} |
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.
nit:
Monitor{' '} | |
{`${t('Monitor')} '} |
inline={false} | ||
flexibleControlStateSize | ||
/>{' '} | ||
for{' '} |
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.
for{' '} | |
{`${t('for')} `} |
RELEASE_CREATION = 0, | ||
DEPLOY_CREATION = 1, |
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 the ints map to the database storage level? if so 👍 if not, maybe we could use strings to define these so 0
won't evaluate as falsy.
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.
Yea - i agree with the general sentiment around testing. For this change in particular, i've already included a test to assert the form is able to submit with an activation condition. Otherwise i'm not sure what else you'd like to write a test for unless you're looking to rebuild and re-test every component here unfortunately. We can hash out a separate ticket to clean this up if you feel strongly about it |
Modifies the AlertRule form to add options for activated rule creation
Apr-15-2024.21-50-31.mp4
NOTE: GET api's are still filtering out all activated alert rules so this details page is not rendering anything yet