feat: implement dialogs for changerequest milestone handling and removing release plans #9240
Conversation
daveleek
commented
Feb 6, 2025
daveleek
commented
…ving release plans
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
| <ReleasePlanAddChangeRequestDialog | ||
| action='startMilestone' | ||
| environmentId={environment} | ||
| featureId={featureName} | ||
| onClosing={() => { | ||
| setPlanForChangeRequestStartMilestoneDialog(undefined); | ||
| setMilestoneForChangeRequestDialog(undefined); | ||
| }} | ||
| projectId={projectId} | ||
| releasePlan={planForChangeRequestStartMilestoneDialog} | ||
| milestone={milestoneForChangeRequestDialog} | ||
| /> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 🤷
…nge-request-dialogs
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Files |
|
|
||
| const StyledBoldSpan = styled('span')(({ theme }) => ({ | ||
| fontWeight: theme.typography.fontWeightBold, | ||
| })); | ||
|
|
||
| interface IReleasePlanAddChangeRequestDialogProps { | ||
| action: 'addReleasePlan' | 'deleteReleasePlan' | 'startMilestone'; |
There was a problem hiding this comment.
Is this needed now that we split them up?
There was a problem hiding this comment.
Strange, I removed these. why doesn't that show up?
| releaseTemplate?: IReleasePlanTemplate | undefined; | ||
| releasePlan?: IReleasePlan | undefined; | ||
| milestone?: IReleasePlanMilestone | undefined; | ||
| environmentActive?: boolean; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)} | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This is also gone, very strange
| projectId: string; | ||
| featureId: string; | ||
| environmentId: string; | ||
| releaseTemplate: IReleasePlanTemplate | undefined; | ||
| releaseTemplate?: IReleasePlanTemplate | undefined; |
There was a problem hiding this comment.
No need for the | undefined with the ?.
| text: 'Added to draft', | ||
| }); | ||
| onClosing(); | ||
| }; |
There was a problem hiding this comment.
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>(); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
What's preventing us from making these dialogs work the same way as the existing ReleasePlanRemoveDialog?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
but then that would be 3 isOpens instead.
That feels more intuitive to me.
daveleek
deleted the
feat/release-plan-remove-start-milestone-change-request-dialogs
branch
