-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
addon-docs: No props for some components #9592
Comments
@thany: I would try the following:
|
@thany sorry for the hassle on this. turns out that reliably displaying props across 1000 different configurations and language features is not an easy thing. fortunately |
@eriktoyra I have tried those things.
@shilman Not a problem 👍🏼 |
@thany actually |
I'm having this issue as well. In my component I'm returning some JSX stored in an object based on a prop. If I wrap the return value in JSX it works however.
|
In my case, I'm not returning anything like that. It's a So @garand maybe open a separate issue because your situation is kind of different from what I think most people do in their components. |
@thany I'm experiencing this with Works:
DOESN'T Work: (no props on the table)
Update: It seems that just importing |
@taze-fullstack What about if you wrap the |
@garand I've removed my whole |
Repro for @taze-fullstack 's case. c8c19a2 |
@shilman I found another interesting resolution and point of investigation for you. I had three components:
After a short while I just sat back and compared the two React.FC components what I noticed is that the search which I had bought over from ES used:
Whereas the Select I had rewritten was using:
When I used the |
@sidhuko thanks for this! FYI we're going to switch form |
Importing react like that seems to fix some situations for me. Not all. Here are a few more situation where it magically doesn't work. Union interfacesNo props found for this component: const Modal: React.FC<ISpacingComponent<IModal>> If I change this to: const Modal: React.FC<IModal> Then the props from export interface IPaddings {
// Just some regular props here
}
export interface IMargins {
// Just some regular props here
}
type ISpacer = IPaddings & IMargins & {
/**
* Determines which element to render as.
*/
as?: keyof JSX.IntrinsicElements;
};
export type ISpacingComponent<Props> = Props & Partial<ISpacer>; So there's nothing too special about it. Typescript loves this, and intellisense works beautifully. I would imagine the typescript webpack loader thingy (I follow the documentation to the letter on this!) uses actual typescript, not its own little broken parser? forwardRef componentsconst FormInputCheckbox = React.forwardRef<Ref, React.PropsWithChildren<IFormInputCheckRadio>> This produces a different error:
Which is displayed in place of the "No props found for this component" message. Interface with extendsconst FormInputCheckboxList: React.FC<IFormInputCheckboxList> If I skim too quickly over the generated props table, it appears to work fine. But it's omitting a LOT of props actually. That might be because the webpack typescripter loader thingy chokes on this: interface IFormInputCheckboxList extends Omit<IFormInputCheckRadioList, 'onChange' | 'value'> {
value?: Array<string>;
onChange: (values: Array<string>) => void;
} Only Export orderIt seems that the typescript loader thingy naively assumes the last export in a module is the component we're after. Even if that export is a totally different one than the one being imported in the MDX doc: export default FormInputSelect;
export { OuterWrapper as Base }; Here, it blindly assumes import FormInputSelect from './controls/FormInputSelect'; Which is the DEFAULT import, clearly. So taking the last import what happens to be listed in a module, is just plain wrong. |
As for the "Union interfaces" situation, it seems to purely be the fact that I'm pulling intefaces from another module. Again, why does that make any difference at all? Who cares where my interfaces live? Should I repeat them in each and every component where I use them? Surely that's not the most productive solution... Just throwing this into the mix, not sure if it adds anything valuable to diagnosing the problem 😀 |
Is there already a solution for pure import styled from 'styled-components'
import PropTypes from 'prop-types'
const Card = styled.div`
background-color: ${props => props.theme.palette.primary.white};
box-shadow: 0 2px 3px 0 ${props => props.theme.palette.shadowGray};
width: 100%;
`
Card.propTypes = {
children: PropTypes.node.isRequired
}
export default Card |
Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks! |
@danielbayerlein I have the same problem. import-statement at the beginning of the file didn't help. |
It seems like babel-plugin-react-docgen can't parse styled components and set __docgenInfo. |
@SarahEW1206 see #10311 |
Debugging a lot I identified that babel was somehow removing the __docgenInfo property. So I made it work by installing this plugin: https://github.com/storybookjs/babel-plugin-react-docgen |
@jonasantonelli that's strange. |
It feel to me like everyone is writing their own little typescript parser to get this kind of information from the sourcecode. Why is it not possible to just to whatever VScode (or any other editor) does in order to get proper intellisense information? Certainly, code editors don't need these crappy unstable babel plugins to get intellisense information. They (or at least VScode) use the actual proper typescript engine, whichever version the editor or project comes with. |
Oww I understand now |
Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks! |
Hey there, it's me again! I am going close this issue to help our maintainers focus on the current development roadmap instead. If the issue mentioned is still a concern, please open a new ticket and mention this old one. Cheers and thanks for using Storybook! |
Describe the bug
Some components storybook cannot find/display props for.
I've scraped a couple of issues concerning this, but found no solution. It seems I've found another situation yet, where storybook is unable to show props.
To Reproduce
Steps to reproduce the behavior:
Sorry, I really have no idea what's "wrong" with my component to make it not show props. Otherwise I would've fixed, wouldn't I? So I also don't yet know what you need to do exactly, to reproduce it.
It works absolutely fine in intellisense, and typescript doesn't complain about implicit
any
types (which I disallow).Expected behavior
Should just show the props I've built.
Code snippets
In my doc, I'm just doing this:
System:
(Browsers is wrong, I'm actually on Firefox 72)
I'm on Storybook 5.3.8, and all plugins are, too.
I've just upgraded from 5.2.4 which also had this exact problem. It's almost like the upgrade didn't go through, but it did, because SB has decided to go darkmode, which is probably a new thing. I'm also on Typescript 3.6.4.
Additional context
I've tried these possible problems:
export const ComponentName
- I'm exporting a default, but changing it makes no difference.forwardRef
, or usesReact.memo
, or other React magic - not the case. It's just aReact.FC
type. No wrappers of any kind..babelrc
to.storybook
which makes it magcally find a syntax error inconfig.jsx
. Adding the@babel/preset-react
preset fixes this, but not the props table.The text was updated successfully, but these errors were encountered: