docs(Props): improve table with props#1634
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1634 +/- ##
=======================================
Coverage 71.28% 71.28%
=======================================
Files 852 852
Lines 7045 7045
Branches 2008 2029 +21
=======================================
Hits 5022 5022
Misses 2017 2017
Partials 6 6
Continue to review full report at Codecov.
|
5011d3a to
589d5f8
Compare
| name: 'componentInfo', | ||
| }), | ||
| ) | ||
| .pipe(cache(gulpReactDocgen(['DOMAttributes', 'HTMLAttributes']), { name: 'componentInfo-1' })) |
There was a problem hiding this comment.
Should be increased otherwise everyone should clear cache manually
There was a problem hiding this comment.
don't we need to change .gitignore as well?
There was a problem hiding this comment.
Nope, this cache is stored in your TMP directory
miroslavstastny
left a comment
There was a problem hiding this comment.
Shorthand docs and typings not correct for collection shorthand with kind
Let's take ToolbarProps.items as an example:
- it accepts
kindattribute with 5 different values, one of them being default - based on the
kindit calls shorthand factory for 4 different components.
But documentation just states ShorthandCollection<ToolbarItemProps> - it is missing information about kind and respective props.
Also the typing is not correct (though ObjectOf<any> "saves" that).
Sorry that I have not realised it when reviewing #1605 :-/
Link from ShorthandCollection<SubComponent> goes to SubComponent page
If you follow the link from ShorthandCollection<ToolbarItemProps> you will get to ToolbarItemProps page - which correctly describes the props but other than that looks like a dead page (no examples...).
I think I can confuse consumers, it should rather link to parent component page with subcomponent props opened.
| * A slider can be read-only and unable to change states. | ||
| * @default false | ||
| */ | ||
| /** A slider can be read-only and unable to change states. */ |
There was a problem hiding this comment.
I understand @default is no longer used by docsite, but it is still used by intellisense.
Do we want to remove it or rather test that it is present and correct?
There was a problem hiding this comment.
It's hard to maintain things like these because they don't aligned with code. I think that the best way is to remove them and rely on defaultProps.
| import { WithAsProp, ShorthandValue, withSafeTypeForAs } from '../../types' | ||
| import Box, { BoxProps } from '../Box/Box' | ||
|
|
||
| export type LoaderPosition = 'above' | 'below' | 'start' | 'end' |
There was a problem hiding this comment.
Removal of this makes it a BREAKING CHANGE. Is it necessary?
There was a problem hiding this comment.
Technically it's breaking change, will mention this in CHANGELOG and in a PR header.
It's necessary to avoid manual type definition for autogenerated playground.
There was a problem hiding this comment.
oh, we were exporting this type 🤦♂ great catch @miroslavstastny
docs/src/components/ComponentDoc/ComponentPropsTable/ComponentPropsRow.tsx
Outdated
Show resolved
Hide resolved
bmdalex
left a comment
There was a problem hiding this comment.
looks good to me, few comments; awesome job 👍
| name: 'componentInfo', | ||
| }), | ||
| ) | ||
| .pipe(cache(gulpReactDocgen(['DOMAttributes', 'HTMLAttributes']), { name: 'componentInfo-1' })) |
There was a problem hiding this comment.
don't we need to change .gitignore as well?
docs/src/components/ComponentDoc/ComponentPropsTable/ComponentPropsRow.tsx
Show resolved
Hide resolved
docs/src/components/ComponentDoc/ComponentPropsTable/ComponentPropsRow.tsx
Outdated
Show resolved
Hide resolved
docs/src/components/ComponentDoc/ComponentPropsTable/ComponentPropsRow.tsx
Show resolved
Hide resolved
| import { WithAsProp, ShorthandValue, withSafeTypeForAs } from '../../types' | ||
| import Box, { BoxProps } from '../Box/Box' | ||
|
|
||
| export type LoaderPosition = 'above' | 'below' | 'start' | 'end' |
8fc9589 to
05430cb
Compare
05430cb to
8fc9589
Compare
…com/stardust-ui/react into chore/prop-generator
|
@miroslavstastny great catches, fixed them in 9956115 and 83c1577 👍 |
…com/stardust-ui/react into chore/prop-generator
BREAKING CHANGES
LoaderPositionis no longer exported.Problem
To generate proper playgrounds for components we need to have a set of values props. It's impossible to get them from strings.
Allow to use Markdown in props description
This will allow us provide more meaningful descriptions for props.
Missing default values
Only values that were specified by
@defaulttag in JSX were present, forLoaderwe have missedas,delay,labelPositionandsize💥✅ Fixed by update of
parseDefaultValue:Unable to manipulate values
Previously we had just string as values (
"gap.smaller" | "gap.small" | "gap.medium" | "gap.large") fromreact-typescript-docgen, so we can't to use them for playground generation.✅ An updated
parseType()function powered by Babel parses these strings and create proper definition structure:{ "types": [ {"value": "gap.smaller"}, {"value": "gap.small"}, {"value": "gap.medium"}, {"value": "gap.large"} ], "name": "gap", },Why use Babel in
parseType()?Only AST parser can provide proper output. Any implementation based on regexps will be fragile on things like generic types.
Why not use only Babel?
It will be hard to resolve types that are coming interfaces
CommonProps, i.e. Babel good at parse, but it can't resolve TS types.Handle edge cases
react-typescript-docgenusestypeToString()to generate strings with types mentioned above. Sometimes it generates things like this:ℹ️ I tried to configure output of
typeToString()manually via 3rd param (TypeFormatFlags), but it still resolved types.✅ Fixed by direct lookup in Babel AST, see
getTypeFromBabelTree()Wrong
asprop definitionIt was marked as required and missed description.
🆚
Hard to understand what props can be passed to slot
What can be passed to
clearIndicator?Based on #1605 we know which props are used. With parsed types we can obviously understand relationship between components. In this example,
BoxPropsis a link toBoxcomponent 🚀