-
Notifications
You must be signed in to change notification settings - Fork 37
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
@internal by default #187
Comments
The render method could be added to the method denylist I suppose: Could you provide a code example of the other issue you mention, every variable thats not a prop? Why would you not want those documented exactly? |
@thepassle, thank you for your quick response. I am going to make an effort to make the issue as clear as possible. If I am stating the obvious, I'm doing it only for the purposes of leaving nothing ambiguous, and no condescension is intended. Again, I thank you and the team for your efforts here. My custom element has exposed fields-- props-- that are exposed on the interface and mutable by consuming web developers. My custom element also has an internal state, so I need internal variables. These are not exposed. There are also functions that I expose and internal functions that I do not. In Storybook, I want to expose and document props that a consuming developer has access to, not my internal state. Implementation details are not relevant to a Storybook story, and it's confusing to users when those internal variables are not differentiated in any way from the API available to them. I would think that the custom-elements-manifest is supposed to document a component's API. If I'm mistaken about that, that's at least how Storybook is interpreting it for the purposes of generating documentation. Therefore, an easy way to hide implementation details from the manifest would be very useful to users of this package. Right now, when I run
From this code, this
As you can see, there is no difference between property fields and others in the analysis; however, the non-prop fields are not part of the element's API. Finally, here is how this is interpreted by Storybook: Therefore, an easy way to interpret fields with Thanks again for your attention. EDIT: |
It does look like it's intended to work this way, so it's strange that it's writing all of the fields as props! |
Per the conversation in issue open-wc#187, added `render` to the denylist for Stencil.
I see the real issue here. The I'll go submit an issue there instead! Thanks again for all of your great work. |
Is there a reason Second, is is there a reason Stencil properties are mapped to |
Could you post a code snippet or a playground reproduction? I dont see this properties/attributes mentioned in your earlier snippet Stencil properties should be available both in the |
Sorry this is a new thread relating to getting the expected output in Storybook from my custom elements manifest. I am seeing that for Storybook, attributes (which are the fields I expect) are written to the argTypes dictionary, then overwritten by members, which contains all fields (including internal state). I tried deleting members from the JSON, then realized attributes only maps In order to get the docs I expect without internal fields, I copied missing keys from members to attributes, then deleted members. You can see that here: storybookjs/storybook#19414 You can see the difference in the |
Sorry, but this thread has become pretty confusing for me. If this is about the analyzer documenting pseudo-private properties (e.g. properties that are — in the case of Stencil — not denoted with a If you would like to still remove pseudo-private properties, you can do so with a custom plugin. |
I have the same problem: CEM documents properties that are interpreted by Storybook, whereas I would only like attributes. My component :
Generate CEM file :
|
I am using this package to create a manifest for my stencil project in order to generate docs in Storybook.
A major headache is marking every variable that is not a prop (which is already indicated by
@Prop()
) with the@internal
or@omit
decorators, or they will be treated just like props and appear as controls in the Storybook story (I know this is just as much Storybook's fault for ignoring the "private" field, among others).I also have to mark all internal functions, including
render()
, which I'd think would be omitted by the framework integration plugin.I didn't see any config options to assume
@internal
by default unless otherwise indicated. Is there an easy way to do this, would I need to copy the plugin and implement it myself?Thank you for this excellent work, by the way! My issues are minimal-- I am just trying to make things as easy as possible for the developers working on my project.
The text was updated successfully, but these errors were encountered: