feat(compiler): expand class api doc extraction#51685
feat(compiler): expand class api doc extraction#51685jelbourn wants to merge 2 commits intoangular:mainfrom
Conversation
d9bac82 to
dd1beb9
Compare
There was a problem hiding this comment.
My understanding is that concat is faster than push with destructuring, no?
There was a problem hiding this comment.
Not sure that performance matters here, and I'm also not sure if this is true anymore.
Feel to just leave as is. This is a nit (but you used push in other places)
There was a problem hiding this comment.
Out of curiosity, is there a trusted source for the perf comparison? The best I could find myself was just running a benchmark https://www.measurethat.net/Benchmarks/Show/13985/0/concat-two-arrays-push-vs-destructuring
There was a problem hiding this comment.
One thing I'd like to start conversation on: In Dgeni our TypeScript extraction was ultimately only "documenting" symbols that were exported from the package entry-point. e.g. @angular/core/index.
Are we always analyzing everything, or should we rather traverse based on the entry-point and e.g. discover/extract referenced members?
There was a problem hiding this comment.
I'm going to worry about filtering down the set of APIs we either extract or document later in the process; for now I'm focusing on extracting all of the information we need for docs. But yeah, it's reasonable to use an entry-point rather than all files in the program.
There was a problem hiding this comment.
Nit: I know this is still TODO, but I think we could use the compiler type for ClassDeclaration, or maybe even the reflector. That way we wouldn't need the non-null assert. See TypeScriptReflectionHost.
There was a problem hiding this comment.
I've already done this in a follow-up commit, so I'll leave it as-is for this one.
There was a problem hiding this comment.
Is there really the concept of an optional member? seems like this information is not useful for documentation? and technically it just means that something can be undefined. This can also be expressed using an explicit type. e.g.
bla: string|undefined;There was a problem hiding this comment.
There is nuance between a member being optional and accepting an undefined value. This matters for config objects:
https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgLJzAEWHANgewHMBhfEGYQ5AbwChlkxgxcIAuZAZzClEIG56yOLzgAZOACMIuDt14gqAH2QBXEABMIFEBA2CAvrVqhIsRCnRgAyiEQBrSSNLlKNIUxbsuPPoIYiOBLSuAD8cr6KhsYw6ghMZMj4AA4QINh4RAAUCGQUhBxWGQQkeZQAlO4MuSCc+KwAdCU5ZYTl0bSxIPHAiSlptg5OUC2uBWgYgwiOzq2VdNVkdY3NNfnttEa0-ek4zQuMzKwcAOTWEGBMipwnmxvbqSBTMyMHnsfIJwCCrFBgJwAaO78IA
When a config field is optional, you can omit it. When the value may be undefined, you must still specify the field.
There was a problem hiding this comment.
That makes sense. Might be worth adding a comment for this. nly thinking about this in the context of "describing the member in a local sense".
There was a problem hiding this comment.
For the above checks, I'd recommend using ts.isMethodDeclaration etc to avoid the casts
There was a problem hiding this comment.
Oh, I meant to use my own utility method here and forgot to follow through, but also hadn't realized isMethodDeclaration and isPropertyDeclaration existed, so I've replaced them all with these.
There was a problem hiding this comment.
Just an early question based on our discussions: Do we plan on using the metadata from the existing ngtsc decorator handlers, or will we just have our own simpler extraction here that we co-maintain in @angular/compiler-cli?
There was a problem hiding this comment.
Yeah, this will reuse the existing metadata reader
dd1beb9 to
a68f776
Compare
jelbourn
left a comment
There was a problem hiding this comment.
Comments addressed
There was a problem hiding this comment.
My understanding is that concat is faster than push with destructuring, no?
There was a problem hiding this comment.
There is nuance between a member being optional and accepting an undefined value. This matters for config objects:
https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgLJzAEWHANgewHMBhfEGYQ5AbwChlkxgxcIAuZAZzClEIG56yOLzgAZOACMIuDt14gqAH2QBXEABMIFEBA2CAvrVqhIsRCnRgAyiEQBrSSNLlKNIUxbsuPPoIYiOBLSuAD8cr6KhsYw6ghMZMj4AA4QINh4RAAUCGQUhBxWGQQkeZQAlO4MuSCc+KwAdCU5ZYTl0bSxIPHAiSlptg5OUC2uBWgYgwiOzq2VdNVkdY3NNfnttEa0-ek4zQuMzKwcAOTWEGBMipwnmxvbqSBTMyMHnsfIJwCCrFBgJwAaO78IA
When a config field is optional, you can omit it. When the value may be undefined, you must still specify the field.
There was a problem hiding this comment.
I'm going to worry about filtering down the set of APIs we either extract or document later in the process; for now I'm focusing on extracting all of the information we need for docs. But yeah, it's reasonable to use an entry-point rather than all files in the program.
There was a problem hiding this comment.
I've already done this in a follow-up commit, so I'll leave it as-is for this one.
There was a problem hiding this comment.
Oh, I meant to use my own utility method here and forgot to follow through, but also hadn't realized isMethodDeclaration and isPropertyDeclaration existed, so I've replaced them all with these.
There was a problem hiding this comment.
Yeah, this will reuse the existing metadata reader
There was a problem hiding this comment.
Any reason for these to be string enums?
There was a problem hiding this comment.
They'll need to be serialized to json, and this makes them both stable and human-readable
There was a problem hiding this comment.
nit: I feel like the enums should be UpperCamelCase (though the internal TS style guide says CONSTANT_CASE)
There was a problem hiding this comment.
Ack, I'll change this in a follow-up commit since doing it here will be merge conflict city
a68f776 to
e364379
Compare
This commit adds a barebones skeleton for extracting information to be used for extracting info that can be used for API reference generation. Subsequent PRs will expand on this with increasingly real extraction. I started with @alxhub's angular#51615 and very slightly polished to get to this minimal commit.
Based on top of angular#51682 This expands on the skeleton previously added to extract docs info for classes, including properties, methods, and method parameters. Type information and Angular-specific info (e.g. inputs) will come in future PRs.
e364379 to
5d962ad
Compare
Based on top of angular#51685 This expands on the extraction with information for directives, including inputs and outputs. As part of this change, I've refactored the extraction code related to class and to directives into their own extractor classes to more cleanly separate extraction logic based on type of statement.
Based on top of angular#51685 This expands on the extraction with information for directives, including inputs and outputs. As part of this change, I've refactored the extraction code related to class and to directives into their own extractor classes to more cleanly separate extraction logic based on type of statement.
Based on top of #51685 This expands on the extraction with information for directives, including inputs and outputs. As part of this change, I've refactored the extraction code related to class and to directives into their own extractor classes to more cleanly separate extraction logic based on type of statement. PR Close #51733
|
Changes merged in #51733 |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Based on top of #51682
This expands on the skeleton previously added to extract docs info for classes, including properties, methods, and method parameters. Type information and Angular-specific info (e.g. inputs) will come in future PRs.
cc @devversion in case you're interested