[browser] Implement deeper JSImport marshaling metadata

[pavelsavara]

Ability to marshal complex types is currently limited to 1 nested generic parameter type.
We could have JSObject[] parameter but not Action<JSObject[]>.

Simply said, we are not ready for the item in the collection to be another collection or wrapper.

This is because we could only handle 1 level of type parametrization.
And that's because

• the structure in which we pass metadata for the initialization of marshaller is linear to number of parameters.
• because we need to generate the marshaller callback to instantiate and convert the inner data types of generic types. Like items in the collection.

We could improve it by
A) increasing depth of parametrization to 2 or 3 with still linear metadata buffer
B) implement dynamic data structure.

Both should have no impact on the public API types. It would only extend what is now rejected by the code analyzer as not supported.

I think it would address #78455

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Ability to marshal complex types is currently limited to 1 nested generic parameter type.
We could have JSObject[] parameter but not Action<JSObject[]>.

Simply said, we are not ready for the item in the collection to be another collection or wrapper.

This is because we could only handle 1 level of type parametrization.
And that's because

• the structure in which we pass metadata for the initialization of marshaller is linear to number of parameters.
• because we need to generate the marshaller callback to instantiate and convert the inner data types of generic types. Like items in the collection.

We could improve it by
A) increasing depth of parametrization to 2 or 3 with still linear metadata buffer
B) implement dynamic data structure.

Both should have no impact on the public API types. It would only extend what is now rejected by the code analyzer as not supported.

I think it would address #78455

Author:	pavelsavara
Assignees:	pavelsavara, maraf
Labels:	arch-wasm, area-System.Runtime.InteropServices.JavaScript
Milestone:	Future

[elringus]

I've noticed that passing an array as object under Task<> with JSMarshalAs<JSType.Promise<JSType.Any>> actually works: on the JS side the resolved promise returns valid JS array, eg:

[JSExport] [return: JSMarshalAs<JSType.Promise<JSType.Any>>]
private static async Task<object> GetArrayAsync ()
{
    await Task.Delay(1);
    return new[] { "foo", "bar", "baz" };
}

Is this something we can rely on or it may break in future releases?

[pavelsavara]

The marshaling of System.Object is "best effort" trying to map the type to closest type on the other side, dynamically at runtime.
In this particular case the mapping could be recognized on both sides and obvious data types exist.
So I guess it's unlikely to break for this specific combination.

If the collection contained something which we today marshal as untyped proxy and in the future we would have better (more specific) mapping, the "best effort" would be different behavior than it is today.