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

Adjust typings in headings options #15833

Merged
merged 10 commits into from Feb 19, 2024
Merged

Adjust typings in headings options #15833

merged 10 commits into from Feb 19, 2024

Conversation

Mati365
Copy link
Member

@Mati365 Mati365 commented Feb 12, 2024

Suggested merge commit message (convention)

Feat (heading): Adjust typings in headings options. Closes #15790.

@Mati365 Mati365 marked this pull request as ready for review February 12, 2024 11:16
/**
* Custom name of the model specified by the user.
*
* @internal
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it internal if it's used in non-internal type (line 98)?

Copy link
Member Author

@Mati365 Mati365 Feb 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@arkflpc It should be exported and public available, but we have issue with documentation generation. Umberto incorrectly serializes union in template string literal and in API reference we have something like this:

obraz

I tried to split it between types or use it inline directly in HeadingCustomModel but it always results in [object Set] in docs.

Copy link
Contributor

@DawidKossowski DawidKossowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should change this solution a bit. Adding the new type (HeadingCustomModelSeparator) seems redundant, and it makes our API docs look confusing:
Zrzut ekranu 2024-02-19 o 09 18 08

Here's my idea: let's create a separate interface for the custom element. We could call it HeadingCustomElementOption or HeadingCustomOption, and it would basically be a copy of HeadingElementOption, but with the model property changed to heading${ string }. You can also try to prepare a basic type and extend it, but I am not sure if it will be correctly compiled by Umberto.

@Mati365
Copy link
Member Author

Mati365 commented Feb 19, 2024

@DawidKossowski Have you tested this solution? I'm quite sure that it'll lead to collapse of heading union.

@Mati365
Copy link
Member Author

Mati365 commented Feb 19, 2024

@DawidKossowski I pushed modifications.

@DawidKossowski DawidKossowski merged commit 83fc67f into master Feb 19, 2024
6 checks passed
@DawidKossowski DawidKossowski deleted the ck/15790 branch February 19, 2024 13:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Types issues in headings
3 participants