senchalabs / jsduck

Simple JavaScript Duckumentation generator.
http://docs.sencha.com/
GNU General Public License v3.0
1.5k stars 238 forks source link

Control depth when displaying inherited members #314

Open dpashkevich opened 11 years ago

dpashkevich commented 11 years ago

Vision

I've now used jsduck for quite a while and realized a need for a finer control over the display of inherited members. Long story short, I suggest turning the checkbox "Show Inherited" into some sort of slider, here's a mockup of my vision: inheritance-depth

The slider would allow to control the depth of displayed inheritance chain at the moment. For example, when viewing doc page for Ext.grid.View, display only members defined on Ext.grid.View itself and Ext.view.Table (i.e. one level deep).

Rationale

Here are the main two cases where I think the feature would be useful.

Navigating in a deeply nested class hierarchy

The ExtJS framework itself has a pretty huge class hierarchy, with lots of intermediary abstract classes introduced. Say I am trying to customize Ext.grid.View and want to see what are the configuration options specific to that component. Unchecking the box Show Inherited (to filter out the generic stuff inherited from fundamental classes) won't yield a useful result since 99% of its members are defined in its immediate parent class - Ext.view.Table which isn't meant to be used directly but it's there. So I end up making an extra step - navigating to Ext.view.Table docs to see some useful config properties such as firstCls, overItemCls, stripeRows, etc.

Now this is just one example and maybe not the best example since Ext.grid.View doesn't really add anything new over Ext.view.Table and I could get all necessary information by just looking at the latter with Show Iherited unchecked. But it still makes the point of extra navigation steps. If Ext.grid.View had more of its own code I would end up constantly going back and forth between the two classes in the docs to find out about common config options and/or behavior (the classes are still closely related).

One can find many other similar examples throughout the framework where there are two or more classes named AbstractXXX and XXX (and perhaps GroupingXXX :smile:) and the binary option "Show Inherited" doesn't really help you filter out members from basic classes and leave only ones related to a topic.

Separating my code from ExtJS code

I really love the fact that I can compile both ExtJS docs and my project docs into one place so I don't have to switch between two browser tabs to view them. But again, with a long inheritance chain like this:

Ext.Base
    Ext.AbstractComponent
        Ext.Component
            Ext.container.AbstractContainer
                ...
                My.AAA
                    My.BBB
                        My.CCC

I may wish to temporarily hide the "visual noise" inherited from Ext's base classes (and not overridden by my code) and only view the stuff introduced by my code.

Hope this all makes sense and I'm looking forward to hearing what you think about this idea.

nene commented 11 years ago

I definitely agree with you. That would be a nice feature. Something like this has been asked for several times before.

The main trick is implementing the right UI for it. All the data is already there, and the existing filtering code should be relatively easy to extend.

But when will I actually get to doing it, hard to tell...