Skip to content

fix(typedoc): Fix merge properties from base classes and remove obsolete base class name rosolving.#175

Open
skrustev wants to merge 2 commits into
masterfrom
skrastev/fix-base-props
Open

fix(typedoc): Fix merge properties from base classes and remove obsolete base class name rosolving.#175
skrustev wants to merge 2 commits into
masterfrom
skrastev/fix-base-props

Conversation

@skrustev

Copy link
Copy Markdown
Member

Closes https://github.com/IgniteUI/api-docs/issues/140

Additional information (check all that apply):

  • Bug fix
  • New functionality
  • Documentation
  • Demos
  • CI/CD

Checklist:

  • All relevant tags have been applied to this PR
  • This PR includes general feature table updates in the root README.MD
  • This PR includes CHANGELOG.MD updates for newly added functionality
  • This PR contains breaking changes
  • This PR includes behavioral changes and the feature specification has been updated with them

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

This PR updates the custom TypeDoc plugin logic used to surface component/base-class members in the generated React component API docs, addressing incorrect/obsolete base type handling (per api-docs issue #140).

Changes:

  • Expands the set of excluded base types and adds an excluded-property list.
  • Refactors base-type property traversal to handle intersections/merged base types via resolveBaseTypeProps.
  • Removes the older extractBaseType logic that previously populated extendedTypes.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +186 to +189
if (
type.symbol?.name.includes('EventEmitterInterface') ||
excludeBaseTypes.includes(type.symbol?.name)
) {
Comment on lines +244 to +246
if (!type.baseTypesResolved || type.resolvedBaseTypes?.length === 0) {
return;
}
case SymbolFlags.Property:
category = 'Properties';
}
if (value.flags.toString() === '16777220') {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Um yeah, 16777220 is still optional because 16777220 & 16777216 = 16777216, a.k.a how you check flags usually is:

Suggested change
if (value.flags.toString() === '16777220') {
if (value.flags & ts.SymbolFlags.Optional) {

The type checker sometime have some higher level API for such checks, but not all.

PS: 16777220 is pretty much 16777216 with additional flag flipped in the ^2 position.
My fave snippet for flags: Object.keys(ts.SymbolFlags).filter(x => !x.endsWith('Excludes') && ts.SymbolFlags[x] & <value>) (obv good for NodeFlags, TypeFlags, etc) which for 16777220 returns:

['Property', 'Optional', 'All', 'Value', 'PropertyOrAccessor', 'ClassMember']

a.k.a pretty much optional member - what you're looking :)

'FormRequiredInterface',
'FormAssociatedCheckboxElementInterface',
'FormAssociatedElementInterface',
'MaskBehaviorElementInterface',

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

And this list might need an update since the mixins deff have changed.
Would be better if we can just access the ts.Type with all resolved properties directly and just have LitElement / HTMLElement as filter/cut-off point down the chain.

Although, even that is not entirely true, since we do actually re-use some of the native props (think input name, focus/validity methods - not necessary re-declaring them). Not sure how many, but might want to figure out a way to highlight important ones if needed.

@@ -179,55 +183,80 @@ export function load(app: Application) {
}

function parseTypeProperties(type: any, context: Context) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

type: any is no fun :)
Okay, so we do have types / possibly type checked access (at least some form of compile time running). Good to know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants