Repository navigation
Suggestion: Return type in function declaration & possible option to view types by clicking in doc #14624
Description
Activity
Most functions (not
url.parse()it seems, unfortunately) have a "Returns: " bit, like urlSearchParams.entries(). While a good idea, I'm somewhat worried that writing the returned type would crowd the heading too much for a function with long parameter names likeurl.parse().Yeah I'm not really for putting it in the heading either
Reacted by Tobias NießenReacted by Louise Süsslin@Fishrock123 A reasoning would be nice
Easiest argument against it is that that would break links to the docs. Fixing that would probably be non-trivial in the build tooling.
Another is that the return type is already listed.
That being said, while we do have some function with different "argument signatures", it just doesn't operate int he same was a typed language does and as such I'm not certain the same notation is desirable.
Finally, this gets really messy when dealing with async functions that call callbacks with data. (Which most of the significant API is.)
- Reacted by Louise SüsslinReacted by Louise Süsslin
Closing this, discussion can continue on the closed thread if needed.
The
Returnssyntax I mentioned is now in the style guide, so feel free to raise PRs to addReturns:anywhere that needs it.
While working with Node.js, I found having the return types of a function (If given) in the function declaration instead of somewhere in the paragraph below it (As seen in the example following) might improve the documentation.
Further on, it would most likely be useful to be able to click on the types. Both suggestions are popular documentation features, example is the Rust Documentation
Here a screenshot of what I mean
