Type annotations for common element props

[numpde]

I'd like to propose a class to facilitate a little bit the writing of component props, especially for those coming from ReactJS or HTML/JS. It should be basically a dict but with the benefit of code completion. Something like this:

# https://beta.reactjs.org/reference/react-dom/components/common#common
@dataclasses.dataclass
class Props(dict):
    NULL = object()  # analogous to JS 'null'
    UNDEFINED = None  # analogous to JS 'undefined'
    MISSING = object()  # means "not present at all"
    EMPTY = object()  # no value given (as in <button disabled />), but this is probably redundant

    # Special React props
    children: list = MISSING  # children -- ?
    dangerously_set_inner_html: dict = MISSING  # dangerouslySetInnerHTML
    ref: Any = MISSING  # ref
    suppress_content_editable_warning: bool = MISSING  # suppressContentEditableWarning
    suppress_hydration_warning: bool = MISSING  # suppressHydrationWarning
    style: dict = MISSING  # style

    # Standard DOM props
    access_key: str = MISSING  # accessKey
    aria: dict = MISSING  # aria-* (expanded)
    aria_: str = MISSING  # aria-* (any aria- attribute)
    auto_capitalize: str = MISSING  # autoCapitalize
    class_name: str = MISSING  # className
    content_editable: bool = MISSING  # contentEditable
    # etc.

Note, this would also simplify conditional prop supply. Maybe it could specialize to input and such using Props[html.input]. The children prop is debatable.

Furthermore (but this is not specific to this suggestion/class), 'data' and 'aria' props could optionally be dictionaries somewhat similar to 'style', and 'className' could accept a list, e.g.,

Props(
    data={'bs': {'toggle': "collapse"}},
    class_name=["btn", "btn-primary"],
)

would become

{data_bs_toggle="collapse", class_name="btn btn-primary"}

before being processed further.

With the pre-1.0.0 syntax, it'd work as follows:

html.div(
    Props(
        class_name="container",
    ),
    ...  # children
)

and with the 1.0.0a3 syntax:

html.div(
    ...  # children,
    **Props(
        class_name="container",
    )
)

[rmorshea]

'data' and 'aria' props could optionally be dictionaries

I'm not 100% sure we should do it just because it breaks from what React does, but I quite like this idea.

[Archmonger]

Can we accomplish autocomplete with a TypedDict type hint?

[rmorshea]

@dataclasses.dataclass
class Props(dict):

Instead of using dataclasses, we'd probably use a TypedDict instead. But yes, I think this something @Archmonger was talking about doing.

[Archmonger]

The amount of LOCs in there is a bit overkill.

I'd rather go line-by-line on CSS properties and manually add types to them than reverse engineer a java CSS validator.

For now, I think the generic types are alright.

[Archmonger]

https://gist.github.com/Archmonger/8d01d2efba1071f4950549004719eb19

Updated the script to parse the HTML5 attribute spec with type heuristics.

{'a': {'download': <class 'str'>,
       'href': <class 'str'>,
       'hreflang': <class 'str'>,
       'ping': <class 'str'>,
       'referrerpolicy': <class 'str'>,
       'rel': <class 'str'>,
       'target': <class 'str'>,
       'type': <class 'str'>},
 'abbr': {'title': <class 'str'>},
 'button': {'disabled': <class 'bool'>,
            'form': str | int,
            'formaction': <class 'str'>,
            'formenctype': <class 'str'>,
            'formmethod': <class 'str'>,
            'formnovalidate': <class 'bool'>,
            'formtarget': <class 'str'>,
            'name': <class 'str'>,
            'popoverhidetarget': str | int,
            'popovershowtarget': str | int,
            'popovertoggletarget': str | int,
            'type': <class 'str'>,
            'value': <class 'str'>},
  ...
}

[rmorshea]

This will be a bit tricky. There are attributes like autocomplete that, in React, are written as autoComplete instead. Also, all - separated style attributes should be _ instead.

[Archmonger]

I think we can avoid those clashes during merging the two dicts. When we merge, we should ensure that key.strip("_") doesn't exist as a key in either dict.

Or we can manually exclude known clashes.

[rmorshea]

To clarify, when I say autocomplete is written as autoComplete in React, that means that on the Python side, we'll want users to declare it as auto_complete (in order for our camelCase conversion to work). This isn't really about conflicts so much as it is about finding all cases where we need to add a _ delimiter to HTML attributes.