Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inheritance between "groups" and "categories" works different than I'd expect #2746

Open
hybridherbst opened this issue Oct 14, 2024 · 1 comment
Labels
bug Functionality does not match expectation no bug This is expected behavior

Comments

@hybridherbst
Copy link

hybridherbst commented Oct 14, 2024

Search terms

categories, groups, options

Expected Behavior

I'm trying to structure code with both groups and categories.
However, it's not clear to me what has precedence when and when each of those is ignored.

What I would like to achieve is a sorting where "Groups" come first - e.g. "Components" – and then, inside that, the categories.

To me it looks like it might be an issue with inheritance – it looks like when both category and group are specified, then I get the ordering that I expect; but when group is specified on a parent class, that is only inherited by classes that do not specify a category.

In other words: I would expect that in "Case E", "Category A" and "Category B" are nested under "Components", not under "Classes".

(Side note: the docs mention that "categorizeByGroup" is true by default, but it seems actually it's false by default)

Code:

export function add(a, b) {}

/**
 * @group Components
 */
export function sum(a, b) {}

/**
 * @group Components
 */
export class MyClass {}

export class MyClass2 extends MyClass {}

/**
 * @category CategoryA
 */
export class MyClass3 extends MyClass {}

/**
 * @category CategoryB
 */
export class MyClass4 extends MyClass {}

Results by config:

CaseConfigResult
A

  "navigation": {
    "includeFolders": false,
    "includeCategories": false,
    "includeGroups": true
  },
  "categorizeByGroup": false
image
B

  "navigation": {
    "includeFolders": false,
    "includeCategories": true,
    "includeGroups": true
  },
  "categorizeByGroup": false
image
C

  "navigation": {
    "includeFolders": false,
    "includeCategories": true,
    "includeGroups": false
  },
  "categorizeByGroup": false
image
D

  "navigation": {
    "includeFolders": false,
    "includeCategories": false,
    "includeGroups": true
  },
  "categorizeByGroup": true
image
E

  "navigation": {
    "includeFolders": false,
    "includeCategories": true,
    "includeGroups": true
  },
  "categorizeByGroup": true
image
F

  "navigation": {
    "includeFolders": false,
    "includeCategories": true,
    "includeGroups": false
  },
  "categorizeByGroup": true
image

Actual Behavior

This structure loses the group on MyClass3, MyClass2 properly has the group:

/**
 * @group Components
 */
export class MyClass {}

export class MyClass2 extends MyClass {}

/**
 * @category CategoryA
 */
export class MyClass3 extends MyClass {}

This structure properly nests MyClass in Component > Category, which is inherited by MyClass2, but then MyClass3 loses the group that it should inherit:

/**
 * @group Components
 * @category CategoryC
 */
export class MyClass {}

export class MyClass2 extends MyClass {}

/**
 * @category CategoryA
 */
export class MyClass3 extends MyClass {}

Steps to reproduce the bug

Full repro:
https://stackblitz.com/edit/vitejs-vite-yz5hhi?
Adjust settings in typedoc.json and src/index.ts as needed.

@hybridherbst hybridherbst added the bug Functionality does not match expectation label Oct 14, 2024
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Oct 16, 2024

This is working as designed.

Grouping/categorization is applied for a given reflection by looking for the @category and @group tags within that reflection's comments, but MyClass3 in your example has provided a custom comment, which means that it does not inherit the parent class's comment. As MyClass3 then does not include a @group tag, it is placed in the default group for it's kind - Class

Groups/categories could be given their own custom inheritance logic which works the way you describe, but I think that would be overall more confusing to most users as it introduces another possible way that comment inheritance is handled. The current rule of following regular comment inheritance is straightforward.

@Gerrit0 Gerrit0 added the no bug This is expected behavior label Oct 16, 2024
Gerrit0 added a commit to TypeStrong/typedoc-site that referenced this issue Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Functionality does not match expectation no bug This is expected behavior
Projects
None yet
Development

No branches or pull requests

2 participants