Closed sebastiansandqvist closed 7 years ago
Added tables for all of the remaining components that have props.
One very minor change is I made noop
a shared utility function. The reason for this was that it helps to use the function's name
whenever a function is used as a default prop. So if there's a function which happens to be named noop
it makes it easy to know that that's exactly what it is in the table.
Overview
This PR improves the documentation within the demo site by displaying information about each component's props within a table.
This is great for documentation because we do not have to manually keep it in sync with the component. When the component's
propTypes
anddefaultProps
update, so will the<PropTypeTable />
, automatically.Implementation details
It's only capable of detecting simple prop types, like
PropTypes.string
, not the kind that are returned by a function, likePropTypes.arrayOf(PropTypes.string)
. Still, it is very helpful for the majority of cases, even just to see which props are available and required.In addition, I've added a non-standard
propDescriptions
static property that can be used to write documentation for each prop in the context of the component itself. These descriptions are displayed in the table, in addition to whether or not the prop is required.Screenshot
Questions
propDescriptions
? Is it a bad idea to have something non-standard attached to a component?arrayOf()
,oneOf()
, etc.? So far, the only implementation of such a table that I have seen include that information relied on a babel plugin to inject debug information into the components themselves. I would like to avoid that.