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

Destructured object default values are not being recognized. #2430

Closed
PedroCuadra opened this issue Oct 28, 2023 · 1 comment
Closed

Destructured object default values are not being recognized. #2430

PedroCuadra opened this issue Oct 28, 2023 · 1 comment
Labels
bug Functionality does not match expectation help wanted Contributions are especially encouraged

Comments

@PedroCuadra
Copy link

Search Terms

JSDoc, destrucutred object, function

Expected Behavior

Hello guys. I'm using the Typedoc API to generate a custom library documentation website. Apparently default values of destructured object parameters are not being recognized by Typedoc. Here is a brief of the component i'm extracting:

/**
 * Checkbox, casilla de valor binario
 * 
 * @category Components
 *
 * @param { object } props 
 * @param { any } props.value Valor del Checkbox. 
 * @param { any } [props.trueValue = true] Valor cuando la casilla está activa.
 * @param { any } [props.falseValue = false] Valor customizado cuando la casilla está desactivada.
 */
const Checkbox = ({
  value,
  trueValue = true,
  falseValue = false,
  ...
}) => {...}

This is the only SignatureReflection for a Checkbox component, where the defaultValue should be the pointed either in JSDoc or in the destructured object.

image

Actual Behavior

None of JSDoc or in the destructured object is giving a default value, setting DeclarationReflection.defaultValue as undefined.

Steps to reproduce the bug

The bug is produced documenting in JSDoc and giving default values to destructured objects as parameters of a function.

Environment

  • Typedoc version: 0.25.1
  • TypeScript version: 5.2.2 (Even though, i'm documenting with just JSDoc
  • Node.js version: 20.5.1
  • OS: Windows 11

Extra

Would be nice if i could solve it myself and do a pull request but i'm not sure where to dig in.

@PedroCuadra PedroCuadra added the bug Functionality does not match expectation label Oct 28, 2023
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Oct 28, 2023

I don't think this is fixable without reaching into internal TS properties. Destructured objects are horrible to work with in the API, they're a close second to mixins in my opinion of the worst code to try to generate docs for...

I always investigate these types of things with ts-ast-viewer -- https://ts-ast-viewer.com/#code/KYDwDg9gTgLgBAYwgOwM7wMIAtgINYBGEIcAvHABQDecAbgIYA2ArsADRwxSsBqTrZTt3ZwAZk1TA+LYIPGNJcAL4BKMgD44VJQG4AUEA

If you click on ObjectBindingPattern, you'll get a type object, which is what TS is converting from, drilling down into the properties (turn on show internals), you can see that the symbols there do not have any declarations. To get the declarations, we'd have to use the internal links property and check the bindingElement property on that.

(This is looking at it with source language set to TS, if you paste the original code in and set the language to JS, there's a similar story, but we do have a declaration... it's just pointing at the @param, which doesn't have a .initializer, so we don't get any default value there either.)

If you want to investigate this, I'd recommend setting up a TS project with only that function, and starting typedoc in a debugger, I recommend breakpoints in convertProperty in src/lib/converter/symbols.ts and for the conversion functions of the typeLiteralConverter in src/lib/converter/types.ts

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 help wanted Contributions are especially encouraged
Projects
None yet
Development

No branches or pull requests

2 participants