-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Props components not working since 1.0.0-rc.8 #777
Comments
|
@rfoel I just reproduced the bug (this time I hope without typo ^^) The |
Props components also not working when I set typescript as |
@ivan-dalmet I think this is issue with |
Is 1.0.0-rc even use v0.13.7 loader.ts EDIT: NVM, found the ts props loading logic in docz-core/src/utils/docgen/typescript.ts |
@lesha1201 yeah that's a working workaround! |
Hello!
|
I'm having the same issue and have tried every work around suggested above and others I could think of. I've even directly imported from the component file and not the index and Props do not render. I've tried many combinations of the following:
I have multiple component folders self contained using combinations of the above so that I can test them while changing releases and npm/yarn. |
Finally figured it out! It was an odd combination of removing the peer dependencies that I thought I had to add to make docz/yarn happy, including react, react-dom. I tried to get my package.json to look as close to this file here: https://github.com/ivan-dalmet/docz-issue-sandbox/tree/master/issue-777 |
The problem is that when using https://github.com/pedronauck/docz/blob/master/core/docz/src/components/Props.tsx
|
I have my components:
exported like this: // Button.jsx
// ...
export default Button // index.js
export Button from './Button' And when I import Button in .mdx, import { Button } from 'components/Button'
...
<Props of={Button} /> // doesn't render However, if I import Button directly from the Button.js file, it works: import Button from 'components/Button/Button'
...
<Props of={Button} /> // renders Though it seems like a workaround for this particular case, I still have the same error for some (more complex) components. I haven't found the reason yet, but these components worked great with good old PropsTable (I really miss it btw) |
@mlshv +1 for the table. Might be a good idea for |
Now that I have PropTypes rendering using the happy path, I'm still finding one use case that I can not get to render. When leveraging Is there a way to use my Workaround:It's not elegant, but this appears to work: export const WrappedComponent = withStyles(styles)(Component); Update for v1.0.0:This workaround no longer functions and have to maintain using rc.8 for now. Update for v1.0.4:The workaround appears to function again and does not appear to function with basic default exports. |
Currently at v1.0.0, Props works perfectly for us in dev, but when we build production Props deosn't render anything From what I can tell in this thread most of you have this issue in dev as well, so maybe it's a separate issue |
I think I found the source of the problem (at least in my case). TLDR; Theory The Props component uses The list of all components' info (I guess that it gets resolved by findAllExportedComponentDefinitions from react-docgen) is in And everything goes normal when we import a component directly: import Button from 'components/Button/Button' And crashes when we do it through an import { Button } from 'components/Button' That's because in the second case we have Why it doesn't work as expected even when I import component directly in my .mdx Even when I import // in .mdx
import Button from 'components/Button/Button' it may not work because it has already been imported in another component through // some component that uses Button
import { Button } from 'components/Button' So the workaround I found is to always use direct import for all my documented components. It doesn't look pretty, but at least it works. I think that this issue is related to the way react-docgen resolves components. @pedronauck can you provide an idea how it may be possible to import components through UPD: @cupofjoakim I have the same problem. Props doesn't display in production build, even if I apply the mentioned workaround. For me, docz became so unstable after migration from 0.13.7. Thinking about migration to styleguidist |
It may be worth nothing that each UPDATE:Well. This is interesting. I applied some pretty mundane This is the commit, for the curious: OHIF/react-viewerbase@c0b0ed2 It could be a change from UPDATE 2:While the above commit allowed docs to render while I was developing locally, the production build did not render docs. Stopping and restarting the dev build locally removes docs until I modify and save a file. Prop docs are then shown again. |
I'm seeing this same behaviour. Starting without a Is there maybe a difference in how the docs are built when starting the dev-server and when rebuilding a single module? |
I tried commiting the This is in version 1.0.1 of docz Diff screenshot: |
I've found a cause of the Props not working on Windows in version 1.0.3. The |
@evosch, for what it's worth, my dev machine is Windows, and the CI that deploys our production docs is Linux. Both output a |
π I've experienced some version of this problem throughout all the beta releases of Docz w/ Typescript; sad that it continues to be problematic in Environment:
|
I'm having the same issue with props not displaying. I'm running on docz 1.0.4. The interesting thing is if I touch the file that mdx file is importing, then it rebuilds and the props show up. They are never there on the initial load. At first I thought I'd just write a script that touches all my js files, but that doesn't seem work. It seems I need to do that one at a time. PS.
eg
|
None of the above config combinations help to render Props component at 1.0.4. Not windows nor macos |
I'm using 1.04 (latest version) of docz with typescript and I found a workaround for this, edit .docz/cache/propsParser.json and paste you components's corresponding json as this: {
...
"src/components/button/index.tsx": {
"props": []
}
...
} the key of the json object is the path to your components, then edit your components props: e.g: add/edit a comment of your component's props. and The props table will show |
@ejuo, here you go https://github.com/yyynnn/mtsbankui/blob/master/doczrc.js gh-pages branch, those Props that show up are wrong |
@yyynnn, my assumption was confirmed. With modifyBabelRc you rewrite original docz config, that disabled
|
@ejuo wow, thanks for such a thorough answer! It was crucial line in the config to work with older versions, now it works fine without it. |
It works, thank you very much! The props components has displayed in my site now. |
After adding the options listed in #777 (comment) as well as blowing away the |
I have similar issue with TypeScript interface when the definition and component are in difference files. |
Any news on a bugfix? |
You are my hero. dev and build both working after I added jsx to the filterComponents |
TypeScript solution:
Remove your |
I remove .docz file and restart server, just fix it out.don't know why |
I had to find another solution: Working solutionindex.mdx
index.js
ButtonPlain.js
Props not showingindex.mdx
index.js
ButtonPlain.js
|
I've taken a look into this and I believe this issue solely lies within the None of my components have the |
@Lavoaster could you elaborate on the issue on the |
I had this issue and after read and try most of the comments here, finally could get it work. Seems like to see in your docz file (mdx). You have to had in your exported component declared propTypes.
In your awesome component declare proptypes;
NOTE: If you declared your propTypes inside your Class as static it will not work... |
Damn. I'm trying to document some React Native components. The default RN components use 'static' PropTypes. Is there a work around for this? |
Hello! I hope this issue is fixed soon, but in the mean time I have a fix for those of us that are using Typescript. For some reason the I noticed that my components have the right data like this: So I created my own component that replaces import { useComponents } from 'docz';
export default function PropsTable(props) {
const { of: Component } = props;
const { props: DoczThemePropsTable } = useComponents();
const componentProps = Component.__docgenInfo.props;
return <DoczThemePropsTable
props={componentProps}
getPropType={getPropType}
/>;
}
// This `getPropType` is more complex on `Docz`, but we can simplify it:
function getPropType(prop) {
const { flowType } = prop;
return flowType.raw || flowType.name;
} Your component should also follow this structure: export default function MyComponent(props: MyProps) {
const { name } = props;
return (
<h1 className={className}>
{name}
</h1>
);
}
type MyProps = {
className?: String, // optional prop
name: String,
};
MyComponent.defaultProps = {
className: 'my-component',
}; Tried to use On your
|
π Props of component never renders for me; PropsTable isn't in docz either.. |
+1 |
I really wish we'd get at least some update or even a message like "hey i'm swamped right now, i'll have to get to it later" docz is quickly becoming more of a hassle than the helpful tool it's marketed as. also having issues with encapsulating styles. ( how can you have a style/design/component library if all our components are informed by Docz's styles... will dig into resetting the Theme entirely ) |
Hey, Please note that this issue is for docz v1. If you're on docz v2 and this is happening to you than I suggest opening a new issue with your problem and we can help debug it, or check out the examples in the repo. If you want your issue to be fixed faster make sure to provide a repo with a reproduction of the issue. If you're on v1, unfortunately, I can't help you as I don't know enough about it and am swamped right now with v2 development ! EDIT: I see @robjac that you also opened an issue #1091 Moving the discussion for v2 there |
hiοΌi check my code lastnight.And find something here.I'm wishing to be helpful.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Just spent hours battling this to find out that a tsconfig.json is necessary. Thanks a lot! |
Bug Report
The Props components don't render props since rc8 (working in rc7).
There is our folders structure:
No idea why, we investigate on it. Any idea?
The text was updated successfully, but these errors were encountered: