Skip to content

Conversation

@nechaido
Copy link
Member

@nechaido nechaido commented Aug 9, 2018

Changes:

  • rely on a built-in reconnector;
  • add possibility to specify verboseness level.

@nechaido nechaido added the cli label Aug 9, 2018
@nechaido nechaido requested review from belochub and lundibundi August 9, 2018 16:14
verboseLevel !== VERBOSE_LEVEL.ALL
) {
return;
}
Copy link
Member

Choose a reason for hiding this comment

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

Could you reverse this and add a logging statement instead of return?

lib/cli/cli.js Outdated
const serde = require('../serde');

const VERBOSE_LEVEL = {
NO: 0,
Copy link
Member

Choose a reason for hiding this comment

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

Maybe Quiet?

verboseLevel !== VERBOSE_LEVEL.ALL
) {
return;
}
Copy link
Member

Choose a reason for hiding this comment

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

Same as above.

}

connect(protocol, host, port, app, interfaces, callback) {
this.disconnect(() => {
Copy link
Member

Choose a reason for hiding this comment

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

Does this work? (I expect you to get Not connected error when you manually connect for the first time)

Copy link
Member

Choose a reason for hiding this comment

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

@lundibundi, error is ignored in the callback for the disconnect method here.

Although, I think it's better to make some kind of internal _disconnect method that doesn't check if the connection was established before and call it inside of both connect and disconnect methods. That way you can also avoid additional _connect method creation.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yet one question stands: should we close a connection if the initial connection failed or should we let it reconnect?

I say we close it because this is probably because of an error in address, application name or method name.
@belochub @lundibundi what do you think?

bin/cli.js Outdated
v - print every incoming and outgoing message exept heartbeat messages
vv - print every incoming and outgoing message`,
})
.help()
Copy link
Member

Choose a reason for hiding this comment

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

This is a default value.

bin/cli.js Outdated
alias: 'v',
count: true,
describe: `Level of verboseness:
v - print every incoming and outgoing message exept heartbeat messages
Copy link
Member

Choose a reason for hiding this comment

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

s/exept/except

}

connect(protocol, host, port, app, interfaces, callback) {
this.disconnect(() => {
Copy link
Member

Choose a reason for hiding this comment

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

@lundibundi, error is ignored in the callback for the disconnect method here.

Although, I think it's better to make some kind of internal _disconnect method that doesn't check if the connection was established before and call it inside of both connect and disconnect methods. That way you can also avoid additional _connect method creation.

this.cli.connection.emitRemoteEvent(interfaceName, eventName, args);
this.cli.connection.close();
this.cli.connection = null;
this.cli.connectInitiated = false;
Copy link
Member

Choose a reason for hiding this comment

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

You are not using this field anywhere else.

@belochub
Copy link
Member

belochub commented Aug 10, 2018

We should also provide some kind of option (e.g. --no-reconnect with -r as an alias) to allow users to disable the default reconnector.

EDIT: Adding heartbeat interval option may be useful as well.

@lundibundi
Copy link
Member

@belochub +1, but I think we can do that in follow-up PR. Also -r seems like it actually enables reconect, I'd suggest -R for negative aliases or not have this alias at all.

lundibundi
lundibundi previously approved these changes Aug 10, 2018
@belochub
Copy link
Member

@lundibundi, yeah, -R is even better.

lib/cli/cli.js Outdated

this.client = { logger };
} else {
this.client = null;
Copy link
Member

Choose a reason for hiding this comment

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

You can avoid this branch completely if you set this.client to an empty object before this if.

Copy link
Member

@belochub belochub left a comment

Choose a reason for hiding this comment

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

@nechaido, sorry, but I forgot that you also have to move yargs from devDependencies to regular dependencies.

bin/cli.js Outdated
alias: 'i',
type: 'number',
default: 0,
describe: 'Heartbeat interval in miliseconds',
Copy link
Member

Choose a reason for hiding this comment

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

s/miliseconds/milliseconds

bin/cli.js Outdated
args = commandLineArgs(options, { camelCase: true });
} catch (error) {
console.error(error.message);
printHelp();
Copy link
Member

Choose a reason for hiding this comment

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

I don't think it should exit with code 0 when an error occurs during argument parsing.

bin/cli.js Outdated
},
];

const printHelp = () => {
Copy link
Member

Choose a reason for hiding this comment

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

Maybe printHelpAndExit will be a more informative name for this function?

bin/cli.js Outdated
printHelp();
}

if (args.help || args.heartbeatInterval === null) {
Copy link
Member

Choose a reason for hiding this comment

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

When heartbeatInterval is equal to null it should print some kind of an error message to tell the user that he is using it wrong, and it should exit with a non-zero code in that case.

lib/cli/cli.js Outdated
this.client.logger.on('outgoingMessage', (message) => {
if (
(!message.pong && !message.ping) ||
options.verbose === VERBOSE_LEVEL.ALL
Copy link
Member

Choose a reason for hiding this comment

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

I don't see where the verbose field is converted into a number in this implementation, thus it seems like you are checking for equality of a number and an array here, which will never evaluate to true.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed.

bin/cli.js Outdated
header: 'JSTP CLI client',
},
{
header: 'Options',
Copy link
Member

Choose a reason for hiding this comment

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

What do you think about changing it to 'Available options'?

bin/cli.js Outdated
},
{
header: 'Options',
optionList: [
Copy link
Member

Choose a reason for hiding this comment

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

You can use the options array here if you move description and typeLabel fields there.

Copy link
Member

@lundibundi lundibundi left a comment

Choose a reason for hiding this comment

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

I don't think the fact that -help and --h are valid options (as this I assume the main reason for change) is worth changing the yargs to this library considering the verboseness and unsightliness (compared to yargs) of the new implementation.

Main points:

  • try/catch with args parsing (this should be handled internally)
  • no single-site to look at the options (options and their description is spread across options, usage and even arg checks later)
  • manual checking for invalid args (if (args.help || args.heartbeatInterval === null) {)
  • manual help checking/providing

I'd much rather have that slight deficiency with full and short option parsing than this lot of other things to deal with.

@nechaido
Copy link
Member Author

+1 to @lundibundi.

@lundibundi lundibundi dismissed their stale review August 15, 2018 14:33

Outdated

@belochub
Copy link
Member

@lundibundi, as an option, we can use cla-complete package, which just combines command-line-args and command-line-usage packages and handles parsing exceptions, but I don't think that it's really required here since such package can be created in minutes and we have only one CLI application to use it with, meaning we can easily write this ourselves and there is no need to abstract it now.
As to the other points of your review, I think these couple of libraries are more flexible in terms of possible configuration and usage in some parts, and, as a result, using them will be more verbose (and requiring some manual checks), than using yargs.

lib/cli/cli.js Outdated
(!message.pong && !message.ping) ||
options.verbose === VERBOSE_LEVEL.ALL
) {
this.log(`Outgoing message:\n${serde.stringify(message)}`);
Copy link
Member

Choose a reason for hiding this comment

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

Must be "Incoming message" here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed.

bin/cli.js Outdated
}

if (args.heartbeatInterval === null) {
console.log('You must specify hearbeat interval');
Copy link
Member

Choose a reason for hiding this comment

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

s/hearbeat/heartbeat

Copy link
Member

Choose a reason for hiding this comment

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

Also, use console.error here, please.

bin/cli.js Outdated
name: 'heartbeat-interval',
alias: 'i',
type: Number,
default: 0,
Copy link
Member

Choose a reason for hiding this comment

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

The correct name of this property seems to be defaultValue.
Although I am not quite sure if we even need to use this property anywhere.

@nechaido nechaido requested a review from lundibundi August 15, 2018 19:15
lib/cli/cli.js Outdated
const utils = require('./utils');
const serde = require('../serde');

const VERBOSE_LEVEL = {
Copy link
Member

Choose a reason for hiding this comment

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

maybe VERBOSENESS_LEVEL or just VERBOSENESS? Though as you want.

Copy link
Member

@lundibundi lundibundi left a comment

Choose a reason for hiding this comment

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

I still think that we (or at least I) don't want to support code that should've been handled inside of the cli-args library.
Based on @nechaido comment I think that's at least 2 people who think that using yargs is better.
Therefore I'd want to discuss this in person or at least get @aqrln opinion on this here.
It's not a PR that needs to be landed asap so I think it can wait for a few more days.

@nechaido
Copy link
Member Author

nechaido commented Aug 16, 2018

@lundibundi, as a matter of fact, it is a PR that must be landed ASAP. so that it is shipped with metarhia-jstp@2.

@belochub
Copy link
Member

@lundibundi, as I said before, we can use cla-complete package instead of handling some of the things here, that way the code that you don't want to support will be "handled inside of the cli-args library", it's just going to be another library.

If the aforementioned package isn't good enough in your opinion, I can create another one, and just copy some of the code written by @nechaido in this PR into it, so that it will be handled inside the other package and not this one. That way you don't have to support the code that you don't want to support.

@lundibundi
Copy link
Member

@belochub and there will be one more package to support, that you will have to update and test somehow. And most likely still not as good looking as yargs.
To sum it up, if @nechaido and/or @aqrln agree that it's okay to have this instead of just using yargs I'll not object, as this will be better than having our own/your another package to support. (You can probably discuss it with them in person and just post the result/land it if it's okay)

@belochub
Copy link
Member

@lundibundi, like I said, if you want the package that will handle the things you don't want to handle here, we can either use the cla-complete package or create another package with similar functionality.

there will be one more package to support

I don't understand, can you, please, explain what this other package to support will be?

you will have to update and test somehow

We don't have any tests for the cli at the moment.

Copy link
Member

@lundibundi lundibundi left a comment

Choose a reason for hiding this comment

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

LGTM. Also, there is

this.cli.connectInitiated = true;
do we still need to set it?

bin/cli.js Outdated
describe: 'Heartbeat interval in milliseconds',
}).argv;

console.log(args);
Copy link
Member

Choose a reason for hiding this comment

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

Do we need it here?

callback(new Error(`Unknown protocol '${protocol}'`));
return;
}
this.cli.connectInitiated = true;
Copy link
Member

Choose a reason for hiding this comment

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

You should probably remove this line as well.

bin/cli.js Outdated
count: true,
describe: 'Verbosely print incoming and outgoing messages',
})
.options('no-reconnect', {
Copy link
Member

Choose a reason for hiding this comment

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

It is options method here and option methods for 'verbose' and 'heartbeat-interval', is there a difference, or is this just a typo?

Copy link
Member

Choose a reason for hiding this comment

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

After taking a look at yargs documentation, it seems that the options method has a different contract, requiring to provide the object with options descriptions as a single argument, meaning that the way you use that method here is incorrect.

bin/cli.js Outdated
const args = yargs
.option('verbose', {
alias: 'v',
count: true,
Copy link
Member

Choose a reason for hiding this comment

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

Why do you use count option here and not type like in other options definitions?

Copy link
Member Author

Choose a reason for hiding this comment

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

I need to use count so that when you pass -vv, verbose will be equal to 2. I do not use type here because this option does not have any value associated with but instead, we simply count the number of occurrences of this option.

Copy link
Member

Choose a reason for hiding this comment

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

I meant that you could've provided type: 'count' option instead of using count option, to make it consistent with other options definitions.

bin/cli.js Outdated
requiresArg: true,
type: 'number',
describe: 'Heartbeat interval in milliseconds',
}).argv;
Copy link
Member

Choose a reason for hiding this comment

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

In my opinion, we should also use strict() here.

Changes:
* rely on a built-in reconnector;
* add possibility to specify verboseness level.
belochub pushed a commit that referenced this pull request Aug 23, 2018
* Rely on a built-in reconnector.
* Add possibility to specify verboseness level.

PR-URL: #366
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Mykola Bilochub <nbelochub@gmail.com>
@belochub
Copy link
Member

Landed in ecf375d.

@belochub belochub closed this Aug 23, 2018
@belochub belochub deleted the fix-cli branch August 23, 2018 12:20
belochub pushed a commit that referenced this pull request Aug 30, 2018
* Rely on a built-in reconnector.
* Add possibility to specify verboseness level.

PR-URL: #366
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Mykola Bilochub <nbelochub@gmail.com>
@belochub belochub mentioned this pull request Aug 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants