Misleading doc string generation in typescript components

[snehilvj]

Hi, I am migrating dash-mantine-components to typescript. However, I have been facing some issues with the doc strings generation. The doc strings are not very accurate, in fact, for some prop types, doc string generation just fails.

Example 1
Have a look at how the doc string is generated for the radius prop.

The radius property will accept both strings and numbers but the doc string is misleading.

Example 2
For somewhat complex prop types such as value here, the prop generation just fails with the below error.

Error:

> dash_mantine_components@0.11.0a0 build:backends
> dash-generate-components ./src/ts/components dash_mantine_components -p package-info.json --r-prefix '' --jl-prefix '' --ignore \.test\.


ERROR: "__@iterator@2374" matches reserved word pattern: /^_.*$/

ERROR: "__@unscopables@2376" matches reserved word pattern: /^_.*$/
extract-meta failed

Error generating metadata in dash_mantine_components (status=1)
error: Recipe `build` failed on line 5 with exit code 1

Thanks
Snehil

[T4rk1n]

Thanks for the report @snehilvj .

1. For values with enumeration, the implementation currently discard other types than the enumeration. Instead, when it encounter this case, it should transform the enum type into a union of the enum and the others types.
2. Adding tuple support in Fix typescript tuple type. #2257

[snehilvj]

Hi @T4rk1n Thanks for the fix on 2nd point above. Any thing going with the 1st point above? Btw loving the typescript experience so far. Migrated entire dmc to typescript in the latest 0.11.0a0 release.

[tsveti22]

Hi @T4rk1n
Currently experiencing the same issue with the dangerouslySetInnerHTML prop which includes an "__html" key. Interestingly, the component generation script runs successfully in windows, but we get this on Unix:

ERROR: "__html" matches reserved word pattern: /^_.*$/
extract-meta failed

The same thing happens with any prop that has __, e.g. __@iterator@1234. We're converting an internal typescript component library to Dash, and it's pretty frustrating, because we can't generate components on our unix system without doing a billion workarounds to exclude problematic props. Would really appreciate any help.

[T4rk1n]

@tsveti22
There might be an issue with the arguments not getting passed on windows so the reserved word patterns is not defined there and it generates the props with _.
There is no way to override the pattern with the included command, but you can generate the metadata.json with the command (node path/to/extract-meta.js):

dash/dash/extract-meta.js

Lines 29 to 30 in 993b57f

	'extract-meta ^fileIgnorePattern ^forbidden$|^props$|^patterns$' +
	' path/to/component(s) [path/to/more/component(s) ...] > metadata.json'

Then use the python generator:

dash/dash/development/component_generator.py

Lines 39 to 52 in 993b57f

	def generate_components(
	components_source,
	project_shortname,
	package_info_filename="package.json",
	ignore="^_",
	rprefix=None,
	rdepends="",
	rimports="",
	rsuggests="",
	jlprefix=None,
	metadata=None,
	keep_prop_order=None,
	max_props=None,
	):

With the metadata given the json.load("metadata.json").

The __@iterator@1234 bug is with a type could not be handled, even with allowing the _ it would generate something that is not good. The tuple case was fixed in #2257, if there is other cases that needs to be handled we would need examples for fixing.

Part 1 of this issue is still unfixed, that is when you have an enum type with mixed types it only generates one type.

[gvwilson]

@T4rk1n will your work on the code generator fix this as a side effect?

[T4rk1n]

@T4rk1n will your work on the code generator fix this as a side effect?

No the enum types is another bug.

[AnnMarieW]

For reference, here's a PR that may fix some issues here #3364