* Show patterns instead of real paths
* realBadge property instead of preview.buildFromExample
* E2e test for displaying a badge
* Check bagde url in badge wrapper
* expectBadgeExample helper function
* Remove a hostname from badge url
* Simpler Cypress assertions
* realBadge -> isBadgeSuggestion
* Do not show regexp in patterns
* Display suggested badges
* E2e test for badge suggestion
* Suggest resource returns example with pattern
* Do not require preview in MarkupModalContent
* Skip integration test for suggestion
* Unmodifiable path in customizer
* Use suggested link
* Allow to change suggested badges
* Enable skipped test
* Enable skipped test
* Code refactoring
* Code refactoring
* Code refactoring
* Code refactoring
* Code refactoring
* Code refactoring
* Unused code removed
* Unused code removed
* getExampleWithServiceByPattern helper added
* BadgeExamples uses examples instead of services definitions
* Revert "getExampleWithServiceByPattern helper added"
This reverts commit 80839fd705.
* style removed from example
* example.exact replaced with preview.buildFromExample
* keywords are required again
* Code refactoring
* More e2e tests for suggestion feature
* Code refactoring
* Build add with a base url
* showActualParams -> isPrefilled
* A new schema for BadgeExamples
* Link moved to queryParams
* Updated documentation for the suggest reponse format
* Link moved to queryParams - another test updated
* Revert "Link moved to queryParams - another test updated"
This reverts commit b5f811bb07.
* Revert "Link moved to queryParams"
This reverts commit 3b54c6d2b4.
* Disable changes in path in suggested badges
* 'link' element documentation restored
I did this as a warm-up to using [React hooks](https://reactjs.org/docs/hooks-intro.html), which provide a better way to accomplish stateful things and side effects using functional components. This allows all components to be written in the same style, improves testability, facilitates code reuse, etc.
There's [a intro here](https://reactjs.org/docs/hooks-intro.html) which links to [Dan's talk at React Conf](https://www.youtube.com/watch?time_continue=3599&v=dpw9EHDh2bM) which does a really good job of explaining why hooks are a good way to write components. He describes hooks as being the electrons and neutrons to components which are atoms. Low-level functionality which was always there in React, though not as accessibly or visibly.
This adds a lint rule that enforces "the rule of hooks" which says they have to be declared at the top level in the functional component.
I don't think this changeset does a fabulous job of showing off the improvements hooks allows, though I think it is still a good direction for this code.
This will definitely save time, and ensure more uniformity.
It moves the `createServiceTester()` calls to a different place from where I'd like them, though I'm happy to have them checked by the linter.
Closes#2701
This consolidates all the badge URL generation functions into a single place, and updates the rest of the calling code to use it. It renames some things and updates labels to bring the names into alignment with the current API.
Resolve#2027
* Endpoint page: improve formatting
Cherry-picked from #2906 (conflicts with that)
Partly addresses #2837 but does not resolve it
* Add badge customizer to the endpoint page
* Clean lint
It can be helpful to have some diagnostic pages for development and quality control. I added one here for the logos, which renders all the named logos in ?style=flat and ?style=social.
While Next.js can handle static sites, we've had a few issues with it, notably a performance hit at runtime and some bugginess around routing and SSR. Gatsby being fully intended for high-performance static sites makes it a great technical fit for the Shields frontend. The `createPages()` API should be a really nice way to add a page for each service family, for example.
This migrates the frontend from Next.js to Gatsby. Gatsby is a powerful tool, which has a bit of downside as there's a lot to dig through. Overall I found configuration easier than Next.js. There are a lot of plugins and for the most part they worked out of the box. The documentation is good.
Links are cleaner now: there is no #. This will break old links though perhaps we could add some redirection to help with that. The only one I’m really concerned about `/#/endpoint`. I’m not sure if folks are deep-linking to the category pages.
There are a lot of enhancements we could add, in order to speed up the site even more. In particular we could think about inlining the SVGs rather than making separate requests for each one.
While Gatsby recommends GraphQL, it's not required. To keep things simple and reduce the learning curve, I did not use it here.
Close#1943Fix#2837Fix#2616
* Add semantic color keywords
This is based on the list I proposed at https://github.com/badges/shields/issues/1522#issuecomment-456455618. As I started documenting `default` I realized it didn't feel quite right. It's not semantic in relation to the content the way the others are, and it's also not the default left color. I changed it to `disabled` which isn't perfect, but seems better. I'm open to other suggestions.
I updated the documentation but the colors won't render correctly until this is deployed
Close#1522
* Reformat the aliases
* Pretty up the docs
* Reset whitespace changes
* Clean lint
This removes `LONG_CACHE` and its descendants, which was a feature that added `?maxAge` to the live preview badges in the frontend. Since they are all static that is no longer needed, as the static badges all have longer cache timeouts regardless.
The static previews don't support the social badges. Adding that lets us remove support for `exampleUrl`. Close#2479.
This includes `style` and `namedLogo` in the service-definition export and updates the frontend to use it. To accomplish this, it passes `namedLogo` through `coalesceBadge`. After logo resolution is moved to `makeBadge` this duplication can be removed, as `logo` will no longer be needed in the result of `coalesceBadge`.
This reimplements the idea @bkdotcom came up with in #1519, and took a stab at in #1525. It’s a really powerful way to add all sorts of custom badges, particularly considering [tools like RunKit endpoints and Jupyter Kernel Gateway](https://github.com/badges/shields/issues/2259#issuecomment-444186589), not to mention all the other ways cloud functions can be deployed these days.
The intention of wrapping HTML in an `__html` is to avoid accidentally unsafe rendering of something that is non-html.
Including this in the definition export solves the problem, and does not seem too onerous for other possible users of that file.
Close#2725
- With examples using `pattern`s, allow building the URL from its component parts, including the query string.
- Provide a button to copy the link, with an animation.
To enable this for other badges, convert them to use a `pattern`: #1961.
The CSS in the project is relatively difficult to change. While it is very DRY, it relies heavily on inheritance. It's difficult to make changes in the markup modal without it also affecting styles elsewhere.
[styled-components](https://www.styled-components.com/) is one of the leading CSS-in-JS libraries. By reducing dependency on global state and CSS inheritance, styles become explicit and are easier to inspect and change. It's also convenient that styles can be embedded with the components they modify.
At runtime, the library creates CSS classes, so it's pretty efficient.
We were using a little bit of [styled-jsx](https://github.com/zeit/styled-jsx) before, which ships with Next.js, though styled-components is more widely used and I've had good experiences with it all around.
In a few cases I've duplicated styles where it feels more natural to do that: for example, `text-align: center` is duplicated in `Main` and `MarkupModal`.
Much of this is a refactor, though there are a few visual changes, particularly in the markup modal and the style examples.
The frontend has a few tests in `lib/` but not all of that is covered. The components are not covered at all. It's difficult to make changes to the frontend because you have to manually test that things haven't broken.
This PR uses [Enzyme](https://airbnb.io/enzyme/) to add some [shallow-rendering tests](https://github.com/airbnb/enzyme/blob/master/docs/api/shallow.md), which are essentially unit tests of the components.
This should pave the way for functional tests of the more complex components.
dependabot-preview[bot]andCaleb Cartwright
Mackenzie MillerandPaul Melnikow
Marcin MielnickiandGitHub
Paul MelnikowandPierre-Yves B
tooommandchris48s
XhmikosRandPaul Melnikow
mbarkhauandPaul Melnikow
Ville SkyttäandPaul Melnikow
Maximilian BrandauandPaul Melnikow
dependabot[bot]andPaul Melnikow