-
Notifications
You must be signed in to change notification settings - Fork 2
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: multiple project managers #304
Conversation
{projectRevision.managerFormChanges.edges.map(({ node }) => ( | ||
<React.Fragment key={node.projectManagerLabel.id}> | ||
<Grid.Row> | ||
<label>{node.projectManagerLabel.label}</label> |
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.
<label>{node.projectManagerLabel.label}</label> | |
<label htmlFor={your_select_id}>{node.projectManagerLabel.label} (optional)</label> |
In the current behaviour, all managers are optional, so this should be reflected in the label.
We do have a FieldLabel
component, which could be reused here. At least the getRequiredLabel
function could be reused.
size="small" | ||
onClick={() => deleteManager(node.formChange?.id)} | ||
> | ||
Clear |
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 be disabled if there is no manager selected, or if the mutation is already in flight for this manager. You may need to refactor the react fragment into a separate component to track individual mutations
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.
As an alternative, we could also make the clear button a noop if the mutation is in flight or if there is no manager selected, I don't think that would harm the UX, things would be cleared again from the user's perspective
app/next-env.d.ts
Outdated
@@ -1,4 +1,5 @@ | |||
/// <reference types="next" /> | |||
/// <reference types="next/types/global" /> |
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.
you need to update your local yarn packages. This was removed in the latest nextjs update
}, | ||
}); | ||
}); | ||
|
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 missing a test that makes sure the updateFormChangeMutation
is called when we update a dropdown field without clearing it
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.
Nice! 👌 Just missing a small test
60161af
to
aef7b35
Compare
projectRevision(id: $projectRevision) { | ||
managerFormChanges: projectManagerFormChangesByLabel { | ||
edges { | ||
node { | ||
projectManagerLabel { | ||
id | ||
rowId | ||
label | ||
} | ||
formChange { | ||
id | ||
newFormData | ||
} | ||
} | ||
} |
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.
https://bcgov-cas.promyze.app/#/CAS%20GGIRCS/home?practiceId=61e1eb156e4cd70fe286ec9f
You could reuse ProjectManagerForm_query
here, or, if that fragment was split in two, ProjectManagerForm_projectRevision
// Delete a manager from the project revision | ||
const [discardFormChange] = useDeleteManagerFromRevisionMutation(); | ||
const deleteManager = (id: string) => { | ||
discardFormChange({ |
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.
The action here needs to depend on the form_change
operation
:
- If
operation === "CREATE"
, then you can discard it, as the manager was added in the same revision - If
operation === "UPDATE"
, then theform_change.operation
should be updated toARCHIVE
fb9f614
to
3ef1b05
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.
// If a form_change exists, and the payload does not contain a cifUserId delete it | ||
else if (formChangeId && !formChange.cifUserId && !discardInFlight) { | ||
deleteManager(formChangeId); | ||
} |
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 feel this entire pattern of creating / updating / deleting form changes depending on whether we have a certain field or not will be reused over and over, just a noting a thought for later on how we could reuse that logic
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.
Yes, this may be refactored into a hook. We can do that after we have two examples of this pattern (there will be a second one in #280 )
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.
-- nvm -- reviewing too many PRs in parallel
revision={query.projectRevision} | ||
projectManagerFormRef={projectManagerFormRef} | ||
setValidatingForm={(validator) => | ||
(projectManagerFormRef.current = validator) |
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 really like to find better wording for this function / callback if you have ideas, I'm quite unhappy with what I chose when I first implemented it.
This is just confusing
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.
looks good! I'll let @matthieu-foucault approve if he has more comments
249c692
to
c82b5c0
Compare
allCifUsers { | ||
edges { | ||
node { | ||
rowId | ||
firstName | ||
lastName | ||
} | ||
} |
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.
Why is this removed? You should have two fragments instead of passing allCifUsers
as a prop, no? You can use useFragment
multiple times in the same component.
const { allCifUsers } = useFragment( | ||
graphql` | ||
fragment ProjectManagerFormGroup_query on Query { | ||
allCifUsers { | ||
edges { | ||
node { | ||
rowId | ||
firstName | ||
lastName | ||
} | ||
} | ||
} | ||
} | ||
`, | ||
props.query | ||
); |
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.
Why is this fragment here and not in the child component?
:global(button.pg-button) { | ||
margin-left: 0.4em; | ||
margin-right: 0em; | ||
} | ||
:global(.right-aligned-column) { | ||
display: flex; | ||
justify-content: flex-end; | ||
align-items: flex-start; | ||
} |
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.
See #324 (comment)
I think that we need to use an outer div to scope those styles, otherwise they're no better than if you used <style jsx global>
(I could be wrong though, haven't fully tested this)
<> | ||
<React.Fragment key={change.projectManagerLabel.id}> |
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.
Don't need those two fragments
Allows adding multiple managers to a project.
addManagerToRevision
anddeleteManagerFromRevision
mutations have a query in the mutation return. The record returned fromprojectManagerFormChangesByLabel
is a composite return value that doesn't represent an actual single database record. This means that we can't use the connection directive to update the data. We may want to look into subscriptions at some point. I think they may end up being necessary to handle concurrent editing.We could also look into using refetchable fragments to refresh the ProjectManagerForm fragment, though it kind of sounds like this is essentially the same as adding a query to the mutation return.