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: Voting Component #96

Closed
Tracked by #91
helmturner opened this issue Mar 9, 2024 · 4 comments · Fixed by #209
Closed
Tracked by #91

feat: Voting Component #96

helmturner opened this issue Mar 9, 2024 · 4 comments · Fixed by #209
Labels

Comments

@helmturner
Copy link
Member

helmturner commented Mar 9, 2024

We need to give members a way to vote! For that, we need a voting component.

Requirements:

  • Should take a proposal ID and Title as props
  • Should allow users to cast or update votes for the given proposal
  • May also take a Title prop to display on the component
  • Does not need to be styled (yet)
  • Should handle errors (see the api docs)

Also, see additional requirements in this comment: #96 (comment)

@zenlex
Copy link
Contributor

zenlex commented Mar 9, 2024

This may be implied, but would be lovely for this to work on the index such that as a user I could see all available proposals and vote on them right on the index screen without having to click through to the proposal detail. (In addition to being able to submit/update a vote on a specific proposal from the details page)

@zenlex
Copy link
Contributor

zenlex commented Mar 9, 2024

@helmturner This will also need some type of currentVote optional prop to show the current vote if present for that user won't it?

@helmturner
Copy link
Member Author

Yeah, I limited the scope of this to just a component so that component can be embedded in cards if we choose.

@helmturner This will also need some type of currentVote optional prop to show the current vote if present for that user won't it?

Hmm, maybe—but not with the API as it is. Currently there is no GET /votes or the like, and votes are not returned with proposals by default. Getting vote information for a proposal requires a separate request to GET /proposals/{id}/votes.

The way it's currently designed, it would make sense for the component to fetch the vote totals internally. Do you think we should add an API endpoint for bulk voting data?

@zenlex zenlex added frontend and removed oklathon labels Apr 2, 2024
@helmturner helmturner linked a pull request Apr 28, 2024 that will close this issue
16 tasks
@helmturner
Copy link
Member Author

A couple of clarifications on the spec:

  • The 👍 👎 indicators should only show total vote counts for closed proposals (voting finished)

  • For open (in voting) proposals, they may show the user’s current vote, i.e.:

    • [+1 👍] [ 0 👎] ….(click down *2)….[ 0 👍] [-1 👎]
  • The 👍 👎 buttons may be used to control the radio button value by moving it left or right, but the radio button should be the source of truth for the vote value. If the radio button changes, the 👍 👎 buttons should update their displayed values to reflect that

  • Requests should be debounced such that rapidly changing a vote doesn’t send too many requests to the server

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants