The dozens of quirks and issues with Roblox's API documentation, and some stuff I'd like to see

Hio.

So I’ve been an editor on the Roblox wiki for awhile now, and with the introduction of the Developer Content Engineer position, I don’t know how much longer I’ll be able to do work on the wiki since its being switched over to Confluence.

There are a lot of issues with Roblox’s exported API data that I personally think should be changed.

The API Dump

The API Dump is really weird. Because its designed to be readable by humans, this makes it very difficult for it to be parsed with code, and it lacks a lot of important information.

Some information that is missing includes:

  • No indication that certain classes are purely [abstract] (Documentation - Roblox Creator Hub) (such as BasePlayerGui), and thus they only exist for the sake of inheriting certain members.
  • No indication that certain classes are services
  • No indication that certain classes are settings
  • No indication that certain classes can only be created in certain contexts.
  • Members that can be seen from the Property window (Workspace.PGSPhysicsSolverEnabled, MeshPart.CollisionFidelity, etc) that don’t get exported in the API Dump due to the fact that they aren’t scriptable members.
  • The API Dump is based on what API exists in the windows client, and there are some APIs that are exclusive to Studio, like game:GetObjects(Content url)
  • No dump of the built-in datatypes like Vector3 and CFrame
  • No way to indicate if a member is enabled or not (behind FFlags)
  • Sometimes it has really vague parameters and return types, such as Tuple, array, dictionary, etc (no proper description of what is actually contained in these arrays!)
  • Some return types are only labeled as “Object” or “Instance” without any indication of what class it actually is.

I really think the API Dump should be updated to use a beautified JSON format, so that it would be significantly easier to work with it as far as the code aspects go.

Class Icons

The default class icons are boring.

As demonstrated on @Anaminus’s API reference page, a lot of the class icons are just these boring blue boxes. There is no characterization of these classes, and even if they aren’t being shown in the Explorer I still think they could benefit from having their own icons. I hacked a lot of icons in for myself, as seen on the class reference page. Classes that are abstract have a special icon.

It would be awesome if the explorer icons were exposed as actual image files that we can modify, instead of them being embedded inside of Studio. I also think we should have an option to make more services visible in the Explorer without having to hack at the Reflection Metadata.

ReflectionService

One of the things I’d really like to see implemented at some point is a ReflectionService that allows developers to get metadata about classes and members. This could be used for a wide variety of things, such as autonomously hooking change listeners to all existing members of a class that can be altered, or serializing instances as string data that can be pushed into DataStores.


That’s all I’ve got for now. I’ll probably update this with more details later.
Here are some handy links:

List of internal members that really shouldn’t be in the API Dump:

A list of API change proposals that I think would be nice:

cc @UristMcSparks

14 Likes