-
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
RFC: Standartize content prop #1364
Comments
I agree on confusing, poor coverage, and simplifying the render, however, it is not only useful but required to facilitate the shorthand factories. The purpose of the
Example, a Popup takes <Popup content='Some content' />
<div class="ui popup transition visible">
<div class="content">Some content</div>
</div> Whereas using There are some usages which are unnecessary, such as the ItemMeta's content. This usage is a direct replacement of the All components should have a I think then we must keep the content prop for shorthand purposes. Let me know your thoughts on this. |
I want to eliminate possible misunderstandings. My proposal is remove |
I can see that argument. Keeping consistent props across all components is nice, however, our shorthand props are 1:1 with subcomponents. So, if there is no I was leaning toward removing the prop for this case, however, I have one other consideration. Shorthand props, such as <Button icon='user'>Profile</Button> // does not work
<Button icon='user' content='Profile' /> // works Essentially, the We could allow the use of The inconsistency issue is also raised again, that as a developer I have no way of knowing if a component can use In conclusion, I'm thinking it is still good to keep
|
Main problem that I see there is incompability 😕 <Popup content='Some content' />
<div class="ui popup transition visible">
<div class="content">Some content</div>
</div>
<Popup content={{ children: 'Some content' }} />
<div class="ui popup transition visible">
<div class="content">Some content</div>
</div> <Button icon='user' content='Profile' />
<button class="ui button">
<i class="user icon"></i> Profile
</button>
<Button icon='user' content={{ children: 'Profile' }} /> // does not work |
Oh boy, this is a great point. We simply cannot have some content props work with shorthand, and others not. Exploring ideas here, it is possible to create a component from this: <Button content={{ children: 'Profile' }} />
// => <button class="ui button"><span>Profile</span></button> This would mean that all usages of the content prop must be passed to I'll have to think on this one. At this point, it seems the least destructive path is to keep the |
I have some proposals. content and contentRendererWe have function PopupContent(props) {
// ...
return <ElementType>{_.isNil(children) ? contentRender(content) : children}</ElementType>
}
PopupContent.defaultProps = {
contentRenderer: defaultContentRenderer
}
PopupContent.propTypes = {
// ...
content: customPropTypes.contentShorthand,
contentRenderer: Proptypes.func,
} const defaultContentRenderer = content => {
if(typeof content === 'string' || typeof content === 'number') return content
return createShorthand('div', content)
} So, if we have rename content propYes, it will be breaking, but |
I like this on first glance except for two hang ups:
I'm now thinking that we do not worry about this until we have reported issues about it. I personally have never run into it. Do you have any use cases or bugs you've run into that requires a refactor? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions. |
I'm think that we need to remove
content
prop from all our components.This will be breaking change.
Why?
Confusing
It's represents different types in our components:
Poor coverage
There are many components that doesn't have
content
prop. Sometime they have another shorthand instead ofcontent
.Useless
It does same job as
children
prop:Poor tests
We doesn't have special tests for
contentShorthand
, our existing is not so powerfull asrendersChildren
.Simplify render function
Our
render
funtions will be more simple, while we have less usages oflodash
(_.isNil
).@levithomason @jcarbo I'm glad to hear your throughts :smile
The text was updated successfully, but these errors were encountered: