lib.dom.d.ts: HTMLInputElement::type should be more specific than just 'string'

[ArcticZeroo]

Search Terms

• HTMLInputElement type
• HTML input type
• input type
  • this one returned thousands of unrelated results, so admittedly I didn't go through them all

Suggestion

In lib.dom.d.ts, HTMLInputElement::type is currently specified as a string, but its value can only legally be one of a known set of strings (specified on MDN). I would like to change this property to be a union of string literals that expresses this set of strings.

Use Cases

Currently, code which assumes string is assignable to HTMLInputElement.type is operating on a bad assumption which is not actually safe. By restricting the allowed strings in this property, we get benefits including:

• The obvious benefit of strict typechecking so that developers don't have to worry about typos or other errors causing their input elements to revert back to type text
  • This also allows IDEs to fill in valid types for these developers.
• typeof HTMLInputElement.prototype.type (as HTMLInputElement outside of lib.dom.d.ts refers to the declared var rather than the interface) can be used as a way to express all valid types without needing to declare another type that may eventually become inconsistent or have some errors of its own (omissions, typos, etc)

Examples

const inputElement = document.createElement('input');
inputElement.type = 'cat'; // should be illegal
inputElement.type = 123456; // already illegal (not assignable to 'string')
inputElement.type = '123456'; // should be illegal
inputElement.type = 'text'; // should be legal

Checklist

My suggestion meets these guidelines:

• [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code-
  • This would be a breaking change in existing TypeScript code, because any code which assumes that an arbitrary string is assignable to typeof HTMLInputElement.prototype.type is not actually making safe assumptions. Despite this, I am submitting this issue as both a record of the fact that the shortcoming exists, and to gather feedback on whether this is an acceptable level of breaking to implement it.
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

I'm a little concerned about the breaking aspect of this given that this is probably rarely set by code in the first place. Open to more feedback though

[tjjfvi]

It only breaks assignments (because "button" | "color" | "checkbox" | ... is assignable to string), so if code doesn't ever really set it, then it wouldn't really be an impactful breaking change, right?

[ArcticZeroo]

I think it's pretty likely that most code dynamically creating input elements is setting type directly with a known literal, instead of passing it in somehow via string.

The use case of needing to manipulate an input's type in general seems pretty common to me -- along with needing the ability to set type when dynamically creating inputs, imagine something like a "show password" button which toggles between type="text" and type="password".

The main unknown here is how much code is actually trying to assign string without a known literal type, and I'd guess (without any data to back it up though) that this is a pretty uncommon use case in comparison to the known literal.

For reference, something like the following would be subject to the breaking change:

const createInput = (type: string) => {
    const inputElement = document.createElement('input);
    inputElement.type = type;
    // do some other setup for this element so it's not 2 lines 🤷‍♀️
    return inputElement;
};

[antsif-a]

Quite an old issue, but I also found that type: string already conflicts with React's JSX, as React already has specific declaration of type. For example, the following would not compile:

import React, { HTMLProps } from 'react';

function Button({ ...props }: HTMLProps<HTMLButtonElement>)  {
    return (
        <button { ...props } />
    );
};

Error: Type 'string' is not assignable to type '"button" | "submit" | "reset" | undefined'.