feat(card): create CardWithFile high-level component #2208
Conversation
Pull Request Test Coverage Report for Build 3035
💛 - Coveralls |
| const headerContent = ( | ||
| <ClayCard.AspectRatio className="card-item-first"> | ||
| <div className="aspect-ratio-item aspect-ratio-item-center-middle aspect-ratio-item-fluid card-type-asset-icon"> | ||
| <ClayIcon spritemap={spritemap} symbol="documents-and-media" /> |
There was a problem hiding this comment.
We will have to make symbol configurable here, the user or the product that using can modify it.
There was a problem hiding this comment.
Hmm, what would you imagine users changing it to? I was looking in the docs and it seemed explicit that this was the symbol someone would see.
There was a problem hiding this comment.
The icons may be different, so we as a library should let the product team set this up easily without holding them back so much that they have to issue an issue here just to change the icon I want to leave this part of the high-level not too rigid in order not to reach that level, to certain things that we can make configurable.
But in the documentation has the description of making this configurable, are you looking at this document https://docs.google.com/document/d/1st2moaRVphrsFrDJUz-ic26aH-V46YkQam75X6BHPY0/edit#heading=h.eevh9ngq3hi8?
There was a problem hiding this comment.
ah, I wasn't able to find that doc. that should help. thanks
| <ClayCard.Body> | ||
| <div className="autofit-col"> | ||
| <ClaySticker inline> | ||
| <ClayIcon spritemap={spritemap} symbol="folder" /> |
There was a problem hiding this comment.
I would say the same here
There was a problem hiding this comment.
I'd be hesitant to make it configurable since its explicitly the "CardWithFolder" component. If we remove that symbol, it starts to be much more vague.
There was a problem hiding this comment.
Yeah, you're right about that, you might want to rename it CardWithHorizontal to follow what Lexicon said: https://docs.google.com/document/d/1st2moaRVphrsFrDJUz-ic26aH-V46YkQam75X6BHPY0/edit#heading=h.x89wughhxazs
What do you think?
| const interactiveTag = interactive ? 'span' : 'div'; | ||
|
|
||
| const TagName = href ? 'a' : interactiveTag; | ||
| const OuterTag = CARD_TYPE_ELEMENTS[displayType] as ('span' | 'div' | 'h3'); |
There was a problem hiding this comment.
Just curious, why isn't TypeScript inferring the output here?
There was a problem hiding this comment.
It will infer the type of the value, string, but it wouldn't pick up the explicit string values.
There was a problem hiding this comment.
@bryceosterhaus, @matuzalemsteles.
There are two ways to force it to infer a better type here.
Best way is to use as const like this:
const CARD_TYPE_ELEMENTS = {
subtitle: 'span',
text: 'div',
title: 'h3',
} as const;This stops TypeScript from widening the type to string and you can drop the cast.
The other way that I can think of is to explicitly annotate the type, but that is very repetitive and I wouldn't suggest it:
type T = {
subtitle: 'span',
text: 'div',
title: 'h3',
};
const CARD_TYPE_ELEMENTS: T = {
subtitle: 'span',
text: 'div',
title: 'h3',
};There was a problem hiding this comment.
Best way is to use as const like this...
This is a good approach. Thanks @wincent
There was a problem hiding this comment.
I sent a PR with the suggested fix.
|
@matuzalemsteles made some changes. I also implemented the ability to use images for files, since file and image cards are essentially the same. I also went through that doc and updated the cards to be slightly more flexible for config. Let me know what you think |
| )} | ||
|
|
||
| {imgProps && ( | ||
| <img |
There was a problem hiding this comment.
I'm not sure CardWithFile will accept images in case it should only accept icons, but I understand that in the end it looks like CardWithImage maybe we can leave a more generic name to merge the two into one.
There was a problem hiding this comment.
hmm, yeah probably smart to make the name more generic.
ClayCardWithBasicInfo
or
ClayCardWithEntity (kinda weird cause we already have *WithUser)
We could try to merge this with ClayCardWithUser and make it ClayCardWithEntity. Not sure if we want to keep the distinction though.
Any other names come to mind?
There was a problem hiding this comment.
Hmm I don't know if I like ClayCardWithEntity does not seem so obvious to me its use, maybe going with ClayCardWithInfo it is not quite basic so in fact we can remove the word Basic.
|
@matuzalemsteles i went with |
Fixes #2195
Fixes #2196
Fixes #2197