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

Typealiases should have their own separate pages #2862

Closed
IgnatBeresnev opened this issue Feb 15, 2023 · 7 comments · Fixed by #3051
Closed

Typealiases should have their own separate pages #2862

IgnatBeresnev opened this issue Feb 15, 2023 · 7 comments · Fixed by #3051
Assignees
Labels
enhancement An issue for a feature or an overall improvement feedback: Kotlin libs Feedback from Kotlin's internal libraries

Comments

@IgnatBeresnev
Copy link
Member

IgnatBeresnev commented Feb 15, 2023

At the moment, typealiases don't have their own pages and can only be found among the package's types, which is not always convenient and is difficult to link to.

Typealiases should have dedicated pages, with persistent index.html generated for them, similar to other declarations.

Things to consider/keep in mind:

  1. Previously generated anchor links should be preserved if possible (so compatibility with previous versions of Dokka, especially when linking to external documentation).
  2. If not already, the description of the typealias declaration on the package page should be changed to "brief", similar to other elements.
  3. The dedicated page for the typealias should display full documentation (all KDoc paragraphs, tags, etc).
  4. Check that the search and similar common features work (for instance, see Kotlin's typealias is not handled correctly #2311)
  5. Some internal refactoring may be needed as DTypeAlias is not handled the same way as DClasslike or any other documentable, so it needs to be checked/supported additionally.
@IgnatBeresnev IgnatBeresnev added enhancement An issue for a feature or an overall improvement feedback: Kotlin libs Feedback from Kotlin's internal libraries labels Feb 15, 2023
@IgnatBeresnev IgnatBeresnev added this to the Standard library API reference migration milestone Feb 15, 2023
@IgnatBeresnev IgnatBeresnev changed the title Typealiases should have their own separate page Typealiases should have their own separate pages Feb 15, 2023
@IgnatBeresnev
Copy link
Member Author

IgnatBeresnev commented Mar 8, 2023

Related: #2311, #1202

@IgnatBeresnev
Copy link
Member Author

IgnatBeresnev commented Mar 14, 2023

Can probably be closed after this is implemented: #1667

@ilya-g
Copy link
Member

ilya-g commented Apr 18, 2023

Related: #2971

@vmishenev
Copy link
Member

vmishenev commented Jun 24, 2023

This change requires some refactoring (documentable or/and page model) that should be discussed.
Currently, we have ClasslikePage (see Pages.kt) that can contain actual type alias.
Also, we have mergeImplicitExpectActualDeclarations so one page can have a classlike and a non-actual typealias with the same name.
Options:

  • Rename ClasslikePage to ClasslikeOrTypeAliasPage
  • Introduce an interface DType (DTypeAlias: DType, DClasslike: DType) and rename ClasslikePage to DType
  • Introduce TypeAliasPage (only if we have only typealiases, not classlikes) and use ClasslikePage if we have a classlike with the same name
    ...

@qwwdfsad
Copy link
Member

qwwdfsad commented Jun 24, 2023

I wonder why ClasslikePage does not imply it could refer to typealias though, it looks reasonable as it is right now

@vmishenev
Copy link
Member

I wonder why ClasslikePage does not imply it could refer to typealias though, it looks reasonable as it is right now

Yes, but in documentable mode we have independent DTypeAlias and DClasslike (that even has a scope).

@vmishenev vmishenev self-assigned this Jun 25, 2023
@vmishenev vmishenev linked a pull request Jun 26, 2023 that will close this issue
@vmishenev
Copy link
Member

This is implemented since Dokka 1.9.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An issue for a feature or an overall improvement feedback: Kotlin libs Feedback from Kotlin's internal libraries
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants