Gracefully handle pending changes for contributions #159
Reference in New Issue
Block a user
Delete Branch "feature/pending_changes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This adds the pending tx data to pending contributions (after adding or vetoing, until the tx is mined). It also disables the veto button while pending.
WIP until I've added the same for contributor additions/changes. Also, it's branched out from #156,
which hasn't been merged yet.closes #120
Looking for reviews now. Doing contributors in a separate PR.
Why does this property need to be volatile?
I thought that's just how you do computed properties without dependency now (as someone told me about this). Already thought it doesn't sound right, when the property never changes, but haven't looked it up.
@galfert Does your comment mean that you took this for a spin?
No, marking a property as volatile just deactivates caching and makes it recalculate on every access. It also prevents property notifications.
The
volatile()modifier got deprecated recently. So I think just using an empty string as the dependency would be better here.I only looked at the code. Besides my one comment it looked ok to me.
Could you please test it?
(If you still have trouble running this easily on your machine, then you need to tell us that. Everything should work in a way that it's very easy to test now.)
Note to whoever didn't use this feature before: in order to get longer, more realistic confirmation times from your dev chain, you can add
block-timeto thedevchainnpm script, like so:I tested the PR and confirmed everything to work.
I fixed the merge conflict and changed the
confirmation-statushelper to detect the pending changes. I also removed thevolatile()property modifier everywhere, as it was already throwing a deprecation warning.