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

R4R: Address gov cli ux issues and add additional input validation for better errors #2938

Merged
merged 12 commits into from
Dec 3, 2018

Conversation

jackzampolin
Copy link
Member

  • Targeted PR against correct branch (see CONTRIBUTING.md)

  • Linked to github-issue with discussion and accepted design OR link to spec that describes this work.

  • Wrote tests

  • Updated relevant documentation (docs/)

  • Added entries in PENDING.md with issue #

  • rereviewed Files changed in the github PR explorer

@jackzampolin
Copy link
Member Author

cc @sunnya97

@codecov
Copy link

codecov bot commented Nov 29, 2018

Codecov Report

Merging #2938 into develop will decrease coverage by 0.46%.
The diff coverage is 0%.

@@             Coverage Diff             @@
##           develop    #2938      +/-   ##
===========================================
- Coverage    56.19%   55.72%   -0.47%     
===========================================
  Files          120      120              
  Lines         8383     8468      +85     
===========================================
+ Hits          4711     4719       +8     
- Misses        3350     3427      +77     
  Partials       322      322

@alessio
Copy link
Contributor

alessio commented Nov 29, 2018

@jack rebase on top of develop please - the test failures will eventually go

@jackzampolin jackzampolin changed the title WIP: Address gov cli ux issues and add additional input validation for better errors R4R: Address gov cli ux issues and add additional input validation for better errors Nov 29, 2018
x/gov/client/cli/query.go Outdated Show resolved Hide resolved
x/gov/client/cli/query.go Outdated Show resolved Hide resolved
x/gov/client/cli/query.go Outdated Show resolved Hide resolved
amount, err := sdk.ParseCoins(proposal.Deposit)
if err != nil {
return err
}

// ensure account has enough coins
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't wrong, but it's a weird way to write this logic - we shouldn't be doing this in CLI commands generally, we should be simulating transactions and displaying the error to the user before broadcasting them (if the simulation failed).

If we simulate a submit-proposal transaction with not enough sender balance, it should fail.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I copied this pattern from the x/auth/client/cli/sign.go. Is there a place where this pattern is shown? The code in this PR fixes some really bad errors and UX in the governance and I works well in the current form.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed, fine for now, let's fix the root cause though (separately) - #2953

x/gov/client/cli/tx.go Outdated Show resolved Hide resolved
if err != nil {
return err
}

msg := gov.NewMsgDeposit(depositorAddr, proposalID, amount)
// ensure account has enough coins
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above (we should simulate instead).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above

cwgoes and others added 4 commits November 29, 2018 13:05
Co-Authored-By: jackzampolin <jack.zampolin@gmail.com>
Co-Authored-By: jackzampolin <jack.zampolin@gmail.com>
Co-Authored-By: jackzampolin <jack.zampolin@gmail.com>
Co-Authored-By: jackzampolin <jack.zampolin@gmail.com>
Copy link
Collaborator

@fedekunze fedekunze left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these new commands look all very confusing (see comments). IMHO the even worsen the current implementation's UX. Also there's no issue with a proposal that's been discussed and accepted.

x/gov/client/cli/query.go Show resolved Hide resolved
cmd/gaia/cli_test/cli_test.go Show resolved Hide resolved
cmd/gaia/cli_test/cli_test.go Show resolved Hide resolved
x/gov/client/cli/query.go Show resolved Hide resolved
@jackzampolin
Copy link
Member Author

Here are a couple of issues around the UX on the gov CLI addressed by this PR:

And here is one endorsing the use of positional arguments (which links to one about required flags):

If there are one or two required arguments I don't think its confusing (especially if the documentation is accurate and helpful, which the help text is). It may be confusing the first time the user uses the tool, but it's a HUGE improvement for anyone who uses the tool more than once (the users we care about). It also makes commands much more realistic to type in.

Also we have WAY too many flags in the current CLI and this eliminates some of them.

@alessio
Copy link
Contributor

alessio commented Nov 30, 2018

I think docs require update

@fedekunze
Copy link
Collaborator

Here are a couple of issues around the UX on the gov CLI addressed by this PR:

Thanks for the clarification, you forgot to mention those on the description and updating PENDING.md, so there was no clear issue which was being resolved/addressed by this PR.

If there are one or two required arguments I don't think its confusing (especially if the documentation is accurate and helpful, which the help text is) ...

Also we have WAY too many flags in the current CLI and this eliminates some of them.

Indeed the docs are accurate, but switching to args just because we have too many flags is not a great solution imo. If we want it to be descriptive and objective about the args we should stick with flags. Users can use shorthands for flags if they are tired of writing the full name

@jackzampolin
Copy link
Member Author

Because 1/2 of the commands changed here required 1 flag: --proposal-id which doesn't have a short example and works just as well as a positional argument. The other 1/2 require --proposal-id and an address. I think this works just as well as positional arguments. I haven't changed commands like submit-proposal that require a number of flags.

Also may of these "required" flags we not Required by our code causing bad user experience issues.

Copy link
Collaborator

@fedekunze fedekunze left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK. Minor comments to keep consistency with the cmds descriptions

docs/gaia/gaiacli.md Outdated Show resolved Hide resolved
docs/gaia/gaiacli.md Outdated Show resolved Hide resolved
gaiacli query gov tally <proposal_id>
```

#### Query governance parameters
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++ thanks !

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

d'accord!

fedekunze and others added 2 commits December 3, 2018 12:29
Co-Authored-By: jackzampolin <jack.zampolin@gmail.com>
Co-Authored-By: jackzampolin <jack.zampolin@gmail.com>
@jackzampolin jackzampolin merged commit 886bd35 into develop Dec 3, 2018
@jackzampolin jackzampolin deleted the jack/gov-cli-fixes branch December 3, 2018 20:48
mircea-c pushed a commit that referenced this pull request Dec 5, 2018
…ter errors (#2938)

* Fix governance cli ux issues and add additional transaction validation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants