-
Notifications
You must be signed in to change notification settings - Fork 326
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(standups): Responses grid with static prompt #6353
Conversation
bbbeb63
to
eb76aa0
Compare
eb76aa0
to
66f77e0
Compare
66f77e0
to
11ddf26
Compare
@jmtaber129 would you mind taking a look? thanks! |
const teamMembers = useMemo(() => { | ||
return meeting.phases | ||
.flatMap((phase) => phase.stages) | ||
.flatMap((stage) => stage.teamMember) |
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.
+1 Just mapping to stages
should be a bit more representative, since the response cards encapsulate the full stage with both team member and response, but this is fine as-is for the purposes of implementing the grid
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.
yeah, I'm pretty sure it'll need to be adjusted to the card component anyway so I didn't want to guess. if you don't mind, I'll leave it as is
padding: '0 8px' | ||
}) | ||
|
||
const TeamMemmberName = styled('h3')({ |
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.
+1 TeamMemmberName
-> TeamMemberName
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.
🤦
@@ -22,23 +86,80 @@ const TeamPromptMeeting = (props: Props) => { | |||
graphql` | |||
fragment TeamPromptMeeting_meeting on TeamPromptMeeting { | |||
...TeamPromptTopBar_meeting | |||
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.
+1 This id
doesn't seem to be used anywhere
phaseType | ||
stages { | ||
... on TeamPromptResponseStage { | ||
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.
+1 This id
doesn't seem to be used anywhere (this seems like a reasonable key
for response cards, but we're currently using teamMember.id
)
|
||
return ( | ||
<TeamMemberResponse | ||
key={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.
+1 Would it make sense to use child.key
here? That would guarantee consistency between the key
used by useTransition
and the key
used by React.
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 sure. technically, it's the same thing but I agree, it's cleaner
id | ||
phaseType |
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.
+1 id
and phaseType
don't seem to be used anywhere
@jmtaber129 I fixed every comment except for the mapping which I think should be aligned in the PR related to cards. thank you for the review, moving on to the maintainer review 🙏 |
@mattkrick I'd be great if you could take a look 🙏 thank you! |
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.
some very minor client-side stuff, after that feel free to merge!
@@ -22,23 +86,76 @@ const TeamPromptMeeting = (props: Props) => { | |||
graphql` | |||
fragment TeamPromptMeeting_meeting on TeamPromptMeeting { | |||
...TeamPromptTopBar_meeting | |||
...useMeeting_meeting | |||
phases { | |||
stages { |
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.
-1 fragment on TeamPromptResponsesPhase
instead. it's a little more expressive way to say "we only care about this 1 phase in particular"
as it's written, it's saying, "look at EVERY phase & for EVERY phase, give me the TeamPromptResponsesStages"
Also, if you fragment on the phase, then the teamMember object is guaranteed non null, which is nice.
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 cool, will fix
...useMeeting_meeting | ||
phases { | ||
stages { | ||
... on TeamPromptResponseStage { |
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.
-1 Could you please rename TeamPromptResponsesPhase
to TeamPromptResponsePhase
? (notice the missing "s"). not a problem in this PR, but i didn't discover it until now
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.
no strong opinions here, the origin of the name is the fact that this phase is for all responses, not one. let me know if that makes sense. if you think it's still better to use TeamPromptResponsePhase
I will fix
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 gotcha, that works!
} | ||
}) | ||
.filter(isNotNull) | ||
}, [meeting.phases]) |
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.
-1 with the changes above, you can simplify this to:
const responsePhase = meeting.phases.find((phase) => phase.__typename === 'TeamPromptResponsePhase')!
const teamMembers responsePhase.stages.map((stage) => {...stage.teamMember, key: stage.teamMember.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.
@mattkrick typescript is a little dumb in that case and responsePhase
can be another type as well.
see the screenshot below
do we already have some generic utility to generate type predicates? we'd need something like this and I just want to make sure I haven't missed anything in the codebase
https://stackoverflow.com/questions/59050071/narrow-return-type-of-find-from-discriminated-union-array
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 good call, we have GQLType
, which does the trick. I'll write a little commit to showcase it
}) | ||
.filter(isNotNull) | ||
}, [meeting.phases]) | ||
const phase = getPhaseByTypename(phases, 'TeamPromptResponsesPhase') |
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.
@BartoszJarocki let me know if this gets you whatcha need. if so, go ahead & merge this PR & we'll start using this more in the future
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.
yup, looks good! thank you!
* fix: not add another responses stage if stage already exist for a given team member * feat: added responses phase to phaseTypeToSlug lookup * feat: added team member to team prompt response stage gql type * feat: team prompt grid * feat: added static team prompt question * code cleanup * add getPhaeByTypename Co-authored-by: Matt Krick <matt.krick@gmail.com>
Fixes #6201
For now, we'll use the same grid as we use on the meeting dashboard. In next iterations we'll improve and implement #6389.
Earlier discussion for the reference: #5965
This PR also adds #6200 as it was a little change.