Seeing argument types for Deno APIs requires to go through 3 separate pages.

[bartlomieju]

I want to see parameter types for Deno.chmod API.

To do that I go as follows:
https://doc-land.deno.dev/ -> click "Deno CLI APIs (stable) ->
https://doc-land.deno.dev/deno/stable -> select "Deno" namespace ->
https://doc-land.deno.dev/deno/stable/~/Deno -> select "chmod" function

This requires to go through 3 separate pages to see it.

I think I'd be nice if there was any indication about argument types on the page for "Deno" namespace.

[kitsonk]

I have been thinking about this.

The "problem" that I want to avoid is huge un-readable blocks of text. For example, expanding 10 classes in a mod.ts with the JSDoc blocks for each method and property is not workable. They really need a dedicated page to view.

That being said, I can agree the for functions and variables, having to navigate to too deep is just annoying.

So this is what I would suggest as a compromise:

• we flatten namespaces, but still preserve the namespace pages. So with builtins, you would have an entry for things like Deno.connect on the root page, but you could also navigate to https://doc.deno.land/deno/stable/~/Deno and just see the children of the Deno namespace.
• we expand functions and variables of the doc "listing" page, so instead of just Deno.connect on the index page, it would be Deno.connect(options: ConnectOptions): Promise<Conn> on https://doc.deno.land/deno/stable/ without any other navigation, but the JSDoc @param docs wouldn't be expanded, you would need to navigate to the page to get the "full" function documentation, just like today.

So, effectively in the use case above, it would just be just navigating to /deno/stable, but for something like Deno.File, you would see the entry on the index page as a class and the class level JSDoc, but you would need 1 click to navigate to /deno/stable/~/Deno.File to see what properties it had.