-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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.
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
[UI Framework] Reactify kuiCard and related CSS components #12197
Changes from 4 commits
db71202
84eecae
e5b2e1f
c36765d
23acc84
d8373b6
6c3e802
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
This file was deleted.
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,6 @@ | ||
import React from 'react'; | ||
|
||
import { | ||
KuiCardGroupContainer, | ||
KuiCardGroup, | ||
KuiCard, | ||
KuiCardDescription, | ||
|
@@ -12,58 +11,82 @@ import { | |
} from '../../../../components'; | ||
|
||
export default () => { | ||
/** | ||
* These styles are just for demonstration purposes. It is recommended use | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oops, had a typo in the proposed text 😊 better: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ... and I haven't caught that.... ooops :) |
||
* properly named classes to set the width in production code. | ||
*/ | ||
const cardStyle = { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about adding a comment like the following here?
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To make thinking the fast copy-pasters :) |
||
width: '400px' | ||
}; | ||
|
||
return ( | ||
<div> | ||
<KuiCardGroupContainer> | ||
<KuiCardGroup> | ||
<KuiCard style={cardStyle}> | ||
<KuiCardDescription> | ||
<KuiCardDescriptionTitle> | ||
Get a banana | ||
</KuiCardDescriptionTitle> | ||
|
||
<KuiCardDescriptionText> | ||
Bananas are yellow, fit easily in the hand, and have a lot of potassium or something. | ||
</KuiCardDescriptionText> | ||
</KuiCardDescription> | ||
|
||
<KuiCardFooter> | ||
<KuiLinkButton | ||
buttonType="basic" | ||
href="#" | ||
> | ||
Banana! | ||
</KuiLinkButton> | ||
</KuiCardFooter> | ||
</KuiCard> | ||
|
||
<KuiCard style={cardStyle}> | ||
<KuiCardDescription> | ||
<KuiCardDescriptionTitle> | ||
Get a pteradactyl | ||
</KuiCardDescriptionTitle> | ||
|
||
<KuiCardDescriptionText> | ||
Pteradactyls can fly, like to squawk all the time, and are difficult to spell correctly. | ||
</KuiCardDescriptionText> | ||
</KuiCardDescription> | ||
|
||
<KuiCardFooter> | ||
<KuiLinkButton | ||
buttonType="primary" | ||
href="https://www.elastic.co/subscriptions/xpack" | ||
target="_blank" | ||
> | ||
Pteradactyl! | ||
</KuiLinkButton> | ||
</KuiCardFooter> | ||
</KuiCard> | ||
</KuiCardGroup> | ||
</KuiCardGroupContainer> | ||
<KuiCardGroup> | ||
<KuiCard style={cardStyle}> | ||
<KuiCardDescription> | ||
<KuiCardDescriptionTitle> | ||
Get a banana | ||
</KuiCardDescriptionTitle> | ||
|
||
<KuiCardDescriptionText> | ||
Bananas are yellow, fit easily in the hand, and have a lot of potassium or something. | ||
</KuiCardDescriptionText> | ||
</KuiCardDescription> | ||
|
||
<KuiCardFooter> | ||
<KuiLinkButton | ||
buttonType="basic" | ||
href="#" | ||
> | ||
Banana! | ||
</KuiLinkButton> | ||
</KuiCardFooter> | ||
</KuiCard> | ||
|
||
<KuiCard style={cardStyle}> | ||
<KuiCardDescription> | ||
<KuiCardDescriptionTitle> | ||
Get a pteradactyl | ||
</KuiCardDescriptionTitle> | ||
|
||
<KuiCardDescriptionText> | ||
Pteradactyls can fly, like to squawk all the time, and are difficult to spell correctly. | ||
</KuiCardDescriptionText> | ||
</KuiCardDescription> | ||
|
||
<KuiCardFooter> | ||
<KuiLinkButton | ||
buttonType="primary" | ||
href="https://www.elastic.co/subscriptions/xpack" | ||
target="_blank" | ||
> | ||
Pteradactyl! | ||
</KuiLinkButton> | ||
</KuiCardFooter> | ||
</KuiCard> | ||
|
||
<KuiCard style={cardStyle}> | ||
<KuiCardDescription> | ||
<KuiCardDescriptionTitle> | ||
Get a magnolia tree | ||
</KuiCardDescriptionTitle> | ||
|
||
<KuiCardDescriptionText> | ||
Magnolia trees have broad, waxy leaves which they shed year-round. | ||
</KuiCardDescriptionText> | ||
</KuiCardDescription> | ||
|
||
<KuiCardFooter> | ||
<KuiLinkButton | ||
buttonType="basic" | ||
href="https://www.elastic.co/subscriptions/xpack" | ||
target="_blank" | ||
> | ||
Magnolia! | ||
</KuiLinkButton> | ||
</KuiCardFooter> | ||
</KuiCard> | ||
</KuiCardGroup> | ||
|
||
<br className="guideBreak"/> | ||
|
||
|
@@ -110,6 +133,28 @@ export default () => { | |
</KuiLinkButton> | ||
</KuiCardFooter> | ||
</KuiCard> | ||
|
||
<KuiCard style={cardStyle}> | ||
<KuiCardDescription> | ||
<KuiCardDescriptionTitle> | ||
Get a magnolia tree | ||
</KuiCardDescriptionTitle> | ||
|
||
<KuiCardDescriptionText> | ||
Magnolia trees have broad, waxy leaves which they shed year-round. | ||
</KuiCardDescriptionText> | ||
</KuiCardDescription> | ||
|
||
<KuiCardFooter> | ||
<KuiLinkButton | ||
buttonType="basic" | ||
href="https://www.elastic.co/subscriptions/xpack" | ||
target="_blank" | ||
> | ||
Magnolia! | ||
</KuiLinkButton> | ||
</KuiCardFooter> | ||
</KuiCard> | ||
</KuiCardGroup> | ||
</div> | ||
); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strictly speaking, this violates the open/closed principle by modifying the
.kuiCard
block based on its location inside the.kuiCardGroup
block. I know several other frameworks break this rule by implementing such groups in exactly this way. A way to fix this would be to not nest the selectors and create a mix of.kuiCard
and.kuiCardGroup__card
on the individual card elements.References:
@cjcenizal, it looks like this is consistent with how similar group blocks are implemented in the kui framework (e.g.
.kuiButtonGroup
). So this is not specific to this PR. Do we accept this BEM violation for these cases?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weltenwort, in general you are right, changing the properties through nesting is a secure way into the CSS Hell, but in these cases we have an extra semantic information:
XGroup is a group of X so we are speaking about Xs.
The pro is simpler syntax for the user of the X React component: No extra property is needed on X depending on its location (is X part of a group of Xs or not?) and not to expose CSS, which is a main advantage of the framework.
The con is the loosening of the clear openclosed-principle.
But this loosening is context bound: only within a group of X. It could be considered as an extension of the principle instead of its violation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're absolutely right... this is a dilemma I've encountered several times. For context, this component was originally implemented the way you suggest, and I only recently changed it to use the current pattern (https://github.com/elastic/kibana/pull/12183/files#diff-5b434436eea8c6ef3f9c1f64780bb791L3 for reference).
There are two problems I've encountered when strictly applying BEM in this kind of situation:
.kuiCard
mixed with.kuiCardGroup__card
but you also need.kuiCard__description
mixed with.kuiCardGroup__cardDescription
. From the point of view of someone applying the classes, this "interface" can be complex and confusing.To me, it comes down to a trade-off: sacrificing BEM in exchange for a more ergonomic interface. Personally, I think we should try to stick to BEM as much as possible, until we discover some pain in the interface. What are your thoughts on this?
Also, do you think we should document your links and these lines of reasoning in a style guide?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BEM is good and known, that's why I can read your SCSS
and diverging from a standard needs explanation.
The css_style_guide.md looks to me the right place for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cjcenizal, thanks for the historic references. I tend to agree with you and @PopradiArpad that this looks like a good exemption from the rule. We should definitely document that somewhere. I will create a PR to amend the css style guide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for the record, the aforementioned PR is #12276