-
Notifications
You must be signed in to change notification settings - Fork 61
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
Refactoring and v1.0.0 #125
Comments
Hey @runem ;-) Great summary 🎉 👏 My feedbacks as a nested list:
About JavaScript examples (sorry I can't judge TS): Example 1: The result table seems misaligned. I was expecting this:
Example 2:
Example 3:
|
Thank you so much for your feedback! :-) I've now fixed the problem in the example code 👍 Add 'public' if visibility is not provided? Below, I tried to output what WCA currently outputs using the markdown format. As you see, it only shows the "Visibility" column if one of the rows contain a non-public member. I think this works pretty well :-) Add 'no' if required is false? Pick up Below is actual markdown output from the analyzer on the example-1Properties
example-2Properties
example-3Attributes
Properties
|
Add 'public' if visibility is not provided?
Makes sens 👍 Add 'no' if required is false?
OK Pick up static get properties () when class doesn't extend LitElement?
I totally understand how it could be difficult. I guess users will probably rarely have this edge case. It's not worth it to invest in this. Below is actual markdown output from the analyzer on the refactor branchPerfect 👍 Great work @runem 👏 👏 👏 👏 I'm ready to try this with my components (I'm also looking forward for the fix about ternary operator) 😉 |
I just released I also released a beta version of the above 🎉 It would be really helpful to me if you would like to test it on the component that you were having trouble with in #124 - thank you so much for you help so far :-) You can test the beta version by running this: npx web-component-analyzer@1.0.0-next.1 analyze my-element.js |
I saw the
But hey, I missed this message about See you in a few minutes/hours... |
I'll directly try the |
With 1.0.0-next.9
Questions:
Sorry if my questions look too impatient 😄 this is great work 👍 👏 |
With this: /**
* Some docs
*
* @attr {string|number} datetime - Date as ISO string or timestamp
*/
export class CcDatetimeRelative extends HTMLElement {
static get observedAttributes () {
return ['datetime'];
}
get datetime () {
return this.getAttribute('datetime');
}
set datetime (value) {
this.setAttribute('datetime', value);
} I get this:
|
BTW: I tried the color type ;-) Works great in JSON but I guess the markdown template does not use it yet. |
Thank you so much for your feedback, I really appreciate it! 🤗 string | null: LitElement-specific methods: Document event type: /**
* @fires {string} change - This is a change event
*/ and /**
* @type {string}
*/
this.dispatchEvent(new CustomEvent("my-event")); (with This will however assume the type "string" to be the Include type in CSS property markdown:
|
@hsablonniere I'm not that experienced using the |
OK, so I tried with
LitElement-specific methods:
Document event type:
Include type in CSS property markdown:
Ah ah, I was expecting feedbacks from you, I don't really know what I'm doing with this :p
|
LitElement-sepcific methods:
|
We use https://github.com/vaadin/vaadin-accordion/tree/next |
| in markdown: I guess there is not solution for this because:
I say, let's keep the current behaviour, I have a plan to move away from this Storybook addon and use the JSON output at some point. LitElement-sepcific methods:
Great!! |
@web-padawan I knew you were not that far ;-) |
@runem I'm using the exact same pattern as what @web-padawan is doing with https://github.com/vaadin/vaadin-element-mixin/blob/master/vaadin-element-mixin.html The mixin: export function withMyMixin (ParentClass) {
return class extends ParentClass {
static mixinMethodFoo() {}
mixinMethodBar() {}
}
} Using the mixin: export class MyComponent extends withMyMixin(HTMLElement) {
// ...
} I guess the only differences are naming conventions and case sensitive code formatting ;-) |
Sorry, we should wait for a thread for this, I'll copy/paste the example... |
I just tried
About methods, as you know I don't use TypeScript and I was wondering how far we could go with JSDoc to document function object/array types... This is a method on my map component: /**
* This description works well and is picked up by WCA
* @param {Point[]} points - This description is ignored but I'm OK with it
* @param {PointsOptions} options - This description is ignored but I'm OK with it
*/
addPoints (points, options = {}) {} The thing is that I get | Method | Type | Description |
|-------------|------------------------------------------|-----------------------------------------------------|
| `addPoints` | `(points: any[], options?: any) => void` | This description works well and is picked up by WCA | |
@hsablonniere I support both your mixin pattern and what can be found in https://github.com/vaadin/vaadin-accordion 👍 @web-padawan I'm very interested in hearing if everything works for you. I tested it on https://github.com/vaadin/vaadin-accordion and chose to implement support for I also see that the export const DetailsStateMixin = <T extends VaadinDetailsBase>(base: T): DetailsControlState => {
const Base = ControlStateMixin(base as VaadinDetailsBase);
class VaadinDetailsStateMixin extends Base @hsablonniere Documenting primitive types like Also, if I were to output param descriptions, do you have an idea for how to include it in the markdown? Here are two suggestions:
|
@runem About function params, I would be OK with not having the param description at all but I think I prefer the first example with one description block and a list of params in the same block. |
Also, I will try the |
I was not able to make |
Small bug I noticed in the last component I'm updating. With this small test case: export class MyComponent extends LitElement {
firstUpdated () {
myChartLib.init({
fooMethod() {
// Hello
},
barMethod: () => {
// Hello
}
})
}
} The method ## Methods
| Method | Type |
|-------------|--------------|
| `fooMethod` | `() => void` | I had an example where I used this method pattern in a config object for charts.js and the method was picked up by WCA. As you can see, when I use an arrow function, it solves the problem. |
Sorry if I pollute this thread too much but I need to thank you @runem for all your efforts, I just finished refining our docs and it's awesome... 👍 I used to have a broken list of props, I used to manually write a markdown table to fix this. Many other small details are improved now!!! 👏 Example before: Example after: In case you're interested in how your tool improved our codebase, here's the commit: CleverCloud/clever-components@aca6a36 My next steps:
|
@hsablonniere It looks great! I'm really happy so see it working that well!! 🎉 Wrong methods getting picked upWhoops, great catch! This is because I don't check that the method is a member of the class 👍 Fixed in
|
Method | Type | Description |
---|---|---|
addPoints |
(points: Point[], options?: PointsOptions): void |
This description works well and is picked up by WCA points: This description is ignored but I'm OK with it options: This description is ignored but I'm OK with it |
I will soon release 1.0.0
so if we don't find any more problems during the next couple of days I plan on releasing 🎉
It works, thanks very much @runem 👍 👏 |
Is the methods data also included to JSON output? I would like to use it for Same question about the mixins. |
@web-padawan No, these are not included yet. We still haven't agreed on an optimal format for documenting |
@runem another question about the mixins: even though they are not included, can we at least get the properties implemented in mixins documented on the custom element? E.g. I have a separate mixin for handling |
I guess it makes sense but I think we should consider having custom extensions to the format. In OpenAPI, you can specify properties with |
I may want to document the i18n keys used by my component for example. |
@web-padawan properties found on mixins are documented on the custom element, so if you don't see the Be aware that currently there is one big limitation in WCA which I will work on addressing after v1.0.0. The limitation is that when consuming libraries shipped without Typescript definition files, the library code is not analyzed at all (for example using a mixin that is declared in a library). This is due to how the Typescript-parser works. There is, however, a solution to this 👍 In addition, everything seems to be working fine when I try WCA on for example the ./node_modules/@vaadin/control-state-mixin/control-state-mixin.d.ts
This is the analyzed inheritance tree:
Below follows the entire output which includes properties found on mixins vaadin-details
Mixins: DetailsStateMixin, ControlStateMixin Attributes
Properties
Methods
Events
Slots
CSS Shadow Parts
|
@runem thanks, will try how it works for us. |
Version I will close this issue now, but I'm creating some follow up issue for |
I have been spending the last couple of weeks on refactoring/improving many parts of the analyzer. Most notable, I have been improving performance, jsdoc-support and member-merging. Some of the requirements meant that I had to change core parts of the analyzer, eg. to support lazy-evaluation for performance improvements. Soon I'll be finishing up the work, push it to the branch
refactor
, and afterwards I will begin preparing a version1.0.0
release.The following is a description of what have changed. Feel free to give your feedback, thoughts or additional needs. It would be especially interesting to get some feedback on my examples of how component members are merged now.
Performance
In the past, the entire component, with all of its features, was analyzed when running the analyzer. This means, that an IDE-plugin discovering custom element tag names (eg. on startup) had to analyze all elements, which could result in performance issues. The analyzed components would often be of no use, because only a subset of components are actually used in a given source file. In order to address performance issues, I'm implementing the following 4 things in WCA:
Library exports
In order to use WCA in the browser such as https://runem.github.io/web-component-analyzer, I will make some changes to what this library exports. Specifically, I will:
Diagnostics and metadata
In the past, WCA was able to emit both documentation and diagnostics. In order to clean up things, I'm removing the functionality to emit diagnostics. Instead, it's now possible for WCA to add flavor-specific metadata to analyzed features that can be read programmatically. For example, the content of LitElement's
@property
decorator will now be available to read on the result. Thuslit-analyzer
will now be able to do more things with LitElement-specific information, eg. to emit diagnostics.JSDoc
I will look into supporting
@extends
,@mixes
,@example
,@method / @function
,@typedef
. I haven't started working on them, but the architecture supports it now :-) Existing supported jsdoc tags will work better because of improved merging logic.The architecture
I have been making a lot of changes to the way components are analyzed. It's now possible for flavors to hook into much more than before in a much cleaner flow. This image should give an overview of the architecture:
Analyzing and Merging
Each flavor finds features on components. Features can be "properties", "attributes", "slot", eg. Multiple features can be emitted per property (eg. if you have both a constructor assignment and a class field that reference the same property). I'm making a lot of changes to how these features are merged.
Here are some of the highlights:
required
) prefers the value of the first non-undefined value found@type
JSDoc. In JS-file the@type
JSDoc is preferred over the type checkerHere are some examples so you can see how merging will work. They are a bit contrived, but that's on purpose because I want to show how overlapping fields and comments are merged.
Examples using Javascript
Example 1
Result
Example 2
Result
Example 3
Result
Examples using Typescript
Example 1
Result
Example 2
Result
Example 3
Result
The text was updated successfully, but these errors were encountered: