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

Fix a few typos #2697

Merged
merged 2 commits into from
Jan 8, 2019
Merged

Fix a few typos #2697

merged 2 commits into from
Jan 8, 2019

Conversation

jankeromnes
Copy link
Contributor

Most typos were fixed using codespell -w.

@shields-ci
Copy link

Warnings
⚠️

This PR modified helper functions in lib/ but not accompanying tests.
That's okay so long as it's refactoring existing code.

⚠️ This PR modified service code for vscode-marketplace but not its test code.
That's okay so long as it's refactoring existing code.
Messages
📖 ✨ Thanks for your contribution to Shields, @jankeromnes!
📖

Thanks for contributing to our documentation. We ❤️ our documentarians!

Generated by 🚫 dangerJS against 538e1af

@@ -218,11 +218,11 @@ Description of the code:
* [licenses.js](https://github.com/badges/shields/blob/master/lib/licenses.js)
* [text-formatters.js](https://github.com/badges/shields/blob/master/lib/text-formatters.js)
* [version.js](https://github.com/badges/shields/blob/master/lib/version.js)
4. We perform input validation by defining a schema which we expect the JSON we receive to conform to. This is done using [Joi](https://github.com/hapijs/joi). Defining a schema means we can ensure the JSON we receive meets our expectations and throw an error if we receive unexpected input without having to explicitly code validation checks. The schema also acts as a filter on the JSON object. Any properties we're going to reference need to be validated, otherwise they will be filtered out. In this case our schema declares that we expect to recieve an object which must have a property called 'status', which is a string.
4. We perform input validation by defining a schema which we expect the JSON we receive to conform to. This is done using [Joi](https://github.com/hapijs/joi). Defining a schema means we can ensure the JSON we receive meets our expectations and throw an error if we receive unexpected input without having to explicitly code validation checks. The schema also acts as a filter on the JSON object. Any properties we're going to reference need to be validated, otherwise they will be filtered out. In this case our schema declares that we expect to receive an object which must have a property called 'status', which is a string.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

GitHub doesn't highlight the actual change in this line, so here it is in shorter form:

- to recieve an object
+ to receive an object

5. Our module exports a class which extends `BaseJsonService`
6. As with our previous badge, we need to declare a route. This time we will capture a variable called `gem`.
7. We can use `defaultBadgeData()` to set a default `color`, `logo` and/or `label`. If `handle()` doesn't return any of these keys, we'll use the default. Instead of explicitly setting the label text when we return a badge object, we'll use `defaultBadgeData()` here to define it declaratively.
8. Our bage must implement the `async handle()` function. Because our URL pattern captures a variable called `gem`, our function signature is `async handle({ gem })`. We usually separate the process of generating a badge into 2 stages or concerns: fetch and render. The `fetch()` function is responsible for calling an API endpoint to get data. The `render()` function formats the data for display. In a case where there is a lot of calculation or intermediate steps, this pattern may be thought of as fetch, transform, render and it might be necessary to define some helper functions to assist with the 'transform' step.
8. Our badge must implement the `async handle()` function. Because our URL pattern captures a variable called `gem`, our function signature is `async handle({ gem })`. We usually separate the process of generating a badge into 2 stages or concerns: fetch and render. The `fetch()` function is responsible for calling an API endpoint to get data. The `render()` function formats the data for display. In a case where there is a lot of calculation or intermediate steps, this pattern may be thought of as fetch, transform, render and it might be necessary to define some helper functions to assist with the 'transform' step.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

GitHub doesn't highlight the actual change in this line, so here it is in shorter form:

- Our bage must
+ Our badge must

@paulmelnikow paulmelnikow added the documentation Developer and end-user documentation label Jan 8, 2019
@paulmelnikow paulmelnikow merged commit 3ab2862 into badges:master Jan 8, 2019
@shields-deployment
Copy link

This pull request was merged to master branch. This change is now waiting for deployment, which will usually happen within a few days. Stay tuned by joining our #ops channel on Discord!

After deployment, changes are copied to gh-pages branch:

@paulmelnikow
Copy link
Member

Thank you!

@jankeromnes
Copy link
Contributor Author

Many thanks for the quick review @paulmelnikow ! 💯

@paulmelnikow
Copy link
Member

If you're interested in some kinda fun yet kinda robotic work, we need to convert all of our previewUrls to staticPreview + pattern + namedParams. There are just over 50 left so we're really in the home stretch. #2652 is one I did not long ago… happy to help if you're interested (we can chat on Discord or on #1961).

@jankeromnes
Copy link
Contributor Author

Thanks for the suggestion! I might look into it afterwards, but I'm already working on another PR for Shields (I'd like to make contributions easier by allowing anyone to develop Shields in Gitpod, a free dev environment service, and will probably also suggest a new badge for that service).

I do have one question though, README.md says I should visit localhost:8080, yet CONTRIBUTING.md and TUTORIAL.md tell me to use localhost:3000. What's the difference between these ports? (npm start even seems to open both)

@paulmelnikow
Copy link
Member

paulmelnikow commented Jan 8, 2019

Interesting!

:8080 is the badge server and :3000 is the frontend.

Added: I'm not completely clear on how the Gitpod thing would work, though we like making it easier for people to contribute to Shields! If you need help while you're playing with it, feel free to open a new issue.

@jankeromnes
Copy link
Contributor Author

@paulmelnikow Thanks for the suggestion! I opened #2772 with a bit more details, and my first roadblock (i.e. is there a way to expose the badge server on port 8080 for non-localhost access?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Developer and end-user documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants