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.

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

Merged
merged 7 commits into from
Oct 8, 2016

Conversation

jeffcarbs
Copy link
Member

@jeffcarbs jeffcarbs commented Oct 6, 2016

Fixes #589

This adds shorthand for list and list item. Still somewhat WIP:

  • Add missing test coverage
  • Add pass-through props to item-content Solved a different way

Only 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:

  • I definitely think we should write shorthand for all examples.
  • I think the best idea would be to just show the example once and show the shorthand side-by-side with the regular code.
    • Showing the shorthand in separate section makes it less discoverable.
    • Showing the same exact example twice is redundant and makes the docs hard to read.

This (more advanced shorthand documentation) may be something we leave for a separate PR, just wanted to get thoughts.

@@ -52,10 +52,13 @@ function Header(props) {
return <ElementType {...rest} className={classes}>{children}</ElementType>
}

if ((image && typeof image !== 'boolean') || (icon && typeof icon !== 'boolean')) {
Copy link
Member Author

@jeffcarbs jeffcarbs Oct 6, 2016

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.

Copy link
Member

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)
Copy link
Member

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')) {
Copy link
Member

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))}
Copy link
Member

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>
Copy link
Member

Choose a reason for hiding this comment

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

Coverage:

image

header: customPropTypes.itemShorthand,

/** Shorthand for ListIcon. */
icon: customPropTypes.every([
Copy link
Member

@levithomason levithomason Oct 6, 2016

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.

Copy link
Member Author

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.

@levithomason
Copy link
Member

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.

@codecov-io
Copy link

codecov-io commented Oct 6, 2016

Current coverage is 100% (diff: 100%)

Merging #637 into master will not change coverage

@@           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          

Powered by Codecov. Last update 978f206...48104f2

@jeffcarbs jeffcarbs force-pushed the feature/list-shorthand branch from 3e8b5a3 to 76e5136 Compare October 7, 2016 04:57
@jeffcarbs
Copy link
Member Author

@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.

2016-10-07T01:25:38-04:00 notify POST /repos/Semantic-Org/Semantic-UI-React/statuses/edc973113439d5a74414f62203407b711b5baea9 bot=matheuspoleza code=404
{"message":"Not Found","documentation_url":"https://developer.github.com/v3"}

Perhaps you need to update that key in the url?

@levithomason
Copy link
Member

levithomason commented Oct 8, 2016

Perhaps you need to update that key in the url?

The key is the commit sha:

image

For some reason, making a POST to that endpoint gives a 404 saying it can't be found. I'm betting this is due to renaming the original Semantic-UI-React repo to Semantic-UI-React-Old, then transferring stardust to Semantic-UI-React, and then deleting the original Semantic-UI-React-Old repo. GitHub sets up redirects to handle all the moving around. I'm thinking the transfer/rename/delete has confused GH or one of these services. Especially being I went back to TechnologyAdvice and created another stardust so I could redirect the old docs to the new docs. This means there is a real repo there again, so links to it should not redirect any more.

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 /statuses endpoint is not finding the repo. I've reached out to Codecov support to see if they can help as well.

* - 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.
*/
Copy link
Member

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.

@levithomason
Copy link
Member

Made a fix to the simple bulleted example, it doesn't require the bulleted prop since the elements ul and li are provided. Then, I added some descriptions to the other examples. Will merge on pass.

@levithomason levithomason merged commit 7ae2ed2 into master Oct 8, 2016
@levithomason levithomason deleted the feature/list-shorthand branch October 8, 2016 04:13
@levithomason
Copy link
Member

Released in semantic-ui-react@0.54.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants