-
Notifications
You must be signed in to change notification settings - Fork 13
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
chore(vote): stubbed out voting #209
chore(vote): stubbed out voting #209
Conversation
ef0bc68
to
45e25a8
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.
PRAISE: You really got a lot done! That's two major parts of this feature you've improved in less than a week. We're so close to launching!
ISSUE(blocking): This needs updating in light of the changes in #236.
SUGGESTION: Might be easiest to split each component into it's own file, and then rebase on top of #236 (or main, if it's merged). That way you have fewer merge conflicts and can compare before/after a little easier.
NOTE: Happy to do this for you, if you prefer!
I took the liberty of handling the merge conflicts and bringing this up to date with main, but I didn't want to force push over your pr branch without giving you a chance to review it first. There's a copy of the results at https://github.com/tulsawebdevs/website/tree/feature/proposal-voting in case you'd like to compare them. If that branch looks good to you, let me know and I'll push it to this PR. |
@helmturner Awesome, thanks for doing that! I had a look and everything looks good to me. |
45e25a8
to
1cbb0cd
Compare
@helmturner I had some time today, so hope you don't mind I went ahead and incorporated your updates into this PR. I then also added
Regarding the voting data: Will the user's voting data (upvotes and totals depending on proposal status) be included with the proposal data or will we be needing to fetch that on a per-proposal basis? |
Oh nice, thank you! I'm sorry I didn't get around to it sooner, some family stuff came up that I had to focus on. Re: votes, I think the idea will be to have an endpoint specifically for user's votes. That would be 1 query for user's voting record (maybe we pull the whole thing and put it in client state), and then when a proposal/proposal list is queried we can just populate the vote totals from state. I'll get this reviewd right 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.
PRAISE: excellent work again! Always a pleasure reviewing your code.
POLISH: I think this is g2g after just some minor touch-ups.
QUESTION: If you've got any opinions / curiosity about the form/fetching infra, I've got an experimental branch where I'm exploring some options.
const handleVote = useProtectedFunction( | ||
useDebounce((value: Vote) => { | ||
const votePayload: VotePayload = { | ||
initiativeId: proposal.id.toString(10), | ||
vote: value, | ||
comment: '', | ||
authorId: proposal.authorId, | ||
authorName: proposal.authorName, | ||
authorEmail: proposal.authorEmail, | ||
}; | ||
|
||
setVoteValue(value); | ||
voteRequest(votePayload).catch(() => { | ||
toast.error('Could not cast vote. Please try again.'); | ||
}); | ||
}), | ||
{ | ||
unauthorizedMessage: 'You do not have permission to vote.', | ||
}, | ||
); |
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.
ISSUE: We probably want to take the setVoteValue(value)
call out of the debounce to improve perceived performance. As it is, some clicks are 'ignored' from the user's perspective.
FIX: If I'm not mistaken, we should just be able to lift the function call out of the debounce hook without causing the value to fall out of sync with what's sent in the request.
NOTE(non-blocking): Normally we'd want to store the user's initial vote in memory and only update it when we get a success confirmation from the server. That way we can roll back the UI if the vote request fails. No need to worry about it here, though; i'm researching some libraries to use for data fetching that should abstract most of the query management cycle away.
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.
That makes sense. I thought it was awkward to see a slight delay. I've lifted up setting the vote value.
const voteOptions = [ | ||
{ | ||
label: 'Strongly Disinterested', | ||
value: '-2', | ||
id: 'vote-strongly-disinterested', | ||
}, | ||
{ | ||
label: 'Slightly Disinterested', | ||
value: '-1', | ||
id: 'vote-slightly-disinterested', | ||
}, | ||
{ label: 'Neutral', value: '0', id: 'vote-neutral' }, | ||
{ label: 'Slightly Interested', value: '1', id: 'vote-slightly-interested' }, | ||
{ label: 'Strongly Interested', value: '2', id: 'vote-strongly-interested' }, | ||
]; |
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.
POLISH: I think we can shorten some of the labels on these
SUGGESTION:
const voteOptions = [ | |
{ | |
label: 'Strongly Disinterested', | |
value: '-2', | |
id: 'vote-strongly-disinterested', | |
}, | |
{ | |
label: 'Slightly Disinterested', | |
value: '-1', | |
id: 'vote-slightly-disinterested', | |
}, | |
{ label: 'Neutral', value: '0', id: 'vote-neutral' }, | |
{ label: 'Slightly Interested', value: '1', id: 'vote-slightly-interested' }, | |
{ label: 'Strongly Interested', value: '2', id: 'vote-strongly-interested' }, | |
]; | |
const voteOptions = [ | |
{ | |
label: 'Strong Disinterest', | |
value: '-2', | |
id: 'vote-strong-disinterest', | |
}, | |
{ | |
label: 'Slight Disinterest', | |
value: '-1', | |
id: 'vote-slight-disinterest', | |
}, | |
{ label: 'Neutral', value: '0', id: 'vote-neutral' }, | |
{ label: 'Slight Interest', value: '1', id: 'vote-slight-interest' }, | |
{ label: 'Strong Interest', value: '2', id: 'vote-strong-interest' }, | |
]; |
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 like this suggestion! I've updated based on input.
return ( | ||
<Label | ||
key={`${proposal.id}-${option.id}`} | ||
className={cn('flex items-center gap-2', { |
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.
POLISH: The radio buttons look pretty wonky to me. That's mostly because we have an odd number of off-balance items, but I wonder moving the labels below the radio buttons might help it look more even?
SUGGESTION:
className={cn('flex items-center gap-2', { | |
className={cn('flex w-[20%] flex-col text-center items-center gap-2', { |
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're right, I agree with that. I've made an update to reflect this.
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.
PRAISE: I have nothing to add... this is just great. Beautiful work! Love the code-quality improvements.
Pull Request Template
Checklist
dev
branchnpm test && npm lint && npm test:e2e
and all tests passDescription
Type of Change
How Has This Been Tested?
Microservices and API Integration
Checklist:
Screenshots (if appropriate):
Please review and suggest any further insights, improvements, or modifications needed.