-
Notifications
You must be signed in to change notification settings - Fork 25.3k
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
Conversation
Deployed adev-preview for a502268 to: https://ng-dev-previews-fw--pr-angular-angular-55565-adev-prev-hv2tstou.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
64aea56
to
91b9854
Compare
51a35cf
to
4d92ea9
Compare
4d92ea9
to
a502268
Compare
a502268
to
a4e8820
Compare
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.
a4e8820
to
85e5bf8
Compare
Since this breaks the rendering of the docs, I'll wait for the docs generation to be integrated into this repo to continue. |
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. |
Pending angular/dev-infra#2020
Fixes #55556