Skip to content
This repository has been archived by the owner on May 17, 2024. It is now read-only.

Add subdomain field support to CLI apps #26

Merged
merged 3 commits into from
Sep 5, 2017
Merged

Conversation

eliangcs
Copy link
Member

@eliangcs eliangcs commented Sep 4, 2017

Copy link
Contributor

@BrunoBernardino BrunoBernardino left a comment

Choose a reason for hiding this comment

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

Great job @eliangcs !

I'm requesting changes because I'd like to see the field added to the examples and antiExamples (that runs in the tests).

Other than that I've got a couple of questions on terminology and syntax, basically.

@@ -101,6 +101,10 @@ module.exports = makeSchema({
description: 'Does the value of this field affect the definitions of other fields in the set?',
type: 'boolean',
},
inputFormat: {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wondering if we should remove the , from the inputFormat value (because while it simplifies for the backend, there's no real justification for it in this "public-facing" place. It's arguably cleaner if it was just https://{{subdomain}}.yourdomain.com/, and since it applies to subdomain only, should this field name be subdomainFormat instead of inputFormat?)

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 feel that inputFormat could do more than just subdomain, so I've changed the description to be more general.

Copy link
Contributor

Choose a reason for hiding this comment

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

Makes sense!

@@ -101,6 +101,10 @@ module.exports = makeSchema({
description: 'Does the value of this field affect the definitions of other fields in the set?',
type: 'boolean',
},
inputFormat: {
description: 'Really only useful for subdomain type. This allows the user to specify a comma-separated string like "https://,{{input}},.yourdomain.com/".',
type: 'string',
Copy link
Contributor

Choose a reason for hiding this comment

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

If we can make this type: 'subdomain', we should be able to add some validation where it then requires inputFormat. Do you think it's an overkill to have it that much explicit?

@eliangcs eliangcs force-pushed the cli-subdomain-field branch from 644bc88 to b25b005 Compare September 5, 2017 06:13
@eliangcs
Copy link
Member Author

eliangcs commented Sep 5, 2017

@BrunoBernardino thanks for your review! I've pushed two commits (b25b005 and 11cb76e) with improvements and tests. Please leave feedback. Thanks!

Copy link
Contributor

@BrunoBernardino BrunoBernardino left a comment

Choose a reason for hiding this comment

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

Looks great @eliangcs! Thank you so much for the changes, I feel we've got an even better solution now.

I didn't pull this down and run it locally because it seems straightforward enough.

:shipit:

@eliangcs eliangcs merged commit c0cd0b2 into master Sep 5, 2017
@eliangcs eliangcs deleted the cli-subdomain-field branch September 5, 2017 08:42
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants