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

Feat: Enable activated alert creation via alert rule form #68959

Merged
merged 4 commits into from
Apr 18, 2024

Conversation

nhsiehgit
Copy link
Contributor

@nhsiehgit nhsiehgit commented Apr 16, 2024

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

@github-actions github-actions bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Apr 16, 2024
);
}

renderMonitorTypeSelect() {
Copy link
Contributor

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?

Copy link
Contributor Author

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>
Copy link
Contributor

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={{
Copy link
Contributor

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.

Copy link
Contributor Author

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 💢

Comment on lines 449 to 450
minWidth: 200,
maxWidth: 300,
Copy link
Contributor

Choose a reason for hiding this comment

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

consts

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 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 :/

Comment on lines +460 to +459
{
value: ActivationConditionType.RELEASE_CREATION,
label: t('New Release'),
},
{
value: ActivationConditionType.DEPLOY_CREATION,
label: t('New Deploy'),
},
Copy link
Contributor

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;
Copy link
Contributor

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}
Copy link
Contributor

@saponifi3d saponifi3d Apr 16, 2024

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.

Copy link
Contributor Author

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 :|

Comment on lines +664 to +665
_onSubmitSuccess,
_onSubmitError,
Copy link
Contributor

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>,
Copy link
Contributor

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?

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 have no idea why :/

I think this only changed because lint rules or something 🤷

Copy link
Contributor

@saponifi3d saponifi3d left a 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?)

Copy link

codecov bot commented Apr 17, 2024

Bundle Report

Changes will increase total bundle size by 3.97kB ⬆️

Bundle name Size Change
app-webpack-bundle-array-push 26.17MB 3.97kB ⬆️

Copy link
Contributor

@saponifi3d saponifi3d left a 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>
Copy link
Contributor

Choose a reason for hiding this comment

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

nit:

Suggested change
<strong>Continuous</strong>
<strong>{t('Continuous')</strong>

<strong>Conditional</strong>
{monitorType === MonitorType.ACTIVATED ? (
<ActivatedAlertFields>
Monitor{' '}
Copy link
Contributor

Choose a reason for hiding this comment

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

nit:

Suggested change
Monitor{' '}
{`${t('Monitor')} '}

inline={false}
flexibleControlStateSize
/>{' '}
for{' '}
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
for{' '}
{`${t('for')} `}

Comment on lines +296 to +297
RELEASE_CREATION = 0,
DEPLOY_CREATION = 1,
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@nhsiehgit
Copy link
Contributor Author

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.
These components in particular are just generally gross and lack adequate testing, and i don't think it's worth the effort to push for those changes here.

We can hash out a separate ticket to clean this up if you feel strongly about it

@nhsiehgit nhsiehgit merged commit 6d88cff into master Apr 18, 2024
41 checks passed
@nhsiehgit nhsiehgit deleted the activated_alerts_ui branch April 18, 2024 15:09
@github-actions github-actions bot locked and limited conversation to collaborators May 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Scope: Frontend Automatically applied to PRs that change frontend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants