-
Notifications
You must be signed in to change notification settings - Fork 841
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
[GSoC] Automatic Documentation System for TypeScript Components #3056
Comments
@ashikmeerankutty We'll use this issue to discuss and track modifications to your proposal. Comment in this thread and then I can assign the issue to you. |
@thompsongl Thanks! |
Should I continue this as a separate project outside |
What do you think, @chandlerprall? |
Let's move it inside eui; makes it easier to observer changes against any set of components |
Out of curiosity! I just tried adding the plugin to
|
Sounds like it's processing TypeScript code 😀
Sweet!
The only way to make things better :) Did you remove the existing Next week, I can help look into any issues you're not sure about. If this is too much of a problem right now, there's no rush on moving it into EUI. |
No, I will try removing that.
It doesn't seem to be trouble. I think it's better to continue in eui. I will get a lot of components to try. |
Just found a webpack loader that uses react-docgen-typescript 😐. |
How well does that loader / react-docgen-typescript work with components like EuiButton, which has a mix of our custom eui/src/components/badge/badge.tsx Lines 97 to 102 in c9ae5a0
Second aspect of react-docgen-typescript that wasn't great in the past was whether or not it supports types from 3rd party libs / node_modules. Ideally, I think we'd want to white list some like react-beautiful-dnd, either including the types directly or even maybe creating a link to their documentation. And we also don't want to lose support for generating prop types. |
Example of a prop
|
@chandlerprall Should I proceed in this way or with the plugin. |
@thompsongl what do you think, especially in context of feeding these results/data into the docs stuff? |
Is this the same for the webpack loader? What deficiencies (if any) does the webpack loader have when compared with the plugin? |
Good catch, I dropped that context. We'd (ideally) need a way to get those results without running webpack |
Yes, the webpack-loader provides all the functionalities of react-docgen-typescript. I haven't found any deficiencies with the loader. But I hope creating a custom plugin gives more control on the parser especially for some eui specific needs (if any). |
Thanks for the clarification. I should continue with the plugin. 😅 |
43 minutes is just a little much 😁 |
Sure!
Those are coming from the typescript types/interfaces being imported between files, but those values don't exist after the typescript preset takes its pass. We added logic in our custom |
Yes, we'll want to make sure any existing |
@chandlerprall I can`t think of a suitable comment for the same. Can you please suggest one 😐 |
Let's start with,
|
There is also an issue with |
Does it produce results with simple |
Yes |
I'm facing a weird issue in my plugin. I couldn't figure it till now. Exported types from |
The above issue was fixed using |
It seems like this change eui/src-docs/src/views/accessibility/accessibility_example.js Lines 119 to 121 in 1259952
is not necessary while using the new plugin. Can I change it ? |
Manually checked all components to make sure that props are generated. Props are generated for 90% components even though there are issues with some prop types. |
What was the reason for adding the |
We can convert all |
The |
Go ahead and change it if it is no longer the source of problems |
This would be follow up work to the PR you already have open, but we'd also like to find a way to directly include types and interfaces in the Props table (see #1688) Tables are good example of this. We manually add complex types and interfaces through a propsInfo hack so that consumers can see subcomponent types in the table. For instance, |
One workaround for this issue I just found was to create a component called
In the generated We could then pass it like
The issue here if two of the interface contains the same props only one among them will be shown. |
Thanks for looking into it. Let's move discussion to that issue (#1688). |
Reopening this so all the tracking continues in one issue. @ashikmeerankutty, please list any follow-up work to #3554 that you plan on doing (#3554 (review); sorting the props, for instance) |
Follow ups
|
@ashikmeerankutty Thank you so much for all the work you did on this project!!! 🎉 🎉 I know our all our Elastic engineers are extremely grateful for a more robust and reliable prop table with real Typescript types. The "Extends" bit, while seemingly small, is a game changer! Best of luck to you in future endeavors! |
@ashikmeerankutty I merged #3944, which checks the last box here 🎉 Just make sure you submit all your GSoC evaluations, etc. before the deadline later this week (if you haven't already). @cchaos is right: we're all thrilled with how it turned out! You did fantastic work over the last few months 🚀 |
🙌 |
@cchaos @thompsongl @chandlerprall Thanks for all your support. It was wonderful working with you 😃 |
A better automatic system for documenting EUI TypeScript components. Specifically, we're looking for a better method to extract the acceptable values for each prop on the API. This would be done through automatic transversal of the EUI components itself, combined with the type values from TS and our own inline comments.
Outcome
More accurate, robust prop documentation within the existing "Props" tab for each example section in component documentation. As the EUI team is nearing completion of complete TypeScript conversion, it is possible that the current type and prop traversal system can be entirely replaced.
Related Discussion
props
option in the docs #1688; sometimes manual documentation will still be needed/helpfulInterested in working on EUI for Google Summer of Code? See more details here: https://github.com/elastic/gsoc
The text was updated successfully, but these errors were encountered: