Integer field type inconsistency

[ri0ter]

Prerequisites

• I have read the documentation;
• In the case of a bug report, I understand that providing a SSCCE example is tremendously useful to the maintainers.

Description

Fields across different themes are inconsistent. For schema { "type": "integer"} the form is displaying the field as input[type="number"] input in both core and antD themes, but in all other themes it has input[type="integer"] (on the DOM level) - which is not valid type. According to the widgets documentation:

By default, a regular input[type=text] element is used.
Which implies that both default and antD themes are wrong in it's behavior.

Expected behavior

Fields should behave like described in documentation

Version

v2.4.2

Maybe for now it would be enough to fix all the fields which use invalid type and then restore the consistency with a major release?
Also, wouldn't it be easier to maintain the code if the logic for displaying field would be more explicit/strict, so that StringField wouldn't be responsible for displaying number/integer by default?

@epicfaace I can handle that issue, what do you think about the solution?

[epicfaace]

Ah, I see. Yes, I think your solution works, to fix invalid types for now.

If you'd like, you could make another PR that restores the consistency (and label it breaking-change) so we only add it in 3.x. I wonder if the more natural change for consistency would actually be to change the default behavior (and document this behavior) so that it uses input[type="number"] for all themes. What do you think?

Also, wouldn't it be easier to maintain the code if the logic for displaying field would be more explicit/strict, so that StringField wouldn't be responsible for displaying number/integer by default?

Perhaps, I'm interested in hearing what you think about your thoughts here -- how do you think this could be accomplished?

[epicfaace]

Related PR: #2222

[newt10]

Ah, I see. Yes, I think your solution works, to fix invalid types for now.

If you'd like, you could make another PR that restores the consistency (and label it breaking-change) so we only add it in 3.x. I wonder if the more natural change for consistency would actually be to change the default behavior (and document this behavior) so that it uses input[type="number"] for all themes. What do you think?

Also, wouldn't it be easier to maintain the code if the logic for displaying field would be more explicit/strict, so that StringField wouldn't be responsible for displaying number/integer by default?

Perhaps, I'm interested in hearing what you think about your thoughts here -- how do you think this could be accomplished?

It seems to me that from a consistency perspective, it would make more sense to keep the default behavior, update documentation and other themes.

[heath-freenome]

Fixed in the v5 beta, see the 5.x migration guide