-
Notifications
You must be signed in to change notification settings - Fork 4k
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
feat(List): Shorthand for list and list items #637
Conversation
@@ -52,10 +52,13 @@ function Header(props) { | |||
return <ElementType {...rest} className={classes}>{children}</ElementType> | |||
} | |||
|
|||
if ((image && typeof image !== 'boolean') || (icon && typeof icon !== 'boolean')) { |
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.
These checks weren't entirely accurate. image
or icon
could have been passed as empty strings (valid itemShorthand) but still wouldn't be rendered. Also, the !== boolean
is captured by the shorthand factory, which ignores booleans.
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.
Cool, I'm on board with using the return of the factory to determine the markup. Seems stronger to isolate that log in the factory's handling of the shorthand values.
@@ -52,10 +52,13 @@ function Header(props) { | |||
return <ElementType {...rest} className={classes}>{children}</ElementType> | |||
} | |||
|
|||
if ((image && typeof image !== 'boolean') || (icon && typeof icon !== 'boolean')) { | |||
const iconNode = Icon.create(icon) | |||
const imageNode = Image.create(image) |
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.
I've been moving these names to fooElement
. We had a number of fooJSX
previously. I think element is most accurate since factories return a ReactElement. LMK if you disagree on the name, but I do want to make them consistent.
@@ -52,10 +52,13 @@ function Header(props) { | |||
return <ElementType {...rest} className={classes}>{children}</ElementType> | |||
} | |||
|
|||
if ((image && typeof image !== 'boolean') || (icon && typeof icon !== 'boolean')) { |
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.
Cool, I'm on board with using the return of the factory to determine the markup. Seems stronger to isolate that log in the factory's handling of the shorthand values.
|
||
return ( | ||
<ElementType {...rest} className={classes}> | ||
{_.map(items, (item) => ListItem.create(item))} |
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.
Missing coverage here. Codecov is still not updating PR status for some reason. Killing me...
<ElementType {...rest} className={classes} {...valueProp}> | ||
{iconNode || imageNode} | ||
{(content || headerNode || descriptionNode) && ( | ||
<ListContent> |
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.
header: customPropTypes.itemShorthand, | ||
|
||
/** Shorthand for ListIcon. */ | ||
icon: customPropTypes.every([ |
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.
What do you say we add iconShorthand
and imageShorthand
that can handle disallowing the each other? This is also needed in the header, perhaps elsewhere.
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.
I think that's more of an exception, tbh. A quick search shows it's only applicable in the header and list while icon is a prop in over 20 component/subcomponents (although maybe we're not applying the disallow
in some places we should be?).
In any case, the *Shorthand
props includes a disallow(['children'])
because that's required in all cases. This is only applicable in some cases so I think it'll make it more clear to apply the disallow
within the component's prop definitions that need it.
Agree on shorthand examples, I think there should be a shorthand example following every regular example. See our resolution on this here #564 (comment). You can also reference the Feed docs which I think are a good example of shorthand following the regular example. |
Current coverage is 100% (diff: 100%)@@ master #637 diff @@
====================================
Files 119 119
Lines 1890 1916 +26
Methods 0 0
Messages 0 0
Branches 0 0
====================================
+ Hits 1890 1916 +26
Misses 0 0
Partials 0 0
|
3e8b5a3
to
76e5136
Compare
76e5136
to
edc9731
Compare
@levithomason - added missing specs. Looks like the build notification is broken for codecov: https://codecov.io/gh/Semantic-Org/Semantic-UI-React/commit/edc973113439d5a74414f62203407b711b5baea9/builds.
Perhaps you need to update that key in the url? |
The key is the commit sha: For some reason, making a POST to that endpoint gives a The coverage reports are uploading to Codecov from CircleCI OK, and Codecov shows the correct coverage. It also comments on the PR correctly. It just seems the |
* - a props object, it forces the presence of Item.Content and passes those | ||
* props to it. If you pass a content prop within that props object, it | ||
* will be treated as the sibling node to header/description. | ||
*/ |
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.
I pushed an update to the ComponentProps
component to preserve line breaks. That way this doesn't render as a single ran together line in the prop table.
Made a fix to the simple |
Released in |
Fixes #589
This adds shorthand for list and list item. Still somewhat WIP:
Add pass-through props to item-contentSolved a different wayOnly open question is regarding documentation. How do we want to handle shorthand documentation? I added a few examples here but there's a lot of them for List so I wanted to clarify our approach before going much further. Some thoughts:
This (more advanced shorthand documentation) may be something we leave for a separate PR, just wanted to get thoughts.