Open dpashkevich opened 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...
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:
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 onExt.grid.View
itself andExt.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 toExt.view.Table
docs to see some useful config properties such asfirstCls
,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 overExt.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. IfExt.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
andXXX
(and perhapsGroupingXXX
: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:
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.