Veto contributions #113
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kredits/kredits-web#113
Reference in New Issue
Block a user
closes #98
@@ -1,5 +1,5 @@{{#each contributions as |contribution|}}<li data-contribution-id={{contribution.id}} class={{if contribution.confirmed "confirmed" "unconfirmed"}}><li data-contribution-id={{contribution.id}} class="{{contribution-status contribution}} {{if contribution.vetoed "vetoed"}}"><p class="meta">This is a bit of a hack. It shouldn't required the
iffor the second class. But apparently with the helper, it doesn't bind the contribution property updates, so the value stays the same after setting the contributionvetoedto true. :/@galfert @fsmanuel Any idea if that's an inherent limitation of helpers, or if I did something wrong?
@@ -1,5 +1,5 @@{{#each contributions as |contribution|}}<li data-contribution-id={{contribution.id}} class={{if contribution.confirmed "confirmed" "unconfirmed"}}><li data-contribution-id={{contribution.id}} class="{{contribution-status contribution}} {{if contribution.vetoed "vetoed"}}"><p class="meta">Mmh, indeed it looks like when passing objects to a helper, it doesn't recalculate when one of the object's properties changes.
I see two options:
Pass the two properties that the helper is using directly as parameters (
contribution-status contribution.vetoed contribution.confirmedAt).Create a component for the contribution (e.g.
contribution-item). This way the component can have a computed property for the class.@@ -1,5 +1,5 @@{{#each contributions as |contribution|}}<li data-contribution-id={{contribution.id}} class={{if contribution.confirmed "confirmed" "unconfirmed"}}><li data-contribution-id={{contribution.id}} class="{{contribution-status contribution}} {{if contribution.vetoed "vetoed"}}"><p class="meta">Thanks!
I think version 2 is better, but that it should be done when refactoring the UI soon. I think we'll want to use something like
ember-boostrapinstead of our handrolled everything, because otherwise we spend too much time re-inventing the wheel for all the various UI components.@@ -1,5 +1,5 @@{{#each contributions as |contribution|}}<li data-contribution-id={{contribution.id}} class={{if contribution.confirmed "confirmed" "unconfirmed"}}><li data-contribution-id={{contribution.id}} class="{{contribution-status contribution}} {{if contribution.vetoed "vetoed"}}"><p class="meta">I like version 2 better as well.
I can not say much about the ember code, but looks good to me.
the UI looks and works great!
@@ -0,0 +7,4 @@kredits: service(),currentBlock: alias('kredits.currentBlock'),compute([contribution]) {can this also be something on the model? (#rubythinking :)
@@ -56,3 +56,4 @@console.debug('[kredits] Using user-provided instance, e.g. from Mist browser or Metamask');ethProvider = new ethers.providers.Web3Provider(web3Provider);// const network = await ethProvider.getNetwork();ethProvider.listAccounts().then(accounts => {we can delete this comment.
@@ -0,0 +7,4 @@kredits: service(),currentBlock: alias('kredits.currentBlock'),compute([contribution]) {No, because you cannot inject services into a model.
@@ -56,3 +56,4 @@console.debug('[kredits] Using user-provided instance, e.g. from Mist browser or Metamask');ethProvider = new ethers.providers.Web3Provider(web3Provider);// const network = await ethProvider.getNetwork();ethProvider.listAccounts().then(accounts => {I left it there intentionally, so that I don't have to look up how to get to the network info of the external provider, and where to do that, when tackling #82. (Was going to do a drive-by PR for that, but defining which network is the right one isn't straight-forward.)
good for me to merge... @galfert?