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
docs: show overloads for functions #55565
base: main
Are you sure you want to change the base?
Conversation
Deployed adev-preview for 91b9854 to: https://ng-dev-previews-fw--pr-angular-angular-55565-adev-prev-nmdfexi2.web.app Note: As new commits are pushed to this pull request, this link is updated after the preview is rebuilt. |
68a91a7
to
2f7994b
Compare
a95b7ee
to
23c7caf
Compare
23c7caf
to
7d4aef9
Compare
I haven't looked in depth yet, but I'd appreciate if the tooling updates can be pulled out into a dedicated commit, independent of the compiler changes for multiple signatures. |
Sure, let me split the changes into 2 commits. |
7d4aef9
to
90f5af1
Compare
@@ -134,6 +134,10 @@ export interface FunctionEntry extends DocEntry { | |||
isNewType: boolean; | |||
} | |||
|
|||
export interface FunctionWithOverloadsEntry extends FunctionEntry { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should instead re-use what I've built for initializer APIs: FunctionWithOverloads
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think function extractor should instead return such entry, which has clear implementation
+ signatures
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about reusing it too but went with another type because the extractor needs to return a DocEntry
which FunctionWithOverloads
doesnt extend.
I'm still open to suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking about an entry like we have for initializer APIs, with clear separation of implementation + signatures. Maybe we can share that one and use for both? and name it FunctionEntry
, while the existing FunctionEntry
becomes FunctionMetadata
or similar
in order for the docs to process function entry, this commit refactor function extraction by keeping the implementation as a the default entry and adds all the overloads into a separate array of entries.
90f5af1
to
64aea56
Compare
64aea56
to
91b9854
Compare
Pending angular/dev-infra#2020
Fixes #55556