The Instance class is beefy. When I previously worked on the Roblox wiki, I had this feature for collapsing certain member inheritances in order to better present the information to developers.
The DevHub currently doesn’t have support for this, but I think it would be a beneficial addition to help reduce redundant information. I think this is one of the reasons why people are complaining about “vertical space” on the DevHub.
For reference, this is (roughly) what it looked like on the wiki:
It may be obvious for veteran developers, but for new developers (one of the primary audiences of documentation), this information is extremely important. Think back to when Part didn’t have any of the inherited from BasePart members – that’s going to be new user experience for all members inherited from Instance.
Instead of hiding symptoms, we should address the root problem and fix the dev-hub being so overly-bloated. For example, the size of these members is more than halved with more-appropriate design:
My opinion is that, if I’m browsing a particular class page, then it means I’m only interested in the members defined by the class. I do understand the value of including all members for non-veteran users, though. I would settle for having these sections expanded by default, then adding a show/hide-all button and some cookie magic to remember the setting.
I agree that we have to strike a balance between being explicit for new users and efficient for experienced ones. I think there are some good tactical suggestions in this thread (more compact layout, remembering collapsed sections, etc). I’ll see if we can get something slotted in soon to address this.
I agree with him in the regards that this should be controlled by user preference, such as remembering what parts of a page were collapsed previously. Perhaps the defaults can be specified on a case by case basis where it makes the most sense.
In some cases it makes sense to show the members inherited by the Instance class (like ReplicatedStorage, which stores children and descendants, among other things) and in others it doesn’t (like Path, which doesn’t interact with the DataModel hierarchy at all).
If this is specifically for classes where Instance members don’t matter (i.e. you’re fine with Instance members showing up for Part/Decal/etc), then these specific objects should be marked as [not-used] or similar in the API and automatically hidden in documentation. User preference toggle is not a good solution for this use case because it means I have to manually hide inherited from Instance on every page if enabled per page, or if not enabled per page, once I open it on Part, when I go to Path I have to close it. Once I close it on Path, I have to re-open it on Part.
I would want to see Shape in its own section, followed by further sections for each inherited set of members (this is the current layout). The idea is that, if I’ve gone to a specific page (e.g. Part rather than BasePart), then it means I want to see only the members defined by that class. If that isn’t the case (e.g. I’m unsure of the member name), then there are still the inherited-from sections to work with as a fallback.
As a veteran user, having these sections collapsed is less information that I would have to parse. However, it would be inconvenient if I had to manually collapse sections every time I visited a page, hence the suggestion of cookie magic.
I disagree. I’m talking about a setting that causes all inherited-from sections to be either expanded or collapsed. The state is expand-all by default, for the convenience of novice users. Veteran users use the collapse-all state to reduce the amount of visible information on the page. In this case, they can expand particular sections manually, but doing so causes no permanent state changes.
Storing any more state than this sounds like a nightmare for consistency and muscle memory. It might be neat to have in the short term while your working extensively with a particular class. Long term, navigating to that class to find it in a now-apparently random state would be nothing but obnoxious.
As EchoReaper mentioned above though, circumstances like the Part class would be weird because its only direct member is the Shape property. People likely visit the Part class page more than they visit the BasePart page, and having to switch everything on and off depending on what class page you’re on would feel a bit clumsy imo.
I’m not sure if there’s a clean compromise to all of these edge cases. Ultimately what I want to target in this case is inheritance is getting in the way of clearly presenting information. The default collapsed states could perhaps be groomed on a case-by-case basis, based on what information is more important to be focused on in the page.
It may be obvious for veteran developers, but for new developers (one of the primary audiences of documentation), this information is extremely important. Think back to when Part didn’t have any of the inherited from BasePart members – that’s going to be new user experience for all members inherited from Instance.