Skip to content

Added ES6 Snippet support for NodeJS-Request#164

Closed
sastava007 wants to merge 3 commits intopostmanlabs:developfrom
sastava007:develop
Closed

Added ES6 Snippet support for NodeJS-Request#164
sastava007 wants to merge 3 commits intopostmanlabs:developfrom
sastava007:develop

Conversation

@sastava007
Copy link
Contributor

@sastava007 sastava007 commented Feb 22, 2020

What it does
Allows the user to generate the code snippet for NodeJS Request in ES6 format.
This is in response to issue #115 requested by one of the users.

Changes I made
Created a new folder under ./codegens named nodejs-requestES6 which contains all the code for making requests along with newman and unit test files.

  • Registered a new parameter ES6_enabled in options() which allows the user to toggle between whether codegen generate snippet with ES6 features or not.

  • By default ES6_enabled is set to false

  • Also added the new created option parameter in structure.test.js file to register it as a valid option id.

  • Added unit tests to verify the generated snippets.

Follow Up
This PR is first in the series of upcoming PRs which will add the feature of generating code snippet in ES6 notation with NodeJS.

@abhijitkane @shreys7 Please review!

@umeshp7
Copy link
Contributor

umeshp7 commented Feb 24, 2020

Hey! Thanks for the contribution. @sastava007
This actually could be just changes in the existing NodeJS-Request code-gen. You could either change the existing snippet completely to respect ES6 or you could add an option for enabling ES6 in the same codegen.
There is very little difference between this and the existing NodeJS-Request codegen to qualify as a new codegen. We ideally use a new variant when the underlying library is different and the language is same.

@sastava007
Copy link
Contributor Author

@umeshp7 Thanks for your feedback, I was also thinking of the same changes.
What we can do is that we can pass an extra parameter ES6_enabled : true/false with by default value as false in options while calling convert() and based on that we can return the respective snippet.
What do you say?

@shreys7
Copy link
Member

shreys7 commented Feb 24, 2020

@sastava007 yes, this would be similar to how other options are used while generating snippet. Add it to the options array defined in getOptions() function, and then use the option everywhere you need to generate ES6 enabled snippet. Add the support via options now, the default value can be decided later.

…cture.test.js file to respect the new changes
@sastava007
Copy link
Contributor Author

@umeshp7 @shreys7
I have made the changes as you mentioned and also registered the new option parameter in structure.test.js to avoid any error while testing.
I have tested the above changes locally by passing different values to ES6_enabled parameter to check for any leak and it worked all the time.

Please review!

@umeshp7
Copy link
Contributor

umeshp7 commented Feb 24, 2020

@sastava007 Okay, we'll review. Could you also update the description of this PR to describe the changes you have done now?

@sastava007
Copy link
Contributor Author

@umeshp7 Updated!

@shreys7
Copy link
Member

shreys7 commented Feb 25, 2020

@sastava007 need unit tests around this to verify the generated snippet with option set to true/false

@sastava007
Copy link
Contributor Author

@shreys7 Have added, please review.

@sastava007 sastava007 removed the request for review from abhijitkane February 25, 2020 13:29
Copy link
Member

@shreys7 shreys7 left a comment

Choose a reason for hiding this comment

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

Do we really need a new variable called ES6_snippet? Can't we keep just one snippet variable and make some required changes according to the ES6_enabled option's value, as I see a lot of code being repeated for generating snippet and ES6_snippet.

optionsArray.push(indentString + 'followRedirect: false');
}
if (options.ES6_enabled === true) {
optionsArray.push(indentString + 'ES6_enabled: 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 we need this on line 74? @sastava007

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@shreys7
I thought that it would be better to have a separate snippet for ES6 instead of using bunch of if statements. But, no problem I'll make it with single snippet only.

And for this,

 if (options.ES6_enabled === true) {
    optionsArray.push(indentString + 'ES6_enabled: true');

I have mistaken this and thought that we need to pass it to options property, but just I realized that it's only required till the snippet is generated and after that, it's of no use.

I'll fix all this, and made a separate PR by deleting this one.

Copy link
Member

Choose a reason for hiding this comment

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

@sastava007 Hmm, I see. See if you can reduce the number of if statements. If that's causing a lot of if-else statements, then we can go with your approach.

}

expect(snippet).to.be.a('string');
expect(snippet).to.include('ES6_enabled: true');
Copy link
Member

Choose a reason for hiding this comment

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

again, why does this need to be included in the generated snippet? @sastava007

}

expect(snippet).to.be.a('string');
expect(snippet).to.not.include('ES6_enabled: true');
Copy link
Member

Choose a reason for hiding this comment

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

same comment as above

ES6_snippet += 'const fs = require(\'fs\');\n';
}
snippet += 'var options = {\n';
ES6_snippet += 'const options = {\n';
Copy link
Member

Choose a reason for hiding this comment

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

This should be var or more preferably let instead of const options

@sastava007 sastava007 closed this Feb 27, 2020
@umeshp7
Copy link
Contributor

umeshp7 commented Feb 27, 2020

The changes requested should have been updated on this PR itself for the purposes of keeping proper track of the progress.

@sastava007
Copy link
Contributor Author

Actually, I pushed those commits directly to the default develop branch itself. Because of which whenever I create any new branch for resolving other features/issue all the previous commits were also showing in it.

So I thought that it would be better if I delete that PR and start again with a dedicated branch to a particular issue this would help me to keep working on the different issues until a previous one is under review.

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.

3 participants