[JavaScript][Input.Number] [Type of value has changed with latest update]

[aroraketan]

Platform

What platform is your issue or question related to? (Delete other platforms).

• JavaScript

Author or host

Host: Microsoft Teams (multi-window).

Version of SDK

JS v2.5.0.

Details

The value prop of Input.Number has changed from string type in v1.2.5 to number | undefined type in v2.x.
This can potentially break existing host scenarios.

[ghost]

please review this issue for target Milestone, Inconsistencies & Priority upon triage.

[shalinijoshi19]

@dclaux isn't this related to the Input.Number string vs int discussions we'd been having as part of #3287 earlier this year.. I know we were going to modify the code to accept both number and string types for backwards compatibility. Is that something that is potentially addressed with #5093 ?

[ghost]

Hi @aroraketan. We have acknowledged this issue report. Please continue to follow this issue for updates/progress/questions.

[dclaux]

@aroraketan @shalinijoshi19 this is by design. The behavior was changed because the JS SDK's behavior didn't match that of the other SDKs.

[shalinijoshi19]

@paulcam206 to pick this up to address the breaking change aspect of the original change for JS.

[paulcam206]

also need to update schema and enumerate proximal changes

[dclaux]

@shalinijoshi19 what is there to address?

[shalinijoshi19]

Referencing #3829 which was the issue filed by the BotFramework team around the same issue. @paulcam206 / @dclaux FYI.

[shalinijoshi19]

@aroraketan Input.Number is expected to be a number type per our schema.

• Infact we had inadvertently broken the 1.2.x series at some point to switch from accepting Input.Number as number only in 1.2.0 to string starting likely with 1.2.3, causing a botframework scenario break as reported in Should Input.Number value accept a string? #3287 and leading to an inconsistency in the JS renderer;
• We've since addressed that discrepancy in the JS renderer and the 2.x series now matches our schema and other renderers around Input.Number handling.

@dclaux pls correct me if i am wrong here
@paulcam206 FYI; Doesnt appear we have anything to do here.

[shalinijoshi19]

@sowrabh-msft FYI..

[shalinijoshi19]

@aroraketan Input.Number is expected to be a number type per our schema.

• Infact we had inadvertently broken the 1.2.x series at some point to switch from accepting Input.Number as number only in 1.2.0 to string starting likely with 1.2.3, causing a botframework scenario break as reported in Should Input.Number value accept a string? #3287 and leading to an inconsistency in the JS renderer;
• We've since addressed that discrepancy in the JS renderer and the 2.x series now matches our schema and other renderers around Input.Number handling.

@dclaux pls correct me if i am wrong here
@paulcam206 FYI; Doesnt appear we have anything to do here.

@aroraketan / @sowrabh-msft updates on this one:
So per our offline conversation on this one, it turned out not about the actual Input.Number schema but the transformed callback data type that is passed in to the host Submit.Action callbacks in case of Input.Number here and the type of that object that was divergent and inconsistent with other platforms on JS.
This inconsistency has now been reverted and JS back to passing the Input.Number as a string to the Action.Submit callback in the host.
Meanwhile longer term we realize it's an awkward roundtripping story and we are tracking addressing that experience with #5135 .

[ghost]

🎉AdaptiveCards@2020.12 has been released which fixes this issue.:tada:

Handy links:

• Release Notes
• AdaptiveCards Website
• Official NPM Designer Release
• Official NPM Templating Release
• Official NPM Renderer Release
• Official Nuget Templating Release
• Official Nuget Renderer Release
• Official Maven Renderer Release
• Official CocoaPod Renderer Release