denoland / dotland

[Archived] deno.land website
https://deno.land
MIT License
957 stars 626 forks source link

feat: add built-in APIs #2428

Closed crowlKats closed 2 years ago

crowlKats commented 2 years ago

Towards #2364

kitsonk commented 2 years ago

The index just feels messy at the moment.

Compare what we get for a index of a module:

std_0_155_0___Deno

Versus what we get for APIs:

API___Deno

Because the index of a module is broken up by symbol type, you get a nice alphabetical list for each section. In built-ins the sorting by symbol type still happens in each section, making a very confusing mess when trying to read through it. Feels like we should sort each section alphabetically. I suspect it is also going to be a problem for the nav as well, in modules, you generally deal with a much smaller set of symbols, meaning the kind sort is slightly less problematic, though I have always felt it should be sorted alphabetically.

Also, there is really no context, indication for users unfamiliar with Deno what they are looking at. Where authors have an opportunity to provide module doc for a module to provide context, we have nothing here. Also the place where you look to figure out where you are (the grey bar at the top for std and x) is missing, feeling very inconsistent visually.

Maybe we can add some text, like for stable:

There are APIs that are built into the Deno CLI that are beyond those that are built-ins for JavaScript. They are a combination of web platform APIs Deno has implemented and Deno specific APIs. We try to keep non-standard, Deno specific, APIs in the Deno namespace. We have grouped the APIs into the following functional categories.

For unstable:

There are APIs that are built into the Deno CLI that are beyond those that are built-ins for JavaScript, including APIs that are unstable or experimental. In order to use APIs marked as unstable, you will need to use --unstable on the command line to make them available. All the APIs are a combination of web platform APIs Deno has implemented and Deno specific APIs. We try to keep non-standard, Deno specific, APIs in the Deno namespace. We have grouped the APIs into the following functional categories.

It also feels like we should, in addition to the deprecated tag, display the unstable tag (and maybe the permission tags) in the index?

crowlKats commented 2 years ago

in addition to the deprecated tag, display the unstable tag (and maybe the permission tags) in the index?

Yes, unstable for sure; permission not sure. we need more space, will need a bit of a redesign

crowlKats commented 2 years ago

Also, there is really no context, indication for users unfamiliar with Deno what they are looking at. Where authors have an opportunity to provide module doc for a module to provide context, we have nothing here. Also the place where you look to figure out where you are (the grey bar at the top for std and x) is missing, feeling very inconsistent visually.

It does say Runtime APIs above the sidepanel, and has the API entry in the header highlighted, i think its fairly obvious where you currently are, and the gray bar at top for modules makes little sense to reuse for built-ins as we dont have breadcrumbs, popularity rating & description (i guess the latter could be could be worked around) for built-ins and wouldnt make sense. Also we are treating manual & built-ins as similar things for viewing and learning the functionalities of deno, and the gray bar wouldnt work for the manual.

kitsonk commented 2 years ago

and the gray bar at top for modules makes little sense to reuse for built-ins as we dont have breadcrumbs

namespace breadcrumbs? You totally lose your place here: https://dotland-9sj0b66nphxg.deno-staging.dev/api@v1.25.2?unstable=&s=Deno.errors. It is arguable the title should be Deno.errors instead of just errors too.

modules makes little sense to reuse for built-ins as we dont have breadcrumbs, popularity rating & description (i guess the latter could be could be worked around)

Though, the category could go up there where the description is, and the version list could be in the same place. Outside of it being inconsistent, especially the index, it is just a "what the hell is this" problem... we know, it is built-in APIs but we aren't the people that are going to be using it and it is too sparse and too unlike std and x.