search

mesg-foundation / js-sdk

Javascript mono-repo with all the tools to interact with MESG
https://mesg.com
4 stars 4 forks source link

Ux cli desing improvment/errors #9

Closed krhubert closed 4 years ago

krhubert commented 5 years ago 
./bin/run --passphrase=1234 account:create
 ›   Warning: --passphrase=1234 is not a mesg-cli command.
Did you mean account:export? [y/n]: ^C
./bin/run account:create --passphrase=1234
 ›   Error: Unexpected argument: --passphrase=1234
 ›   See more help with --help
$./bin/run marketplace:publish -a 0x00bfd8604654210a52833fdf946d5c78f13e4ffc ../test-service
 ›   Error: Unexpected arguments: 0x00bfd8604654210a52833fdf946d5c78f13e4ffc, ../test-service
 ›   See more help with --help
$ ./bin/run marketplace:publish ../test-service -a 0x00bfd8604654210a52833fdf946d5c78f13e4ffc                
 ›   Error: Unexpected arguments: -a, 0x00bfd8604654210a52833fdf946d5c78f13e4ffc
 ›   See more help with --help
antho1404 commented 5 years ago
krhubert commented 5 years ago

: - a suggestion for invalid command is displayed only for few seconds oclif/plugin-not-found#29

I think you can't expect issue solving from on repository with 3 stars when the last commit was in 2018

: - parse flags fails when given before arguments => this works for me eg: mesg-cli-dev service:logs --tail=1 J7ot3GBb3y4mWMwRqwSMnsFkui27Nen13Gr97N7DLVbK only get the last log

try

./bin/run service:execute -d=s=test -d=n=3.14 <HASH> <TASK>

: - remove --silent option and leave only -q|--quiet or vice versa => silent doesn't display anything where quiet only displays important informations (just the result usually). Silent is used when we call internally other commands. Could be an hidden flag

I think quiet is enough - I don't see any reason why someone may want to hide importantly info

: - print default value for argument/flag after the description, not before => where?

: - print required info for argument/flag after the description, not before => where?

./bin/run service:dev -h             
Run your service in development mode

USAGE
  $ mesg-cli service:dev [SERVICE_PATH]

ARGUMENTS
  SERVICE_PATH  [default: ./] Path of the service 
                        ^^^^ HERE - should go last (same for required)

daemon:logs - print logs from the begging, but should print from moment it was called (and in general should have more flags like service:logs has) => no reason to have the no-event/no-result this is just log and have the tail and [no]follow. Also logs display everything by default from the beginning (eg: docker)

of course I'm not talking about no-event/result but tail and follow

service:list - flag descirption --sort=sort - key should be renamed to column => Not really, this is a sort so not only the column, you can do -column or +column to change the order

Ok get it, so =sort value dosen't tell the story, maybe --sort=expression

service:list - support --cvs format but cli dosen't need it, do it? => no it's just out of the box but can be removed if it's a problem to have that

the question is why to have it? we can include csv, yaml, hcl anything but someone might be thinking why I need csv.

service:list - no support --json => you have the csv ;) haha

haha xD

service:list - flag --no-truncate does not work => reduce the size of your terminal and you will see it works on the table

I did and it doesn't work - this is why I have added this test.

service:dev - hit ctrl+c when service run a long time or on engine exit => don't undestand this one

I forgot to paste an error:

(node:12917) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added. Use emitter.setMaxListeners() to increase limit

servcie:compile - missing option --oneline for printing json as one liner => | jq -c .

Yes, I know there is jq, but jq is not installed on os by default, and in js print json as oneline is easy.

service:logs - --no-follow flag does not work => this flag works for the logs from docker not the event/result fot this use --no-results --no-events so for absolutely no follow at all `--no-follow --no-results --no-events

service:logs - --no-tail flag does not work => same, works on the logs from docker

If it dosen't work then it should be removed, does it?

account:* - try to invoice command with --help flag passed at the end (last one) - should display help message => this works for me

try with delete and short -h option

$ ./bin/run account:delete -h
Delete account... ?
Type your passphrase: 
Delete account... !
$ ./bin/run account:delete --help
Delete an existing account

USAGE
  $ mesg-cli account:delete ADDRESS

OPTIONS
  -h, --help               show CLI help
  -q, --quiet
  --passphrase=passphrase  (required) Passphrase to unlock your account
  --silent

account:list - has the same issues as servcie:list - columns/sort/no-truncate/extended` => so same answer

So the same answer as above :)

instance:* - missing commands to manage instances - service:start|service:stop|service:logs should be moved under instance command => the cli doesn't need to be a 1:1 matching to the api, the goal is that users don't need to know how it works internally, it's easier to explain that they can start a service than having to explain the concept of service + instance and especially when to use wich one. service:start/stop is more userfriendly

Without instance is like trying to explain how to run docker image without a concept of containers (running instance of image). And you have also commands for remove docker image and docker contaiener, not just one of it.

The point here is not to be 1:1 with api. User has to know the concept of the instance (for example you have instances column in service:list api) to use the engine. User will have to distinguish between instance and service hash (for example service:stop requires instance-hash, while service:delete requires service-hash), start will give you instance-hash in return.

So the point is not to have cli with 1:1 api, but rather having instance is more user-friendly than just leave the only service because it's confusing that few service commands requires instance hash and other few service hash. You just can't hide/ignore the existence of instance, especially if you require instance hash in cli.

NicolasMahe commented 5 years ago
krhubert commented 5 years ago 
➜  cli git:(master) ✗ ./bin/run service:execute AyroMeHmBzmvUSAJ2d9LPUHdYfmPsMgdocNRAkYeN6F9 foo 
 ›   Error: Cannot read property 'find' of undefined
antho1404 commented 5 years ago

@krhubert please create a new issue for that, let's not continue to populate that one which is way too long and close to impossible to work on

krhubert commented 5 years ago

This is still a valuable list of ux improvements and the one I've posted belongs to the issue.

There are still almost 30 issues that haven't been solved until today (over 2 months). So I guess if they haven't solved yet there is no priority to do them.

I don't see how splitting them to separate issues will make it possible to work on them. It will be rather hard to manage such amount of issues about ux.

antho1404 commented 5 years ago

some of these issues are invalid and we cannot track this in one single issue also others need to do more testing because or are actually working correctly. But it's almost impossible to track this correctly with one single issue that references ~50 issues. Let's not continue to populate this list and use the system that Github provides exactly for this.

antho1404 commented 4 years ago

Issue migrated to liteflow-labs/liteflow-js#22