Support multiple CDK badges per construct

[DanielMSchmidt]

Description

Support multiple CDK badges per construct package. Instead of two currently none is shown when searching here: https://constructs.dev/search?q=cdktf-cdk8s&offset=0

Use Case

Packages like https://github.com/DanielMSchmidt/cdktf-cdk8s and https://github.com/hashicorp/cdktf-aws-cdk support more than one cdk (by bridging between two)

Other information

No response

[Chriscbr]

Thanks for raising this issue. I agree that I'm not sure the current experience feels ideal since showing no badge makes it seem like a bug.

Displaying multiple badges requires some care since badges are also shown in the package cards, and there is limited horizontal space / we don't want card titles to appear squished (see screenshot)

I wonder if we could do something where in the backend, we tag packages with all applicable CDK types (instead of the current behavior which is to skip when multiple CDK types are detected) -- and on the frontend, we could display "Multi-CDK" if we are rendering a package card with multiple applicable tags, and we could display all badges explicitly if we are rendering the package page.

@gabewomble WDYT?

[DanielMSchmidt]

My main concern is that the package should stay while filtering. UX nit: We could add a title attribute with the supported CDKs to the Multi-CDK badge. I guess needing two CDKs is quite an edge case, if I wanted to support multiple SDKs I'd probably write multiple packages for any other concern than interoperability, we could also add a new set of badges for interop (or a new label)

[gabewomble]

When we designed these badges, I don't believe we considered the use case / possibility of libraries being compatible with more than one CDK type. However, we absolutely should support the ability to tag multiple CDK types on a single library for filtering purposes regardless of the UI/UX solution we come up with for the badges.

I'll add two issues on the front-end repo - one for the support of multiple CDK types, and the other to track the badge update.

@Chriscbr I also really like the idea of adding a multi-cdk badge, which could provide additional context with a tooltip to show which CDK's the library supports. This suggestion would likely be the easiest to roll with as well 🙂

[Chriscbr]

w00t, it's live! (mouseover to see which frameworks the package uses)