Comments (8)
-
*:*
- 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 -
*:*
- 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 -
*:*
- print default value for argument/flag after the description, not before
=> where? -
*:*
- print required info for argument/flag after the description, not before
=> where? -
daemon:logs
- print logs from the begging, but should print from moment it was called (and in general should have more flags likeservice: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) -
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 -
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 -
service:list
- no support--json
=> you have the csv ;) haha -
service:list
- flag--no-truncate
dose not work
=> reduce the size of your terminal and you will see it works on the table -
service:dev
- hit ctrl+c when service run a long time or on engine exit
=> don't undestand this one -
servcie:compile
- missing option--oneline
for printing json as one liner
=>| jq -c .
-
servcie:compile
- no option for getsource
from ipfs
=> we don't need, we need to compile an actual source code, if your source code is on ipfs then you can use ipfs gateway and this will work -
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 -
account:*
- try to invoce command with--help
flag passed at the end (last one) - should display help message
=> this works for me -
account:list
- has the same issues asservcie:list
- columns/sort/no-truncate/extended`
=> so same answer -
instance:*
- missing commands to manage instances - service:start|service:stop|service:logs should be moved underinstance
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
from js-sdk.
: - 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.
from js-sdk.
- service:logs should return an error if not docker services/containers match the hash
from js-sdk.
- service:execute - better error on non existing task
➜ cli git:(master) ✗ ./bin/run service:execute AyroMeHmBzmvUSAJ2d9LPUHdYfmPsMgdocNRAkYeN6F9 foo
› Error: Cannot read property 'find' of undefined
from js-sdk.
@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
from js-sdk.
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.
from js-sdk.
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.
from js-sdk.
Issue migrated to liteflow-labs/liteflow-js#22
from js-sdk.
Related Issues (20)
- Publish LCD port on daemon:start
- Add account generation
- Simulate transaction before broadcasting HOT 2
- MESG Framework HOT 1
- Save state of deployment in the CLI HOT 1
- Improve publish resources to testnet HOT 4
- Improve message when closing a stream HOT 1
- Update process compilation to add new filter functionalities HOT 1
- When the command `service:dev` throws an error, the engine is not stopped and the next use of `service:dev` doesn't stop the engine and the running service: HOT 4
- Move runner management to the CLI
- Add cleanup command HOT 1
- Support of complex types for filters (array, object) HOT 1
- Support any ancestor for references in filter conditions HOT 1
- bug on event and result logs when data is null
- Display runner hash in commands HOT 1
- Fix tests on macOS HOT 1
- Improve error when email is not correctly formated HOT 1
- Change container name in runner lib
- Command dev should be compatible with relative path for services from app folder HOT 1
- Return type of query is wrong HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from js-sdk.