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

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

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

@shadowspawn
Copy link
Collaborator

(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 April 8, 2021 07:22
@shadowspawn shadowspawn changed the base branch from release/8.x to feature/argument April 8, 2021 07:23
Copy link
Collaborator

@shadowspawn shadowspawn left a comment

Choose a reason for hiding this comment

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

LGTM

@shadowspawn
Copy link
Collaborator

(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

(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 April 8, 2021 07:52
@cravler cravler changed the base branch from release/8.x to feature/argument April 8, 2021 08:21
@cravler cravler changed the base branch from feature/argument to release/8.x April 9, 2021 11:07
@shadowspawn
Copy link
Collaborator

(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

Choose a reason for hiding this comment

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

Thanks!

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

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

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

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

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 Merged into a branch for a future release, but not released yet label Apr 13, 2021
@shadowspawn shadowspawn added this to the v8.0.0 milestone Apr 13, 2021
@shadowspawn shadowspawn removed the pending release Merged into a branch for a future release, but not released yet 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