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

Factory routine to create a new unattached argument #1497

Merged
merged 6 commits into from Apr 12, 2021
Merged

Factory routine to create a new unattached argument #1497

merged 6 commits into from Apr 12, 2021

Conversation

cravler
Copy link
Contributor

@cravler cravler commented Apr 7, 2021

No description provided.

@shadowspawn
Copy link
Collaborator

shadowspawn commented Apr 7, 2021

Thanks. We have a rich pattern for Command then Option to follow! Not much to customise yet, but I do want to follow the same patterns.

@shadowspawn
Copy link
Collaborator

shadowspawn commented Apr 7, 2021

(I saw from a deleted commit that we missed the esm export too.)

@shadowspawn
Copy link
Collaborator

shadowspawn commented Apr 7, 2021

(Sorry, I should have waited to see if the ESM tweaks were coming back! 😊 )

@shadowspawn shadowspawn changed the base branch from feature/argument to release/8.x Apr 8, 2021
@shadowspawn shadowspawn changed the base branch from release/8.x to feature/argument Apr 8, 2021
Copy link
Collaborator

@shadowspawn shadowspawn left a comment

LGTM

@shadowspawn
Copy link
Collaborator

shadowspawn commented Apr 8, 2021

(This will land on release/8.x.)

@abetomo
Copy link
Collaborator

abetomo commented Apr 8, 2021

It would be better if you also update typings/index.d.ts.

@shadowspawn
Copy link
Collaborator

shadowspawn commented Apr 8, 2021

(I'll add some tests too, but I can do the tests afterwards.)

@cravler cravler changed the base branch from feature/argument to release/8.x Apr 8, 2021
@cravler cravler changed the base branch from release/8.x to feature/argument Apr 8, 2021
@cravler cravler changed the base branch from feature/argument to release/8.x Apr 9, 2021
@shadowspawn
Copy link
Collaborator

shadowspawn commented Apr 10, 2021

(Added TypeScript and tests in a PR to the PR.)

…e-for-argument

Add TypeScript and tests for createArgument
Copy link
Collaborator

@abetomo abetomo left a comment

Thanks!

@shadowspawn shadowspawn merged commit 387b6fc into tj:release/8.x Apr 12, 2021
9 checks passed
@cravler cravler deleted the feature/factory-routine-for-argument branch Apr 12, 2021
*/

createArgument(name, description) {
return new Argument(name, description);
Copy link
Contributor

@Niryo Niryo Apr 12, 2021

Choose a reason for hiding this comment

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

What are the benefits of adding this factory when you can use new Argument() directly?

Copy link
Collaborator

@shadowspawn shadowspawn Apr 12, 2021

Choose a reason for hiding this comment

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

The main purpose is so you can override the method and return a custom subclass of Argument, which will be used to create the arguments added by Command methods .argument() and .arguments() and .command('sub <file>').

This factory pattern was first offered with .createCommand() where it is more likely to be used, but offering the same pattern for Option and now Argument.

Copy link
Contributor

@Niryo Niryo Apr 12, 2021

Choose a reason for hiding this comment

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

But why will you want to override the createArgument method when you can just pass any custom Argument class to addArgument?
Also, in order to create custom argument, you need to somewhat know the internals of the Argument class (in both the factory solution and the direct solution), so it sounds like a bad practice and a doc bloater, for probably a really rare use case. Instead of adding this factory to keep the the api aligned, I would consider removing all other factories...

Copy link
Collaborator

@shadowspawn shadowspawn Apr 12, 2021

Choose a reason for hiding this comment

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

.createCommand() was the first one added in #1191 to make Command more subclass friendly. .createHelp() was added in major help refactor in #1365.

.createOption() was added in #1380 to follow the pattern. We had established a tidy pattern for Command which also worked for Help, so following through and offering same support for Option.

in order to create custom argument, you need to somewhat know the internals of the Argument class

Yes, that is implicit in writing a subclass.

I did consider whether to directly support subclassing at all for Command, but it a useful approach for extending functionality especially in custom cases which are not common use cases and would not be integrated into Commander itself.

@shadowspawn shadowspawn added the pending release label Apr 13, 2021
@shadowspawn shadowspawn added this to the v8.0.0 milestone Apr 13, 2021
@shadowspawn shadowspawn removed the pending release label Jun 25, 2021
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.

None yet

4 participants