GeezerVison is showing github.com — Option to specify default non-categorized/grouped reflection name · Issue #2922 · TypeStrong/typedoc
Option to specify default non-categorized/grouped reflection name #2922DescriptionSearch Terms
none, default category, default group, top-level navigation
Problem
I try to make documentation navigation structure like next (with most common usage entities in top level navigation, without hidden its behind category/group dropdown element).
- Entity1
- Entity2
- ...
- Advanced category
-- Advanced category Entity 1
-- Advanced category Entity 2
-- ...
- Internal category
-- Internal category Entity 1
-- Internal category Entity 2
-- ...
I found code
|
const none = reflection.find((x) => x.title.toLocaleLowerCase() === "none"); |
, so I named category for top level navigation entities None to get the behavior I want.
But in modules documentation page shows category name None, it's not very nice, I would like to be able to change this default name.
I do this with categoriest, but I think this works similarly with groups too.
Suggested Solution
Add option for TypeDoc to change default name for non-collectibles reflections. ActivityGerrit0 commented on Apr 1, 2025 Would it be better for the modules page to be rendered like the navigation, leaving those elements outside of a group/category entirely? sergeiivankov commented on Apr 2, 2025 I think this is a good solution. On the other hand, in the current version there is an option to specify a description of the base category (entity without a category), in your proposal, if I understand correctly, there will be no such option. Gerrit0 commented on Apr 2, 2025 The category description should be unnecessary, the top of the module page renders the comment for the module, which seems like it ought to be sufficient to me... pjeby commented on Apr 4, 2025 Possibly related: there doesn't seem to be a way to make a module page not have groups or categories -- @hideGroups only affects the navigation tree, not the page rendering. Is that intentional? Right now if you want your module contents to be flat you have to put everything in the same category or group, which then has the issue of either including a spurious heading in both the page and the nav tree, or needing the spurious page heading to be called "None". Gerrit0 commented on Apr 4, 2025 Yes, the navigation and module structure is completely separate as I simply hadn't considered if module pages should care about those tags. I'm leaning towards TypeDoc should use the same logic for both for consistency. Gerrit0 commented on Apr 6, 2025 Upon further reflection, I'm backtracking here a bit... Trying to make the navigation and page structure follow the same rules is nice at first, but runs into problems because they are truly different things. The navigation has customization options that it would be very weird to have the module page follow, and @showGroups / @hideGroups were truly meant only for the navigation, not to also affect the page contents.
in both the page and the nav tree
Only if you have turned on the navigation.includeGroups option, which is off by default.
I am going to introduce a @disableGroups tag which completely disables the grouping mechanism for a given parent, which will result in both the navigation and the page not including group sections. Including this in @hideGroups would be a breaking change, which I don't want to do as I don't want to start a beta branch so close to the 0.28 release. added a commit that references this issue on Apr 6, 2025This issue will close once commit e577bfc is merged into the 'master' branch.e577bfc pjeby commented on Apr 6, 2025 Hm. I just tried the dev branch, and @disableGroups works great, but @category none isn't working on reflections that are members of a class; should it? pjeby commented on Apr 6, 2025 Also, @disableGroups on a class whose members aren't categorized results in the members being listed twice on the on-page nav, as both top-level items and items under a "none" category:
Gerrit0 commented on Apr 7, 2025
@category none isn't working on reflections that are members of a class; should it?
This and the double navigation bug were both caused by forgetting a return facepalm pjeby commented on Apr 7, 2025 Hey, we've all been there. 😁 Anyway, it works great now!
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
