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

use fetch/render pattern in [apm appveyor cdnjs clojars gem] #1901

Merged
merged 3 commits into from
Aug 12, 2018

Conversation

chris48s
Copy link
Member

Once this is in, I will pick up #1740 again

@chris48s chris48s added the service-badge New or updated service badge label Aug 11, 2018
@shields-ci
Copy link

Warnings
⚠️

This PR modified service code for appveyor but not its test code. That's okay so long as it's refactoring existing code.

Messages
📖

✨ Thanks for your contribution to Shields, @chris48s!

Generated by 🚫 dangerJS

Copy link
Member

@paulmelnikow paulmelnikow 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!

@@ -41,11 +41,13 @@ class BaseAPMService extends BaseJsonService {
}

class APMDownloads extends BaseAPMService {
static render(downloads) {
Copy link
Member

@paulmelnikow paulmelnikow Aug 11, 2018

Choose a reason for hiding this comment

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

Could we pass { downloads } here instead? I prefer that pattern as it reads better on the calling side, and grows well.

Copy link
Member Author

Choose a reason for hiding this comment

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

Shall I switch all the fetch() and render() methods to use the object destructuring syntax, or just the render()s ? I don't have particularly strong opinions on this, I'm just slightly unsure what the tradeoff is in this situation..

Copy link
Member

Choose a reason for hiding this comment

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

I think named parameters are great. They make the calling code self-documenting, and allow functions to grow organically with minimal impact at the callsite. As the number of parameters grows past one, naming them reduces the risk of passing the wrong value to a function. Of course JS doesn't have named parameters, but destructuring provides basically the same thing.

So, I'd suggest doing both!

@chris48s chris48s merged commit 0f534ce into badges:master Aug 12, 2018
@shields-deployment
Copy link

This pull request was merged to master branch. Now this change is waiting for deployment.
Deploys usually happen every few weeks. After deployment changes are copied to gh-pages branch.

This badge displays deployment status:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
service-badge New or updated service badge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants