Inherited Classes should be listed in API documentation

[bigcrazycarboy]

Hi guys,
I couldn’t help but notice that the new developer hub is lacking the inherited objects section. Here are some reasons we should keep this section in there (very sorry if you guys now have to revise all the threads you’ve already made, but I think it would be very useful)

• Buttons
  New developers won’t know to run (if v:isA(“GuiButton”)), and instead they’ll try to run (if v:isA(“TextButton”) or v:isA(“ImageButton”) or …)

-Parts
A lot of classes inherit the abstract Basepart class. Using Basepart is very useful as we all know.

I think that should be enough to make my point clear - at the moment I’ve got to say I was liking the old wiki a bit better, but I know the hub is still in development so I’ll have some mercy at the moment. I just don’t want any loss of functionality when porting the old wiki to the hub. Other than the content, I like the site layout a bit better. Thanks!
-big

[Egzekiel]

Support, other exemples are ValueBase (like IntValue, BoolValue) or BodyMover (like BodyForce, BodyPosition).
It doesn’t show those on the wiki page of the objects.

[ArchiveChampion]

This is good feedback.

What you can do currently, is enable ‘Class Tree’ view on the left hand side collapsable side-bar. Then you can see a full class tree of inherritance.

[EchoReaper]

Class tree is no good in its current state. Example of trying to find the class HingeConstraint inherits:

https://gfycat.com/CalmBrightAmericanquarterhorse

I know there is search, but I’m not going to move my cursor all the way to the search bar, remove my hand from the mouse so I can type, and then switch back to the mouse – that’s way too much work, and the devhub sidebar relies too much on the search bar for how little it helps.

This could be improved by opening the class tree to the location of the current class being viewed, but in general, such a long list of objects is not very usable and should be avoided. When looking at HingeConstraint, I don’t care what StringValue or Frame inherit from – the class tree is just a bunch of information that’s not relevant to me. The

ThisClass > SuperClass > SuperClass’s SuperClass

design of the wiki did a really good job at providing necessary information without making it hard to find in a bunch of fluff.

[ArchiveChampion]

We hear your feedback - thank you for the detailed response.

[ColdSmoke]

This is still an issue. The old Wiki had this information laid out which really helps in discovery of related classes for different use cases.

(From the old wiki)

^ From JointInstance page

^From Weld page

[bigcrazycarboy]

Although it’s not as clean as how it used to be, you will see subtitles called “Inherited from: Basepart” (for example) and if you trace that back all the way it’ll take you to the parent abstract class. Although, I did like the hierarchical look it had before…

[ColdSmoke]

It still lacks the ability to find what classes inherit the class you’re looking at. I wouldn’t really consider this issue solved. Currently I’m trying to view all classes that inherit GuiObject so that I can decide whether or not this is the proper class level for this filter I’m scripting. Not being able to see the context of this class in relation to the other classes makes this a way slower process

Edit: I did just notice the class tree menu that ArchiveChampion mentioned above, but man it’s just so much less convenient than the way the wiki used to be, and pretty unusable

[bigcrazycarboy]

The class tree is as close as we’re getting right now I think. I liked it better when it filtered out all the other classes that you’re not gonna be looking at so you don’t have to scroll for 15 minutes to find the class you’re looking for. You could CTRL+F for it, but that’s no excuse for the web design to be less intuitive. I marked this solved because, fundamentally, it’s the same I guess. Old one was better though.