-
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: Standardize shorthand prop names for primary content #391
Comments
Looks good 👍 Also, might be added |
I can agree there, seems |
The Header needed a complete refactor due to component augmentation, I've baked this in as well. See, #414. |
This work is going on in #452. The <Label icon='settings'>Settings</Label>
<Label icon='settings' children='Settings' /> Where as this is: <Label icon='settings' content='Settings' /> We could have made the IMO, there is also just something not quite right about passing children as a prop when using JSX. |
All components have been updated. |
Issue
Many components provide a shorthand prop for defining the primary content of the component. We currently have inconsistent prop names for this shorthand prop. It makes it confusing as a developer to have to use
text
in some places,content
in others, and more.Additionally, the
text
prop (and others) are already used in some components to control features. We need a standard that is consistent and avoids collisions.Proposal
Here are the proposed rules for choosing the primary content shorthand prop name:
Naming
1. Use the component part name
If there is a subcomponent which holds the primary content of the component, then the subcomponent name should be used for the shorthand prop name:
This makes intuitive sense as you are passing down a prop from the parent to the subcomponent with the same name. It also follows what we are doing with the
icon
andimage
props, where you can configure the children with the same prop name.It allows us to also add standardized feature support for various component parts via our factories,
createDescription(...)
,createMeta(...)
. Contrived examples, we could standardize props likechildKey
,elementType
, or rending links, etc.2. Use
content
If the component does not have a subcomponent name to use, then use
content
:This makes sense in the context of SUI as "content" is a standard component part that means "the primary content of the component". If there are no child components left to configure, then you are adding the "content" of the component.
Again, this would allow us to
createContent(content)
and add standardized support via our factories if we wanted.A good counter argument to
content
on a component that has no subcomponents is, "Why not just usechildren
?" This is already built into React of course.PropTypes
PropType validation has also come up in https://github.com/TechnologyAdvice/stardust/pull/390#discussion_r74690941. Initially we thought to limit these to strings only. This allows the props to be used as child keys in arrays. It also simplifies things for the user.
However, some components like
<Statistic.Value />
may very well accept a number on<Statistic value={100} />
. It would be troublesome to force users to convert numbers to strings in this case. Also, numbers do not present the same issues for child keys as accepting objects.customPropTypes.shorthand
I propose we create this propType to consistently validate shorthand props. Not only would it standardize shorthand props, we could then bake in
disallow(['children'])
as well. This would pair very nicely with standardize factories for shorthand.CONTRIBUTING
Any PR resolving this issue should update the CONTRIBUTING.md with the final shorthand props spec.
The text was updated successfully, but these errors were encountered: