-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
fix(List): Update to v1 API #551
Conversation
</List.Content> | ||
</List.Item> | ||
<List.Item> | ||
<List.Icon name='github' size='large' verticalAlign='middle' /> |
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.
We have there hateful situation, Icon
doesn't have prop verticalAlign
but .list .icon
has. I don't like idea with List.Icon
, may be something better?
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 clarity, we're talking about this:
Oh boy :/ The proper extrapolation of our API is to add List.Icon
. However, odds of users using this over Icon
are slim. Especially considering all other components use the Icon
directly.
I think we add verticalAlign
to the Icon
itself. I realize that prop would only be valid when used in a List, but it seems to make the most sense for users.
Any other wise ideas @jcarbo?
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 List.Icon
might actually be the way to go. It would just be a wrapper around Icon
that handles the verticalAlign
prop:
function ListIcon(props) {
const { verticalAlign, className } = props
const classes = cx(
useValueAndKey(verticalAlign, 'verticalAlign'),
className
)
const rest = getUnhandledProps(ListIcon, props)
return <Icon {...rest} className={classes} />
}
In all likelihood, if I were using a List
I'd either be:
- using the
icon
prop as a shorthand, so it wouldn't matter whether it'sIcon
orList.Icon
under the hood. - looking at the example page for
List
to see how to structure it and would see theList.Icon
subcomponent there.
I could also see just building it into the Icon
class with a comment noting that it's a specific use-case, although I really wish there were at least one other use-case 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.
Agreed. I was on the fence as well, but after sleeping on it and hearing this I think we should stick with the API pattern we've chosen rather than make an exception.
@layershifter let's keep it consistent and go with List.Icon
. Thanks for the input guys.
Current coverage is 99.61% (diff: 100%)@@ master #551 diff @@
==========================================
Files 112 117 +5
Lines 1767 1807 +40
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 1758 1800 +42
+ Misses 9 7 -2
Partials 0 0
|
2a0c5a7
to
a7a817c
Compare
const rest = getUnhandledProps(ListItem, props) | ||
const valueProp = ElementType === 'li' ? { value } : { dataValue: value } | ||
|
||
return <ElementType {...rest} {...valueProp} className={classes}>{children}</ElementType> |
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.
Comrades, what you think about this (valueProp
)? May be more elegant solution possible there?
I'm talking about this:
<li value="*">User Benefits</li>
You can also manually specify a value for an ordered list using data-value on a div, or value on an li
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 don't see any React warnings when adding value
to an <li>
. Any reason not to with this?
<List.Item value='*' />
//=> <li value="*"></li>
If there is an issue, one alternative could be to use bullet
:
<List.Item bullet='#' />
//=> <li value="#"></li>
Though, I'd lean toward SUI parity if we can.
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'm talking about this transform, it looks not very clean (valueProp
spreading).
<List.Item value='*' />
//=> <div data-value="*"></div>
<List.Item as='li' value='*' />
//=> <li value="*"></li>
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 see, I believe the conditional you have now is acceptable. It is the same approach I would take as a first try.
const ElementType = getElementType(ListList, props) | ||
const classes = cx( | ||
className, | ||
useKeyOnly(ElementType !== 'ul' && ElementType !== 'ol', 'list'), |
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.
Another evil place with class handling, see SUI docs about ul
& ol
.
Combo like Menu.Menu
is there, too :-\
<List>
<List.Item>
Item
<List.List>
<List.Item>Sub item</List.Item>
</List.List>
</List.Item>
</List>
// ...
// <div class="ui list">
// <div class="item">
// <div class="list">...</div>
// </div>
// </div>
// ...
<List as='ul'>
<List.Item as='li'>
Item
<List.List as='ul'>
<List.Item as='li'>Sub item</List.Item>
</List.List>
</List.Item>
</List>
// ...
// <ul class="ui list">
// <li>
// <ul>...</ul>
// </li>
// </ul>
// ...
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.
Per the docs the "list" class may be omitted "as a convenience" when using an "ol" or "ul" tag. Though, I don't think it is required to be omitted. We can likely always have the "list" class present.
I suspect we can also have the "item" class on all items as well. Let's try always having the classes first. That way, the components are more simple.
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.
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.
Oh boy, well then. I think the logic you originally had there is just the way it has to be.
Ahoy, docs are fully there 🚢 Working on tests. |
Awesome, pulling and trying them out. Will let you know. |
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.
Once again, thanks for the massive amount of work here. Especially for keeping up to date on all the latest decisions and incorporating them here. It is very much appreciated!
I've left a few comments. I'll update common tests as well, then we should update this branch to have the latest.
</ElementType> | ||
) | ||
} | ||
function List(props) { |
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.
Let's add the component description from the SUI docs as well.
/> | ||
<ComponentExample examplePath='elements/List/Types/ListExampleBulletedSimple'> | ||
<Message info> | ||
For convenience, a simple bulleted list can also use <code>ul</code> tag. |
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 this message is only applicable to SUI core where the user defines HTML/CSS. Since, in Semantic-UI-React the classNames are hidden from the user. Let's go ahead and remove this.
/> | ||
<ComponentExample examplePath='elements/List/Types/ListExampleOrderedSimple'> | ||
<Message info> | ||
You can also manually specify a value for an ordered list using <code>value</code>. |
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.
This message belongs on the next example.
import React from 'react' | ||
import { Image, List } from 'stardust' | ||
|
||
const ListExampleHorizontalNumbered = () => ( |
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.
How about we rename this ListExampleHorizontalOrdered
to keep with the prop name?
name: 'List', | ||
type: META.TYPES.ELEMENT, | ||
props: { | ||
floated: ['left', 'right'], |
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.
Can use SUI.FLOATS
here for the values.
parent: 'List', | ||
type: META.TYPES.ELEMENT, | ||
props: { | ||
floated: ['left', 'right'], |
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.
Can use SUI.FLOATS
here for the values.
useKeyOnly(active, 'active'), | ||
useKeyOnly(disabled, 'disabled'), | ||
className, | ||
useKeyOnly(ElementType !== 'li', '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.
Can we move this up so the user's className
is added very last?
@@ -24,6 +24,8 @@ export { default as Input } from './Input/Input' | |||
export { default as Label } from './Label/Label' | |||
export { default as LabelDetail } from './Label/LabelDetail' | |||
|
|||
// TODO: Export `List` |
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.
Looks like this is done now, but we should export the rest of the List sub components as well. I'll add a common test that ensures all components are exported at the top level as well.
I've fixed comments and added tests. There is one failed test on |
Updated to latest |
I'll release this later today, thanks much! |
Released in |
This PR updates List component to v1 API.