Redundancy makes navigation of SOLID API difficult

[cefn]

Hi and thanks for Typedoc!

It offers an amazing start and I accept I should theme if I need something different. However, thought I should share that for my very simple case the default theme tends to push all the meaningful information 'below the fold' by redundant information which could probably be fixed by changing defaults.

From the top to the bottom, referencing the screenshot above...

• The Lock interface visibly has a generic parameter Key in its declaration. Nevertheless 112 vertical pixels are dedicated to a block containing three words "Type Parameters...Key"
• The Lock interface is a top-level interface with no hierarchy. Nevertheless another 100 pixels are dedicated to a block stating "Hierarchy...Lock"
• The Lock interface is designed with a simple API and single responsibility. It's sole acquire property is already visible in the index in the navigation tree to the right of the page and its full definition would be visible except that 150 pixels are dedicated to a block stating "Index...Properties...acquire".

Combined, these elements push all of the API details out of site below the viewport. I can't help thinking that these cases might be eliminated in more opinionated model-generation or template logic.

A) Is a Generic parameters block necessary given the visible declaration already in the header
B) Is a Hierarchy block for something without a Hierarchy necessary.
C) Is a property index necessary when there are property trees for Lock already rendered to the right. It also takes a lot of prime space. Perhaps it could have less whitespace and vertical structure if it remains?

Thoughts

If I was to approach solving it for my case via typedoc flags or a specialised typedoc theme is there any value in me trying to PR changes back to the main project or themes that you might accept or have been considering anyway?

Alternative View

The alternative view shown below comes from manually deleting the redundant blocks described from the first screenshot. After this change, within the 800 or so vertical pixels the complete API for this interface is visible. It still has some redundancy given the type declaration for acquire shown twice for no obvious reason but it's much better.

[Gerrit0]

A) Is a Generic parameters block necessary given the visible declaration already in the header

The header only includes the type parameter names, it will not include the constraint (if any) or comments attached to the type parameter.

B) Is a Hierarchy block for something without a Hierarchy necessary.

Definitely not! I didn't even think it was displayed... Should be an easy fix https://github.com/TypeStrong/typedoc/blob/master/src/lib/converter/plugins/TypePlugin.ts#L134

C) Is a property index necessary when there are property trees for Lock already rendered to the right. It also takes a lot of prime space. Perhaps it could have less whitespace and vertical structure if it remains?

The index does more than just list properties, it groups them by type, and if some reflections are marked with the @category tag, then they will be grouped using that as well. For your example, it's definitely not that useful, but I think it makes a lot of sense for modules.

type declaration for acquire shown twice for no obvious reason

This is because the type is defined using a property instead of a method, and wasn't caught by TypeDoc's special casing for property-methods.

I'm definitely open to improvements to the theme, I believe there's lots of things that could be improved.