Motivation: simplify the usage pattern, and wrap Liquidvoting api calls together with the updating of the vote counter.
This moves all calls to the four api mutators out of controllers and commands, and into the Decidim::Liquidvoting module meant to centralise this kind of thing. So all calls to do Liquidvoting things now look like Liquidvoting.some_method, and ApiClient is fully wrapped there.
It additionally moves the proposal vote count update into the same wrapper calls, further simplifying the controllers and commands, and insuring that the api call doesn't happen without the vote update (it was not happening for delegations, see below).
Here's the old and new usage pattern (here, for create_vote, in the VoteProposal command):
The specs for the new methods in Decidim::Liquidvoting focus on behavior, not state; no attempt is made to validate api results for example. Instead, we just assert that the new wrapper methods 1) send the appropriate message to ApiClient with the correct arguments, and 2) send a Proposal#proposal_votes_count message with the expected value.
I tackled this now so that further integration work (endorsements, etc) can copy the new pattern (or whatever new pattern comes out of this review).
Closes #95
To update the vote count on create_delegation, I had to change the api response in the graphql query (now all modifiers return a voting_result), and also the api client response (which was systematically returning true).
Additionally, the create/destroy delegations were not recording the new vote count in the proposal; that is fixed here.
Motivation: simplify the usage pattern, and wrap Liquidvoting api calls together with the updating of the vote counter.
This moves all calls to the four api mutators out of controllers and commands, and into the
Decidim::Liquidvotingmodule meant to centralise this kind of thing. So all calls to do Liquidvoting things now look likeLiquidvoting.some_method, andApiClientis fully wrapped there.It additionally moves the proposal vote count update into the same wrapper calls, further simplifying the controllers and commands, and insuring that the api call doesn't happen without the vote update (it was not happening for delegations, see below).
Here's the old and new usage pattern (here, for
create_vote, in theVoteProposalcommand):The specs for the new methods in
Decidim::Liquidvotingfocus on behavior, not state; no attempt is made to validate api results for example. Instead, we just assert that the new wrapper methods 1) send the appropriate message toApiClientwith the correct arguments, and 2) send aProposal#proposal_votes_countmessage with the expected value.I tackled this now so that further integration work (endorsements, etc) can copy the new pattern (or whatever new pattern comes out of this review).
Closes #95
To update the vote count on
create_delegation, I had to change the api response in the graphql query (now all modifiers return avoting_result), and also the api client response (which was systematically returningtrue).Additionally, the create/destroy delegations were not recording the new vote count in the proposal; that is fixed here.
Resolves #94