Add Tag component
See the result :
-
https://cikimomogi-grammy.github.io/PQ-507/hosting/deno-deploy.html
-
https://cikimomogi-grammy.github.io/PQ-507/plugins/autoquote.html
Some examples:
| Result | Syntax | Description |
|---|---|---|
![]() |
<TagGroup><Tag template="deno"/></TagGroup> |
Use default deno template |
![]() |
<TagGroup><Tag template="deno" text="DENO LAND"/></TagGroup> |
Use default deno template but change the label to "DENO LAND" |
![]() |
<TagGroup><Tag template="deno"/><Tag template="nodejs"/></TagGroup> |
Use two tags: Deno and Node.JS |
![]() |
<TagGroup><Tag text="GRAMMYJS" icon="telegram" iconType="logo" color="#26A5E4"/></TagGroup> |
Custom tag. |
![]() |
<TagGroup><Tag text="TRENDING" icon="fire" iconType="icon" iconColor="#dc3545" iconBg="#ffe674" color="#fde427" textColor="#ff8080"/></TagGroup> |
Custom tag. |
List of Tag attributes:
| Attribute | Option | Description |
|---|---|---|
template |
official, thirdparty, deno, nodejs |
Tag template |
desc |
Any string | Description for the tag. It will displayed as a tooltip |
link |
Any URL or anchor link. | Tag hyperlink |
color |
HEX, RGB, or any string that matched with css color | Tag background color. Example use for HEX color: <Tag color="ffffff" ... /> |
colorDark |
HEX, RGB, or any string that matched with css color | Tag background color for dark mode. Example use for HEX color: <Tag colorDark="ffffff" ... /> |
icon |
.svg file's name | Tag icon. If we do not have the icon on asset folder (matched by the file's name), then fetch them from simpleicons.org. Example: <Tag icon="npm" iconType="logo"/> will fetch .svg with name npm from URL https://simpleicons.org/icons/npm.svg |
iconType |
icon, logo |
Icon type. icon will fetch from icons.getbootstrap.com and logo will fetch from simpleicons.org. Example: <Tag icon="fire" iconType="icon"/> will fetch from URL https://icons.getbootstrap.com/assets/icons/fire.svg |
iconColor |
HEX, RGB, or any string that matched with css color | Tag icon color |
iconColorDark |
HEX, RGB, or any string that matched with css color | Tag icon color for dark mode |
iconBg |
HEX, RGB, or any string that matched with css color | Background color of the tag icon |
iconBgDark |
HEX, RGB, or any string that matched with css color | Background color of the tag icon for dark mode |
text |
Any string | Tag label |
textColor |
HEX, RGB, or any string that matched with css color | Tag label color. Example use for HEX color: <Tag textColor="ffffff" ... /> |
textColorDark |
HEX, RGB, or any string that matched with css color | Tag label color for dark mode. Example use for HEX color: <Tag textColorDark="ffffff" ... /> |
TagGroup is useful for adding some margins to your tags. You can wrap your tags inside TagGroup like this one:
<TagGroup>
<Tag text="TAG 1" />
<Tag text="TAG 2" />
</TagGroup>;
Always use TagGroup when Tag is used right below heading.
But, in some cases we may not include TagGroup, such as when we insert Tag between sentences like this one:

List of TagGroup attributes:
| Attribute | Option | Description |
|---|---|---|
mt |
px, rem, or any string number that matched with css size units | Top margin. Example: <TagGroup mt="12px"> ... </TagGroup> |
mb |
px, rem, or any string number that matched with css size units | Bottom margin. Example: <TagGroup mb="12rem"> ... </TagGroup> |
pt |
px, rem, or any string number that matched with css size units | Top padding. Example: <TagGroup pt="12rem"> ... </TagGroup> |
pb |
px, rem, or any string number that matched with css size units | Bottom padding. Example: <TagGroup pb="12rem"> ... </TagGroup> |
🚀 Deployed on https://634ed354962969069a8b103f--grammy.netlify.app
Have you considered adding these labels to the navigation menu, too?
Suggestion: Maybe use the greenish color of Node.js logo for Node.js badge? (I don't see a specific color scheme for Deno other than black-and-white, so the current one is nice)
https://github.com/grammyjs/website/pull/507/commits/f06b4f76b8dd8741a2c7c3f46ab59cbcf5e7e8c2:

To do:
- [x] Implement labels into the navigation menu
As a general rule, all plugins should be available on both runtimes. That's why adding both Deno and Node labels to all official plugins is maybe a little weird. We should rather add a note to stateless-question (or finally port it, @EdJoPaTo?) as well as to fluent. It can say that exactly this plugin is Node-only.
We can well use the lables for the hosting pages!
I had the same thought until I realized that some official plugins do not support Deno. Perhaps we can add a node.js only badge for those two plugins while removing the Deno and Node.js badges from the rest.

I'm not sure we need a badge for that. That makes it look like Node-only plugins are a thing which we advertise or anything (we even created a label for it!) while in reality there's like 1 plugin that won't support Deno, and another one that will be supporting both runtimes in the future.
Great changes, awesome to use a component!
This PR is ready for review. Just waiting for the last step to sync all languages once the PR is approved. I have updated some information too, please see the description above.
Alright. This one is final. No more commit again from me. Pinky promise.
As we're increasing the number of tools that are available to website contributors, we will have to start documenting how to document. I see two alternatives:
- Just paste the PQ description at the end of the contribution guide into CONTRIBUTING.md. Pro: easy to write, con: unlikely anyone will read.
- Start a page on https://grammy.dev itself about how to contribute. This could be useful for tips and tricks about OSS contributions in general, and it could contain instructions on how to help out with the grammY ecosystem as well as this site in particular. Pro: much easier to find (searchbar anyone?), con: takes some effort to write.
What is your opinion?
As we're increasing the number of tools that are available to website contributors, we will have to start documenting how to document. I see two alternatives:
- Just paste the PQ description at the end of the contribution guide into CONTRIBUTING.md. Pro: easy to write, con: unlikely anyone will read.
- Start a page on https://grammy.dev itself about how to contribute. This could be useful for tips and tricks about OSS contributions in general, and it could contain instructions on how to help out with the grammY ecosystem as well as this site in particular. Pro: much easier to find (searchbar anyone?), con: takes some effort to write.
What is your opinion?
That's good idea. I don't mind creating a new page to explain more clearly the usage of this plugin.
I know I said that adding Deno/Node support badges to every official plugin page is superfluous (and I still think that). However, seeing now that the third-party plugins do have these labels (which makes sense), I must say that I find it a bit odd that they're missing from official plugins.
This leaves us with three choices:
- Live with the inconsistency.
- Add badges to all official plugins.
- Remove badges from third-party plugins.
I think number three is probably more reasonable. Thus, I have removed the Deno/Node tag from all plugin pages.
When I clone this branch, there are a bunch of linting errors in my editor and warning from the Vetur extension. Could you add the list of extensions you use to the VSCode settings as extension recommendations? Also, I tend to lauch the editor at the repo root, but now it seems like VSCode does not pick up the right TS or Vue tooling when doing that. Seems like a lot broke, would appreciate if you could educate us.
I read on the Vue page that Vetur has been deprecated and replaced by Volar. Here's the list of plugins I use:
I already set all the settings and include them in the recent commit. So, it should be possible to use both extensions immediately after installing them.
As we're increasing the number of tools that are available to website contributors, we will have to start documenting how to document. I see two alternatives:
- Just paste the PQ description at the end of the contribution guide into CONTRIBUTING.md. Pro: easy to write, con: unlikely anyone will read.
- Start a page on https://grammy.dev itself about how to contribute. This could be useful for tips and tricks about OSS contributions in general, and it could contain instructions on how to help out with the grammY ecosystem as well as this site in particular. Pro: much easier to find (searchbar anyone?), con: takes some effort to write.
What is your opinion?
That's good idea. I don't mind creating a new page to explain more clearly the usage of this plugin.
I have opened #519 to track and discuss this.
I know I said that adding Deno/Node support badges to every official plugin page is superfluous (and I still think that). However, seeing now that the third-party plugins do have these labels (which makes sense), I must say that I find it a bit odd that they're missing from official plugins. This leaves us with three choices:
- Live with the inconsistency.
- Add badges to all official plugins.
- Remove badges from third-party plugins.
I think number three is probably more reasonable. Thus, I have removed the Deno/Node tag from all plugin pages.
Awesome, thanks! 🎉
When I clone this branch, there are a bunch of linting errors in my editor and warning from the Vetur extension. Could you add the list of extensions you use to the VSCode settings as extension recommendations? Also, I tend to lauch the editor at the repo root, but now it seems like VSCode does not pick up the right TS or Vue tooling when doing that. Seems like a lot broke, would appreciate if you could educate us.
I read on the Vue page that Vetur has been deprecated and replaced by Volar. Here's the list of plugins I use:
I already set all the settings and include them in the recent commit. So, it should be possible to use both extensions immediately after installing them.
Thank you so much! I'll try all of this out as soon as I have time. The plugins can also be added as recommended plugins to the .vscode/settings.json file.
Add two new plugins:
autotagPageto add tags to multiple pages, andautotagMenuto add tags to multiple navbar menus.
I'm quite satisfied with the result. My code is probably a bit messy, so refactoring is very welcome :) Once this PQ is successfully merged I will proceed with the documentation part.
Should we add these stunning looking badges to https://grammy.dev/hosting/comparison.html#serverless, as well?
Sure. What badges should we add?
The Deno/Node ones.
Should we then retain the columns about Deno and Node? They will be redundant, but it could be that they still provide a better overview?
Like this?

No, I'd rather make a column "platforms"
No, I'd rather make a column "platforms"
And then we add Deno/Nodejs badges there?
Yes
Style 1:

Style 2:

Style 3:

Style 4:

Personally, I prefer styles 1 or 2.
2 but a bit smaller paddings. 1 (current?) is also ok
Isn't web also a platform? Also, what does the web platform even tell us?
what does the web platform even tell us?
Good question. Does it have anything to do with bot development, specifically? :thinking:
what does the web platform even tell us
ESM without any Deno APIs, I suppose
what does the web platform even tell us
ESM without any Deno APIs, I suppose
How about we add a Node badge if the platform supports Node APIs, a Deno badge if the platform supports Deno APIs, and no badge if the platform supports neither of the two?
Good, since the only platform that this is intended for was Cloudflare Workers, and it also supports Deno





