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

<input> value and other properties should accept more types #43

Open
justinfagnani opened this issue Apr 8, 2019 · 6 comments
Open

Comments

@justinfagnani
Copy link
Collaborator

Right now a binding like:

html`<input type="range" .value=${currentValue} .max=${max}>`;

Will report errors on the value and max bindings if currentValue and max are numbers. But an input handles this just fine. This may be something that needs to be updated in the typings, but maybe there's something to be done in the plugin?

@runem
Copy link
Owner

runem commented Apr 9, 2019

Thanks for your issue! This plugin uses properties and types from lib.dom.d.ts. Here are some of the properties on HTMLInputElement:

interface HTMLInputElement extends HTMLElement {

    ...

    value: string
    max: string;
    maxLength: number;
    min: string;
    minLength: number;

    ...
}

Typescript TSJSlib-generator seems to be generating these files based on IDL. For example max on HTMLInputElement is attribute DOMString max and maxLength is attribute long maxLength.

I'm already patching some of these types but I have problems finding an overview of properties accepting other types than described in the IDL. Do you know if there exists a clear overview, or if it's safe to assume that eg. all properties of type string also accepts number?

If not I plan on patching the type of each built in property manually when I get the time :-)

@justinfagnani
Copy link
Collaborator Author

This actually might be a good question to bring up to @DanielRosenwasser and the TypeScript team. Since so many DOM setters perform type coercion, and so accept any number of types, what should their real types be?

input.value = 5;

is perfectly fine JavaScript...

@DanielRosenwasser
Copy link

I think this ties back into having separate read types and write types, which I'm personally not opposed to if we can think it through. Putting together a short issue that we can track might be helpful if one doesn't already exist.

@justinfagnani
Copy link
Collaborator Author

@DanielRosenwasser did you ever put together a tracker issue for this?

@runem runem transferred this issue from runem/vscode-lit-plugin Aug 12, 2019
@justinfagnani
Copy link
Collaborator Author

I filed an upstream issue for this.

@graynorton
Copy link

Looks like the underlying TypeScript support is in place as of v4.3: microsoft/TypeScript#42425

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants