[patch] move cell value type to a new attribute "cellValueType" in custom function metadata

[xai-msft]

Cell value types have been introduced to custom function input parameter type. We decided to move it to a new attribute "cellValueType" for backward compatibility, so that older client won't break on unknown types.
"cellValueType" works as follows:
When "type" is one of "boolean"/"number"/"string", "cellValueType" won't be parsed by Excel. When "type" is "any" and "cellValueType" is a valid cell value type, the cell value type will be used as custom function parameter type. If "cellValueType" is invalid, Excel will use the fallback "type" "any".

Sample function metadata before change:

{
"description": "Test Excel.CellValue parameter",
"id": "TESTCELLVALUEPARAM",
"name": "TESTCELLVALUEPARAM",
"parameters": [
{
"name": "x",
"type": "cellvalue"
}
],
"result": {}
}

after change:

{
"description": "Test Excel.CellValue parameter",
"id": "TESTCELLVALUEPARAM",
"name": "TESTCELLVALUEPARAM",
"parameters": [
{
"name": "x",
"type": "any"
"cellValueType": "cellvalue"
}
],
"result": {}
}

1. Do these changes impact command syntax of any of the packages? (e.g., add/remove command, add/remove a command parameter, or update required parameters)
   No

2. Do these changes impact documentation? (e.g., a tutorial on https://learn.microsoft.com/office/dev/add-ins/overview/office-add-ins)
   Cell value types are not public yet.

Validation/testing performed:
Updated and ran tests.

[akrantz]

The change is simple but I'd like to discuss more about the naming here. I feel like there should be more examples / test cases. This is not really about the change here is what metadata is generated, but really is more about the native code which is parsing and handling the metadata. I wish I had known about this discussion earlier.

[AlexJerabek]

Corollary to this: aren't there doc changes that'll need to happen? Have those been requested from the content team?

[xai-msft]

Hi @akrantz , I have updated the change according to our discussions. Could you please help merge this as I don't have permission? Thank you!

[akrantz]

Looks good!

[millerds]

/azurepipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[millerds]

@xai-msft . . . Alex's question still needs to be addressed.

[AlexJerabek]

@millerds @xai-msft @akrantz
The PR description says these changes aren't public yet. Do we have an idea when they will be? Is there a preview phase? As long as this PR is separate from the feature request, we can loop in @alison-mk separately to document the new cellValueType and behavioral changes to type.

[millerds]

@millerds @xai-msft @akrantz The PR description says these changes aren't public yet. Do we have an idea when they will be? Is there a preview phase? As long as this PR is separate from the feature request, we can loop in @alison-mk separately to document the new cellValueType and behavioral changes to type.

This repo does not have separate internal or preview releases branches (we haven't needed one yet). Once this gets checked in it will be part of the next publish of the packages (which is not on a set time schedule) . . . making it at least preview even if the full support of it is not official yet.

[AlexJerabek]

Thanks @millerds! Then I'd like to wait to check this in until we have a minimum set of documentation ready to go in concurrently. We have a legal requirement to document any public API surface area, so we'll at least need some mention of the new attribute.

@xai-msft and @alison-mk can get that staged in the https://github.com/OfficeDev/office-js-docs-pr repo.

[alison-mk]

Thanks, all! I'll reach out to @xai-msft internally to coordinate the docs updates. I started a draft PR here: OfficeDev/office-js-docs-pr#4632. Agreed that we should align the docs update with the feature release if possible.

[xai-msft]

Thanks @millerds for the reminder and thank you all for the discussions. I'll work with Alison on documentations and update here when it's ready.

[akrantz]

Should formattednumbercellvalue map to number?

[xai-msft]

I think that makes sense.

[akrantz]

Made a suggestion about formattednumbercellvalue mapping but looks good to me otherwise. I've actually happen to see this updated to cellValueType and appreciate being receptive to previous feedback that I have given.

[akrantz]

@AlexJerabek We should go ahead with this change before documentation has been updated. It won't have any impact on what a user would do. This is just to make improvements so Excel know more about the cell value types so it can coerce types to the desired cell value type.

[MiaofeiWang]

It seems merging this PR still needs repo admin's help. Would you please help run the status check, @akrantz @millerds ? Thank you.