I see that you support flat badges in badgen, are they supported here? I'm not seeing anything about flat icons inside the docs.
I'm planning to support flat badge, thinking use flat.badgen.net to serve flat style and badgen.net for classic style, should be cleaner than switching with query params.
It's online now https://flat.badgen.net 馃
Nice! :metal:
Why .net instead of the .now.sh TLD?
?style=flat)BTW, As of (1), I even thought about shrink https://badgen.now.sh/badge/... to https://badgen.now.sh/-/... 馃槀 but that's not right. Do you have any better idea for shortening this /badge/ segment?
Well the original badge is:
https://badgen.now.sh/badge/:subject/:status/:color
Why not use this for flat badges:
https://badgen.now.sh/flat/:subject/:status/:color
I guess my point is: the domain name should remain the same, regardless of the "style" of badge.
That's ok for static badge, but a little complicated for live badges
Segments in URL are like arguments for functions, I wish to keep them as less as possible
I see what you mean. So changing the route isn't really an option.
I think it's fine to add a query string parameter for badge style.
Since the data is the same so it make sense to keep the URL the same.
This is what shields does:
https://img.shields.io/npm/v/copee.svg
https://img.shields.io/npm/v/copee.svg?style=flat
https://img.shields.io/npm/v/copee.svg?style=flat-square
https://img.shields.io/npm/v/copee.svg?style=plastic
This also gives you flexibility if you want to add more options, no need to mess with the routes.
I'm OK with query string, just not a fan of it. I was thinking if we could offer a better option than Shields does? My thoughts on this can be divided into two parts:
What about put that info into hostname, compare these:
https://badgen.now.sh/npm/v/copee?style=flat
https://flat-badgen.now.sh/npm/v/copee
I prefer the latter one. This also brings an __extra benefit__: we could easily serve a full preview of all flat badges within a single server(now alias make this super handy):

I like the simplicity.
And there's __another extra benefit__ 馃お: Put "flat" in the hostname makes it feels more "official" like, stand at the same level as "classic" style. After all, if someone want to use flat style badge, he would use it on all badges rather than in a mixed style, https://flat-badgen.now.sh will be the one-stop shop solely for flat-lovers, they don't have to pick badge from classic shop, then "change" it to flat style. I think it's a better experience.
I was think of this recently, to __provide consistent style across all badges__ could be a goal/value of Badgen. That's why Badgen use to redirect travis-ci badge requests to it's official location at first, but then turn to serve it as live-badge, all redirection-badge are move to live-badge. These provider might not serve flat style, Badgen can do that, and provide flat style for all badges, provide consistence for users. For the same purpose, first-class experience for flat-lovers is a meaningful feature.
That's why I tend to use hostname to switch style. If so, (the second part):
Here's some options came to me:
https://badgen.now.sh
https://flat-badgen.now.sh
https://badgen.now.sh
https://flat.badgen.now.sh
https://badgen.net
https://flat.badgen.net
(3) looks best in this situation 馃構
we could easily serve a full preview of all flat badges within a single server
Yes that's a good point I didn't consider, but surely this could be accomplished with a query string parameter and maybe a dropdown to pick the style.
Take a look at https://shields.io/#styles which also shows additional options beyond style which might be beneficial such as link or maxAge.
provide consistent style across all badges could be a goal/value of Badgen.
Yep, I agree, that's a good goal.
(3) looks best in this situation
If I had to pick, 3 would be best.
One thing to note is that shields calls this style flat-square since flat is the default style. Maybe Badgen should use the same style name to avoid confusion?
I'm agree too. In anyway there should have support for query params anyway. Because there we should allow passing icon, emoji and why not label (allows changing the left side to whatever you want, i really want that feature).
Lets have both style query and domain. The badgen.net will serve the flat rounded style and will allow to pass style query param. The flat.badgen.net will serve flat-squared style.
And actually i'm agree with @styfle for the naming. It may be confusing, but it would suck if we name it flat-square.badgen.net :D
Just realizing that find-my-way router is pretty bullshit in terms of querystring and its query string tests are ridicilous - testing nothing.
I just tried and we don't have way to get queryparams with this router.
I highly think to start a branch with micro and micro-dev
Agree with the flat/flat-square naming confusion, here's some options with my thought(not sure yet):
flat-square.badgen.net - too long, not cool anymores.badgen.net - short but confusingsquare.badgen.net - ok maybe?flat.badgen.net - currently choiceAfter rejecting option (1), consistency with shields.io is gone. Among other choices, flat is the shortest but still meaningful one, that's how I choose it. What's your idea about these options or other proposal?
ADD A POINT: As of the confusion, I think once people see the "flat badgen page", they will get the idea. So IMO the confusion about naming conflict with Shield's traditional won't cause too much problem.
@olstenlarck As the find-my-way thing, here's my plan:
new URL('https://badgen.now.sh/badge?arg=1').searchParams
I like micro but it doesn't come with router, we still need to choose one between these.
I like micro but it doesn't come with router, we still need to choose one between these.
Exactly. Why not? Even more, we need just micro-get and microrouter. The dev environment would be awesome too.
As about the proposals.. i'm for flat.badgen.net. No matter that it may be confusing for the users - they'll get it.
Overall find-my-way are better tested than micro-get and microrouter, I think the reason it doesn't really have tests for query string is it doesn't support query params 馃槀 It's just to make sure router doesn't get broken by query strings.
I haven't do benchmarks but from the docs, find-my-way's "radix-tree" method looks better promising than microrouter's url-pattern. Hmmm, this talk gives me an idea that, maybe I could add the query params support to micro-fork(I created it to mix microrouter's api with find-my-way's router implementation), to have benefits from both 馃構
micro-dev are good to have if we had micro.
Oh, don't why i thought they parse them, hm.
Anyway, cool for the micro-fork except the name. ;d
馃槀 Just thought the shape of fork kinda like paths of route. Maybe I should create a logo for explanation.
https://flat.badgen.net online now 馃拑
I think it would be better the "Query Params" to be on the top of the site, between "Usage" and the "Examples" sections. Because badges number will grow.
Also think that style | flat badge could be visually flat on the badgen.net and style | classic be visually classic on the flat.badgen.net.
Also think that style | flat badge could be visually flat on the badgen.net and style | classic be visually classic on the flat.badgen.net.
@olstenlarck Fixed in #32
I think it would be better the "Query Params" to be on the top of the site, between "Usage" and the "Examples" sections. Because badges number will grow.
Agree 馃憤 At first I put that block on top, latter change to bottom for a little nicer(very opinionated) first screen. I'm planing move index.md to a fully customizable jsx page, with more refinement on the looks, I'll be happy to move "Query Params" to top.
Most helpful comment
馃槀 Just thought the shape of fork kinda like paths of route. Maybe I should create a logo for explanation.