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

Add Username and Repo Name to Shield Creation fields #701

Closed
oscarmorrison opened this issue Apr 30, 2016 · 4 comments
Closed

Add Username and Repo Name to Shield Creation fields #701

oscarmorrison opened this issue Apr 30, 2016 · 4 comments
Labels
frontend The Docusaurus app serving the docs site

Comments

@oscarmorrison
Copy link

As a new user to Shields.io badges it is not obvious where in the URL
should be the username and the repository name.
It would be helpful to add fields such as

Github User Name
Repo Name

to Shield Creation form such as below:
(obviously this would be different field names per badge)

Screenshot

@oscarmorrison
Copy link
Author

CC @espadrine

@paulmelnikow
Copy link
Member

Related to #466.

paulmelnikow added a commit that referenced this issue Nov 28, 2017
I rewrote the frontend in React using a module bundler. It's matched feature-for-feature with the current frontend, with only slight changes in the styling. I did not fuss about making the styling identical; the badge popup looks particularly different.

This makes the front end much easier to develop. I'm really looking forward to implementing #701, to which this paves the way.

This makes light use of Next.js, which provides webpack config and dev/build tooling. We’ll probably replace it with create-react-app or our own webpack setup because unfortunately it comes with a lot of runtime overhead (the build is 400k).

Let’s open new issues for bugs and features, and track other follow-ups here: https://github.com/badges/shields/projects/1
@tooomm
Copy link
Contributor

tooomm commented Dec 6, 2017

See #1331 (comment) and following:
Request to add a direct link to generated/shown custom image and a custom parameter field.

paulmelnikow added a commit that referenced this issue Nov 12, 2018
This continues the work from #2279, by allowing example badges to be specified using `namedParams`.

Using an object makes it possible for us to display these in form fields down the line. (#701)

Closes #2050.
paulmelnikow added a commit that referenced this issue Nov 17, 2018
This continues the work from #2279, by allowing example badges to be specified using `namedParams`. Using an object makes it possible for us to display these in form fields down the line. (#701)

I've called this the "preferred" way, and labeled the other ways deprecated. I've also added some doc to the `examples` property in BaseService. Then I realized we had some doc in the tutorial, though I think it's fine to have a short version in the tutorial, and the gory detail in BaseService.

I've also added a `pattern` keyword, and made `urlPattern` an alias.

Closes #2050.
paulmelnikow added a commit that referenced this issue Dec 2, 2018
Three main goals:

1. In the front end:
      a. Show form fields and automatically assemble badge URLs (#701)
      c. Group together examples for the same service
      b. Show deprecated services
2. Make it easy to changing the schema of `examples`, thanks to 100% validation. One challenge with frameworks is that when there are typos things fail silently which is pretty unfriendly to developers. The validation should really help with that. (This caught one bug in AUR, though I fixed it in #2405 which landed first.)
3. Produce a service definition export for external tool builders. (#776)
4. Build toward harmony between the front-end data structure and the `examples` key in the service classes. I aliased `staticPreview` to `staticExample` which starts this process.

The old format:

- Lacked a consistent machine-readable representation of the fields.
- Flattened multiple examples for the same service were flattened.
- Excluded deprecated services.

The new format improves a few things, too:

- It cleans up the naming. Since this file evolved over time, the names were a bit muddled (i.e. what was an example vs a preview).
- It duplicated information (like `.svg`). (I can imagine dropping the `.svg` from our badge URLs someday, which would make the URLs easier to read and maintain.)
- For a human reading the YAML file, providing the static example as a deconstructed object is more readable.

Here are a couple snippets:

```yml
  - category: build
    name: AppVeyorCi
    isDeprecated: false
    route:
      format: '([^/]+/[^/]+)(?:/(.+))?'
      queryParams: []
    examples:
      - title: AppVeyor
        example: {path: /appveyor/ci/gruntjs/grunt, queryParams: {}}
        preview: {label: build, message: passing, color: brightgreen}
        keywords: []
      - title: AppVeyor branch
        example: {path: /appveyor/ci/gruntjs/grunt/master, queryParams: {}}
        preview: {label: build, message: passing, color: brightgreen}
        keywords: []
  - category: downloads
    name: AmoDownloads
    isDeprecated: false
    examples:
      - title: Mozilla Add-on
        example: {path: /amo/d/dustman, queryParams: {}}
        preview: {path: /amo/d/dustman, queryParams: {}}
        keywords: [amo, firefox]
```
@paulmelnikow
Copy link
Member

Let's track this in #2496.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
frontend The Docusaurus app serving the docs site
Projects
None yet
Development

No branches or pull requests

3 participants