feat: card Storybook Components

[TenzDelek]

Description
created storybook for cards

1. Venue

2. Speaker

3. past-edition

Related issue(s)

GSOC

[netlify]

✅ Deploy Preview for peaceful-ramanujan-288045 ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	d915306
🔍 Latest deploy log	https://app.netlify.com/projects/peaceful-ramanujan-288045/deploys/69a84f244317e6000878641d
😎 Deploy Preview	https://deploy-preview-811--peaceful-ramanujan-288045.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[AceTheCreator]

think we might need to rethink this card Storybook setup. The current approach treats stories as one-to-one with use cases, but they should really map one-to-one with components.

I understand your reasoning, since we have three card implementations, that’s three separate components, each with its own story file. But that separation should be because they’re technically different components, not because of different use cases.

A better approach would be to create a single, flexible Card component with variants that cover all three cases. The goal of a design system is to capture patterns and build reusable solutions. If every use case becomes its own component, we lose that consistency and end up with a collection of one-offs.

Great work so far 💪🏽
Let me know what you think, @TenzDelek.

cc @ashmit-coder

[TenzDelek]

think we might need to rethink this card Storybook setup. The current approach treats stories as one-to-one with use cases, but they should really map one-to-one with components.

I understand your reasoning, since we have three card implementations, that’s three separate components, each with its own story file. But that separation should be because they’re technically different components, not because of different use cases.

A better approach would be to create a single, flexible Card component with variants that cover all three cases. The goal of a design system is to capture patterns and build reusable solutions. If every use case becomes its own component, we lose that consistency and end up with a collection of one-offs.

Great work so far 💪🏽 Let me know what you think, @TenzDelek.

cc @ashmit-coder

Thank you Ace for your suggestion but I think forcing those card into one component would be the wrong kind of abstraction and would be much harder to maintain in the long run. there will be unnecessary to much of prop passing and conditional.
I think instead of that, we can go with similar case of how shadcn does. using a base card component (kind of a wrapper).
cc @AceTheCreator @ashmit-coder

[AceTheCreator]

think we might need to rethink this card Storybook setup. The current approach treats stories as one-to-one with use cases, but they should really map one-to-one with components.
I understand your reasoning, since we have three card implementations, that’s three separate components, each with its own story file. But that separation should be because they’re technically different components, not because of different use cases.
A better approach would be to create a single, flexible Card component with variants that cover all three cases. The goal of a design system is to capture patterns and build reusable solutions. If every use case becomes its own component, we lose that consistency and end up with a collection of one-offs.
Great work so far 💪🏽 Let me know what you think, @TenzDelek.
cc @ashmit-coder

Thank you Ace for your suggestion but I think forcing those card into one component would be the wrong kind of abstraction and would be much harder to maintain in the long run. there will be unnecessary to much of prop passing and conditional. I think instead of that, we can go with similar case of how shadcn does. using a base card component (kind of a wrapper). cc @AceTheCreator @ashmit-coder

@TenzDelek can you share a link on how shadcn does it?

[TenzDelek]

think we might need to rethink this card Storybook setup. The current approach treats stories as one-to-one with use cases, but they should really map one-to-one with components.
I understand your reasoning, since we have three card implementations, that’s three separate components, each with its own story file. But that separation should be because they’re technically different components, not because of different use cases.
A better approach would be to create a single, flexible Card component with variants that cover all three cases. The goal of a design system is to capture patterns and build reusable solutions. If every use case becomes its own component, we lose that consistency and end up with a collection of one-offs.
Great work so far 💪🏽 Let me know what you think, @TenzDelek.
cc @ashmit-coder

Thank you Ace for your suggestion but I think forcing those card into one component would be the wrong kind of abstraction and would be much harder to maintain in the long run. there will be unnecessary to much of prop passing and conditional. I think instead of that, we can go with similar case of how shadcn does. using a base card component (kind of a wrapper). cc @AceTheCreator @ashmit-coder

@TenzDelek can you share a link on how shadcn does it?

https://ui.shadcn.com/docs/components/card cc @AceTheCreator

[TenzDelek]

hi @AceTheCreator ,@ashmit-coder , I went through the codebase of the main website. and it seems they are also keeping it in a distributive way. I think this would be much approachable and cleaner than what you suggested. because thinking in another way all three card seems to be way different in terms of ui. but happy to hear what your thought on this one as well. 😄
prev gsoc pr related with it asyncapi/website#3122

[AceTheCreator]

hi @AceTheCreator ,@ashmit-coder , I went through the codebase of the main website. and it seems they are also keeping it in a distributive way. I think this would be much approachable and cleaner than what you suggested. because thinking in another way all three card seems to be way different in terms of ui. but happy to hear what your thought on this one as well. 😄 prev gsoc pr related with it asyncapi/website#3122

Okay, let's do it that way then 👍🏾

[TenzDelek]

hi @AceTheCreator ,@ashmit-coder , I went through the codebase of the main website. and it seems they are also keeping it in a distributive way. I think this would be much approachable and cleaner than what you suggested. because thinking in another way all three card seems to be way different in terms of ui. but happy to hear what your thought on this one as well. 😄 prev gsoc pr related with it asyncapi/website#3122

Okay, let's do it that way then 👍🏾

this pr is already doing that. happy for a quick review.

[AceTheCreator]

@TenzDelek, are you planning on implementing the ticket card component?

[TenzDelek]

what we did additionally:

1. group all 4 card in /card directory and improve some naming of the component
2. create a UI separate card component for ticket.

[TenzDelek]

ready for review @AceTheCreator

[AceTheCreator]

LGTM! 🚀

[AceTheCreator]

Hey @TenzDelek good job on this 💜

[AceTheCreator]

/rtm

[TenzDelek]

merging as already approved by @AceTheCreator . the /rtm was unable to merge it due to unresolved comment

[TenzDelek]

/rtm

[TenzDelek]

thank you for the review Ace. learn a lot