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(standups): Responses grid with static prompt #6353

Merged
merged 8 commits into from
Apr 22, 2022

Conversation

BartoszJarocki
Copy link
Contributor

@BartoszJarocki BartoszJarocki commented Apr 6, 2022

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.

@BartoszJarocki BartoszJarocki force-pushed the feat/6201/standups-grid branch 2 times, most recently from bbbeb63 to eb76aa0 Compare April 7, 2022 13:57
@BartoszJarocki BartoszJarocki linked an issue Apr 8, 2022 that may be closed by this pull request
1 task
@BartoszJarocki BartoszJarocki marked this pull request as ready for review April 13, 2022 07:43
@BartoszJarocki
Copy link
Contributor Author

@jmtaber129 would you mind taking a look? thanks!

@BartoszJarocki BartoszJarocki changed the title feat(standups): Responses grid feat(standups): Responses grid with static prompt Apr 13, 2022
@BartoszJarocki BartoszJarocki linked an issue Apr 13, 2022 that may be closed by this pull request
2 tasks
const teamMembers = useMemo(() => {
return meeting.phases
.flatMap((phase) => phase.stages)
.flatMap((stage) => stage.teamMember)
Copy link
Contributor

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

Copy link
Contributor Author

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')({
Copy link
Contributor

Choose a reason for hiding this comment

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

+1 TeamMemmberName -> TeamMemberName

Copy link
Contributor Author

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

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

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

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.

Copy link
Contributor Author

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

Comment on lines 92 to 93
id
phaseType
Copy link
Contributor

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

@BartoszJarocki
Copy link
Contributor Author

@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 🙏

@BartoszJarocki
Copy link
Contributor Author

@mattkrick I'd be great if you could take a look 🙏 thank you!

Copy link
Member

@mattkrick mattkrick left a 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 {
Copy link
Member

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.

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 cool, will fix

...useMeeting_meeting
phases {
stages {
... on TeamPromptResponseStage {
Copy link
Member

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

Copy link
Contributor Author

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

Copy link
Member

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])
Copy link
Member

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}))

Copy link
Contributor Author

@BartoszJarocki BartoszJarocki Apr 19, 2022

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
Screenshot 2022-04-19 at 15 35 16

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

Copy link
Member

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')
Copy link
Member

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

Copy link
Contributor Author

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!

@BartoszJarocki BartoszJarocki merged commit 244cec2 into master Apr 22, 2022
@BartoszJarocki BartoszJarocki deleted the feat/6201/standups-grid branch April 22, 2022 06:57
atannus pushed a commit to atannus/parabol that referenced this pull request Apr 26, 2022
* 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>
@github-actions github-actions bot mentioned this pull request Sep 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Standup UI - Responses grid Standup UI - Static, non-editable prompt
3 participants