Add typing to component init.

[T4rk1n]

Add python typing to generated components __init__.

Contributor Checklist

• I have added tests, or extended existing tests, to cover any new features or bugs fixed in this PR
• I have added entry in the CHANGELOG.md

[alexcjohnson]

I wonder, now that we're Py3-only, maybe we should call black on the generated files as part of the generation process? We already do that in the core component packages as a separate step.

[tuchandra]

Hi - this is really, really cool. I would love to see this landed into Dash, and if I can help with reviewing this PR, debugging any tests, etc., please let me know. I was working on a separate effort to generate stub (.pyi) files, so I have tinkered around with this part of the codebase a little bit. I'm excited to see where this goes!

[eff-kay]

@alexcjohnson @T4rk1n just wondering if people can pass in Decimals in here as well?

[alexcjohnson]

If to_json_plotly can serialize it then yes. It's pretty flexible, so probably Decimal is fine, but I haven't tested it.

[T4rk1n]

Decimal can serialize, I think we can put numbers.Number to get all the number types.

[alexcjohnson]

numbers.Number is too much, it includes complex - how about numbers.Real?

[T4rk1n]

https://docs.python.org/3/library/numbers.html#the-numeric-tower

Number is the base class, then they extend the last one, to get the Integral you need all the other 3 implemented. Tested with numpy and Number is what get the most support and our to_json supports them, I dont think custom implementation of those works.

[eff-kay]

this should be a List[Any]. mypy will throw an error on this.

also, wondering if we should use the parent type Iterable.

[T4rk1n]

typing.List is same as typing.List[typing.Any], iterable might not json compatible, I think the List is the most safe for this typing.

[alexcjohnson]

There are certainly a number of other iterables people frequently use though - tuple, range, dict_keys, dict_values, etc etc... I wouldn't want to push people into casting everything to a list, that would be unnecessary overhead.

[T4rk1n]

range, dict_keys, dict_values,

Those already needs to be cast to list for json.

I guess we could do a union of Tuple and List.

[alexcjohnson]

Still open 😎

[T4rk1n]

We can add Tuple as union for untyped arrays, but arrayOf is really a different typing on both side.

[alexcjohnson]

Thanks for updating array. Not sure what you mean by "arrayOf is really a different typing on both side", but I think it's fairly important to accept tuples in arrayOf. I recall for example various database drivers returning query results as either nested tuples or tuples of dicts.

I wonder if it would be worth defining up front a couple of extra types we can reuse later, like:

JsonNumber = typing.Union[int, float, numbers.Real]  # or whatever we end up with for numbers
JsonArray = typing.Union[typing.List, typing.Tuple]
ReactNode = typing.Union[
    typing.Union[str, JsonNumber, Component],  # note more numbers here!
    JsonArray[typing.Union[str, JsonNumber, Component]]
]

If we did something like that, would we be able to change:

optionalArrayOf: typing.List[typing.Union[int, float, numbers.Number]] = Component.UNDEFINED

into this?

optionalArrayOf: JsonArray[JsonNumber] = Component.UNDEFINED

[T4rk1n]

It's better to go without defining type aliases that would require to be imported and would break backward compatibility for component libraries that compiled with the new typing but the user has dash locked to a previous version.

[T4rk1n]

I went with pyright instead of mypy for the static checker because it has better package/module resolution and default argument gets automatically added as an union type.

The checker and my IDE don't recognize the type of Component and as such put it as Any which breaks the checking for those types.

[alexcjohnson]

Huh, never noticed this before... do we actually support Element as distinct from Node?

[T4rk1n]

Yes, it ends up rendering the same as node but for typing it allows only a single component to be put and not a list of string/number/components.

[alexcjohnson]

Are there any examples of this in existing components? Does it work, either as children or with components-as-props?

[T4rk1n]

Before component as props, it was kind of invalid prop as only the children would be hydrated and children would be treated as a node, component as props also doesn't differ those Element from node.

The collect_nodes make both node and element into component:

dash/dash/development/_collect_nodes.py

Lines 1 to 2 in 453834b

	def is_node(value):
	return value in ("node", "element")

I think the only other place we have Element defined is in the typescript props:

dash/@plotly/dash-generator-test-component-typescript/src/props.ts

Line 31 in 453834b

element?: JSX.Element;

But the prop itself was not tested as it was before component as props was supported.

[alexcjohnson]

Suggested change

	typing_extensions>=4.4.0;python_version>"3.6"
	typing_extensions>=4.4.0;python_version>="3.7"

Just to be more obviously symmetric with the <"3.7"

I wonder though, if 4.1.1 is sufficient would we be better off just collapsing these into one line? If someone on 3.7+ has a version >=4.1.1,<4.4.0 pinned for some reason is that a problem?

typing_extensions>=4.1.1

[T4rk1n]

4.1.1 has fix for imports on 3.7, it's the last version that works with 3.6. I don't see anything we actually uses in the later version so we can try a single version >=4.1.1

[alexcjohnson]

Not a big deal, but in principle we can avoid noqa: F401 if we look at class_string and drop any imports we don't need.

[T4rk1n]

The docstring on the components are not in the right position for IDE support, the docstring for the props should be under the __init__ for them to appear on the tooltip when hovering/typing a component prop. The type in the docstring can now be removed as it is duplicate.

[T4rk1n]

There is a typing error with plotly Figure objects on dcc.Graph.figure prop expecting a dict, need to find a way to add it to possible types for that prop.

[alexcjohnson]

do we need stringcase in requires-install? Couldn't it go in requires-dev?

[T4rk1n]

It's needed for the old runtime component loader 😞

[alexcjohnson]

haha ok - we should put a deprecation warning on runtime component generation, and remove it whenever we decide to do a Dash 3.0