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: implement dialogs for changerequest milestone handling and removing release plans #9240

Merged

Conversation

daveleek
Copy link
Contributor

@daveleek daveleek commented Feb 6, 2025

image
Skjermbilde 2025-02-06 kl  10 20 10

Verified

This commit was signed with the committer’s verified signature.
daveleek David Leek
…ving release plans
Copy link

vercel bot commented Feb 6, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
unleash-monorepo-frontend ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 6, 2025 3:37pm
1 Skipped Deployment
Name Status Preview Comments Updated (UTC)
unleash-docs ⬜️ Ignored (Inspect) Visit Preview Feb 6, 2025 3:37pm

Comment on lines 237 to 248
<ReleasePlanAddChangeRequestDialog
action='startMilestone'
environmentId={environment}
featureId={featureName}
onClosing={() => {
setPlanForChangeRequestStartMilestoneDialog(undefined);
setMilestoneForChangeRequestDialog(undefined);
}}
projectId={projectId}
releasePlan={planForChangeRequestStartMilestoneDialog}
milestone={milestoneForChangeRequestDialog}
/>
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 set two up here so I wouldn't have to let the action be nullable & have another react state for it. I could change the logic in the dialog to looking at milestone being set, only release plan being set, or only template being set though. WDYT @nunogois?

Copy link
Member

Choose a reason for hiding this comment

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

Uh sure. Honestly I would have expected separate dialog components for each action, but if this works and you're happy I don't think it matters much 🤷

Verified

This commit was signed with the committer’s verified signature.
daveleek David Leek
…nge-request-dialogs
Copy link
Contributor

github-actions bot commented Feb 6, 2025

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

PackageVersionScoreDetails

Scanned Files

Verified

This commit was signed with the committer’s verified signature.
daveleek David Leek

const StyledBoldSpan = styled('span')(({ theme }) => ({
fontWeight: theme.typography.fontWeightBold,
}));

interface IReleasePlanAddChangeRequestDialogProps {
action: 'addReleasePlan' | 'deleteReleasePlan' | 'startMilestone';
Copy link
Member

Choose a reason for hiding this comment

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

Is this needed now that we split them up?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Strange, I removed these. why doesn't that show up?

releaseTemplate?: IReleasePlanTemplate | undefined;
releasePlan?: IReleasePlan | undefined;
milestone?: IReleasePlanMilestone | undefined;
environmentActive?: boolean;
Copy link
Member

@nunogois nunogois Feb 6, 2025

Choose a reason for hiding this comment

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

Seems like these 2 are unused. One of the advantages of splitting them up into separate components is that each one can request exactly what they need.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is really weird, I removed these

@@ -45,7 +62,7 @@ export const ReleasePlanAddChangeRequestDialog = ({
return (
<Dialogue
title='Request changes'
open={Boolean(releaseTemplate)}
open={Boolean(releaseTemplate) || Boolean(releasePlan)}
Copy link
Member

Choose a reason for hiding this comment

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

Not a huge fan of this ambiguity. What is this dialog doing that it shows up if one of these is truthy? I also prefer to handle the open state explicitly instead of relying on other state variables, but that's mostly a personal preference.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is also gone, very strange

projectId: string;
featureId: string;
environmentId: string;
releaseTemplate: IReleasePlanTemplate | undefined;
releaseTemplate?: IReleasePlanTemplate | undefined;
Copy link
Member

Choose a reason for hiding this comment

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

No need for the | undefined with the ?.

text: 'Added to draft',
});
onClosing();
};
Copy link
Member

@nunogois nunogois Feb 6, 2025

Choose a reason for hiding this comment

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

IMO the caller should own this. I think dialogs should only care about displaying the required information and emitting the "confirmation" callback to the parent, which then handles it. Something like onConfirm.

const [
milestoneForChangeRequestDialog,
setMilestoneForChangeRequestDialog,
] = useState<IReleasePlanMilestone | undefined>();
Copy link
Member

Choose a reason for hiding this comment

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

You can use something like selectedReleasePlan and share that state across multiple dialogs, since only one of them will be open at a time. I'm also pretty sure you don't need to specify | undefined here, it's implicit.

Copy link
Member

Choose a reason for hiding this comment

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

What's preventing us from making these dialogs work the same way as the existing ReleasePlanRemoveDialog?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

since only one of them will be open at a time

We moved the "am I open" part inside the dialog, so this follows that pattern. And to check if it's open - it checks to see if the provided property is defined (or boolean). So if we share, then both delete and start milestone will open in some sequence.

We could move to having an isOpen for them, but then that would be 3 isOpens instead.

Copy link
Member

@nunogois nunogois Feb 6, 2025

Choose a reason for hiding this comment

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

but then that would be 3 isOpens instead.

That feels more intuitive to me.

Verified

This commit was signed with the committer’s verified signature.
daveleek David Leek

Verified

This commit was signed with the committer’s verified signature.
daveleek David Leek

Verified

This commit was signed with the committer’s verified signature.
daveleek David Leek

Verified

This commit was signed with the committer’s verified signature.
daveleek David Leek

Verified

This commit was signed with the committer’s verified signature.
daveleek David Leek
…ding change
@daveleek daveleek merged commit e689e2e into main Feb 6, 2025
11 checks passed
@daveleek daveleek deleted the feat/release-plan-remove-start-milestone-change-request-dialogs branch February 6, 2025 15:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

2 participants