Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

tech: Initial Card UI component #4705

Merged
merged 10 commits into from
Sep 19, 2024
Merged

tech: Initial Card UI component #4705

merged 10 commits into from
Sep 19, 2024
+157 −1

Conversation

Youakeem
Copy link
Contributor

@Youakeem Youakeem commented Sep 16, 2024 •
edited
Loading

Describe your changes

Screenshot 2024-09-16 at 11.56.48.png

Justify why they are needed

Building block for ProductCards and other type of cards

https://www.figma.com/design/5kmmDdh6StpXzbEfr7WevV/Hedvig-UI-Kit?node-id=16269-14623&t=EyGtApoX5yoK0pGI-1

Checklist before requesting a review

  • I have performed a self-review of my code

@vercel Vercel
Copy link

vercel bot commented Sep 16, 2024 •
edited
Loading

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
hedvig-dot-com ✅ Ready (Inspect) Visit Preview Sep 19, 2024 7:50am

@Youakeem Graphite App
Copy link
Contributor Author

Youakeem commented Sep 16, 2024 •
edited
Loading

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Youakeem and the rest of your teammates on Graphite Graphite

This was referenced Sep 16, 2024
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
@Youakeem Youakeem changed the title Add initial ProductCard version tech: Initial Card UI component Sep 16, 2024
@Youakeem Youakeem marked this pull request as ready for review September 16, 2024 10:02
@Youakeem Youakeem requested a review from a team as a code owner September 16, 2024 10:02
gustaveen
gustaveen reviewed Sep 16, 2024
View reviewed changes
Copy link
Member

@gustaveen gustaveen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! 👌 Just some comments

packages/ui/src/components/Card/Card.css.ts
import { xStack, yStack } from '../../patterns'
import { sprinkles, tokens } from '../../theme'

export const cardRoot = recipe({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to use a recipe for this if we only have one size and variant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure how many we'll have for each. In a later PR we add a secondary variant and I suppose we'll need to support different sizes as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also added another size

packages/ui/src/components/Card/Card.tsx Show resolved Hide resolved
packages/ui/src/components/Card/Card.tsx Outdated
type RootProps = ComponentProps<'div'> & RootStyleProps

function CardRoot({ variant, size, className, children }: PropsWithChildren<RootProps>) {
return <article className={clsx(cardRoot({ variant, size }), className)}>{children}</article>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just wondering if we will pass classNames to these components, their use cases would be covered by variants anyway right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand what you mean. This pattern normally merges the internal styles with whatever is being applied by consumers.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Precisely! Just wondered if we should do that by default for all components or if it should be on a need basis? Most components we have we don't need to pass a class from the consumer right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I think we should do it by default. We only need clsx if we are adding some custom classes, otherwise it'll just be applied as part of ...props

This was referenced Sep 18, 2024
Merged
Merged
Merged
Merged
@Youakeem Graphite App
Copy link
Contributor Author

Youakeem commented Sep 19, 2024 •
edited
Loading

Merge activity

  • Sep 19, 3:16 AM EDT: @Youakeem started a stack merge that includes this pull request via Graphite.
  • Sep 19, 3:42 AM EDT: Graphite rebased this pull request as part of a merge.
  • Sep 19, 3:51 AM EDT: @Youakeem merged this pull request with Graphite.

@Youakeem Youakeem changed the base branch from tech-base-pillow-component to graphite-base/4705 September 19, 2024 07:26
@Youakeem Youakeem changed the base branch from graphite-base/4705 to main September 19, 2024 07:39
@Youakeem Youakeem merged commit 8859dd3 into main Sep 19, 2024
5 checks passed
@Youakeem Youakeem deleted the tech-card-component branch September 19, 2024 07:51
This was referenced Sep 19, 2024
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@guilhermespopolin guilhermespopolin guilhermespopolin approved these changes

@alebedev alebedev alebedev approved these changes

@gustaveen gustaveen Awaiting requested review from gustaveen

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@Youakeem @alebedev @gustaveen @guilhermespopolin