Supporting a proposal

[oliverbarnes]

As a participant
I want to support proposals by other participants

When viewing a proposal not his own, a participant sees a "Support this" button. When clicking on it, the button should change in some way to signify it's "on" somehow. Or maybe the proposal itself could have a visual cue that it's supported?

• [ ] Define UX

[oliverbarnes]

There should also be a support count, updated when support is added

[oliverbarnes]

API endpoint done, payloads look like this:

Request

{
  "data": {
    "type": "support",
    "relationships": {
      "proposal": {
        "data": {
          "id": "1",
          "type": "proposal"
        }
      }
    }
  }
}

Response

{
  "data": {
    "id": "1",
    "type": "support",
    "attributes": {},
    "relationships": {
      "proposal": {
        "data": {
          "type": "proposal",
          "id": "1"
        }
      }
    }
  },
  "included": [
    {
      "type": "proposal",
      "id": "1",
      "attributes": {
        "support-count": 1
      }
    }
  ]
}

[tnum]

The mockups have a toggle switch as it is clear to see if the switch is 'on'. I also suggested 'tick' icons in the proposal listing view to indicate which proposals are being supported - although it may make the listings view too "cluttered"

[oliverbarnes]

Something bothers me about the switch widget, I don't think it works... It reminds me of settings, of stuff that you need to be very careful before switching on. While It needs to be very inviting and easy to click.

Once clicked, both the button and the proposal itself should change satisfyingly - you've embraced the proposal, afterall. Maybe a border could show up around the proposal?

I think the green tick on supported proposals works, and green makes sense as the color for the 'supported' state.

Once we get to counter-proposals, there could be an equivalent fat button for 'counter-proposal', as an alternative to the 'support' button. And with delegations, the delegation button would be a mid-way alternative, somehow.

[oliverbarnes]

• [x] handle "supported by me" scenario
• [x] handle "proposed by me" scenario (where current user then cannot suport her own proposal)

[ThomasWeiser]

Current state 7aa68e25e4b48a7ee53b61140d506aebaafd532f is the result of a pairing session with @oliverbarnes.

We agreed that the backend should indicate whether a proposal is supported by the current user. This supported-by-me flag should be an attribute of every proposal resource in a response. See https://github.com/oliverbarnes/participate-api/issues/27

(Edit: Didn't see you already mentioned "supported by me" above.)

[oliverbarnes]

authored-by-me and supported-by-me attributes added on https://github.com/oliverbarnes/participate-api/pull/30 and https://github.com/oliverbarnes/participate-api/pull/32

[ThomasWeiser]

Please review the PR.

Done:

• Decoding and storing authored-by-me and supported-by-me
• Use these flags to reflect the state on the support button
• Decode the response from POST /support and store the state in the model without reloading the proposal resource

API usage depends on oliverbarnes/participate-api#33

Will implement removing support (#24) afterwards as a separate PR.

[oliverbarnes]

Looks good. I didn't have time to test it yet, I'm assuming it was thoroughly tested before asking for the review? ;)

[ThomasWeiser]

Yes, I've tested it. Nonetheless, should soon start with automatic testing #49.