Blazor WASM unmarshalled interop with JSImport

[Hooterr]

Hi all,
I need to use JS interop without JSON overhead (too slow, too much data).
I was following examples in the docs that use IJSUnmarshalledRuntime, but is deprecated now. and the docs say I should use JSImportAttribute. Ok fair enough but I can't find the same example for JSImport as there was for the deprectaed interface. Namely a managed object in .NET (struct) passed to JS via a pointer and then read with Blazor.platform.readStringField using offsets.

Here is what I have

[JSImport("globalThis.test2")]
public static partial void Test2([JSMarshalAs<JSType.Any>] object param);
...
JsUnmarshalled.Test2(new InteropStruct()
{
    Name = "Brigadier Alistair Gordon Lethbridge-Stewart",
    Year = 1968,
});

JS

function test2(flights){
    console.log(flights);
    const name = Blazor.platform.readStringField(flights, 0);
    const year = Blazor.platform.readInt32Field(flights, 8);
    console.log(`${name} (${year})`)
}

But I'm getting null when reading name value. Looks like readStringField expects a pointer as a number but instead generated interop code passes ManagedObject Symbol(wasm js_owned_gc_handle): 118 into test2 function.
Not sure how to get an actual heap pointer from that in JS.

I tried another way

[JSImport("globalThis.test2")]
public static partial void Test([JSMarshalAs<JSType.Number>] int param);

and call it like this:

var a = new InteropStruct()
{
    Name = "Brigadier Alistair Gordon Lethbridge-Stewart",
    Year = 1968,
};
IntPtr tr = (int)&a;

JsUnmarshalled.Test(tr.ToInt32());

That worked. But I'm pretty sure that's not how it's supposed to be used. On the other hand the function I wan to call is supposed to decode fields from my managed .net object, copy then, and create JS objects to be used in JS. The function would be synchronous. If I'm not mistaken I don't really need to worry about GC moving my object somewhere else since GC can only do that after my JS function completes.

I know that's a niche usecase but maybe someone has some ideas on how to do this correctly?

The struct for completness

[StructLayout(LayoutKind.Explicit)]
public struct InteropStruct
{
    [FieldOffset(0)]
    public string Name;

    [FieldOffset(8)]
    public int Year;
}

[maraf]

cc @pavelsavara

[pavelsavara]

At the moment we don't support marshaling structures with [JSImport].

The [JSMarshalAs<JSType.Any>] will marshal it as a proxy JS objects, just a wrapper around GCHandle.
That's why Blazor's deprecated unsafe pointer based platform.readStringField would not work on it.
We deprecated this because it was really unsafe, because GC could move the managed objects in memory.

You said that you have lot of data.
Possible solutions how you can transfer it:

1. marshal each member of the structure as different parameter of JSImport method. Like void Method(string name, int year)
2. if you have array of InteropStruct[] you can transform it into multiple arrays of simple types. And then marshal it as void Method(string[] names, int[] years). This is what we do in the HTTP client implementation, when we pass HTTP headers to JS.
3. you can use JSON serializer yourself and marshal string. This could be slower. This is what Blazor does.
4. convert it to byte[] and pass that. In your case, the field Name makes it difficult because of the dynamic size.
5. pin it in memory and pass IntPtr. This is tricky, because you will need to pin the string too and deal with the details.

Hope this helps.

[Hooterr]

It's a geojson with a lot of data mostly strings and numbers. Serializing it to either JSON or binary is too slow anyway.

I went with option 1&2. It's still miles faster than normal interop which is great.

Thanks for the response!

[legistek]

We deprecated this because it was really unsafe,

Except this unsafe interop is exactly what you use for RenderTreeFrame's is it not? Y'all aren't the only ones who know how to pointer arithmetic. ;)

I was extensively using the low level interop - in both directions - in order to achieve performance that was not possible with normal Blazor. I understood these were "internal" APIs, but I expected they might change - not be eliminated. Despite the Mono WASM SDK ostensibly still supporting this, as far as I can tell you obfuscated away any ability for us to use these. For example BINDING and MONO appear to be totally inaccessible now. Is there in fact no way to still use the legacy APIs and if so why did you make the decision to nerf such powerful functionality that was frankly necessary to overcome severe performance limitations in the out-of-the-box framework? You kept the stuff Blazor needed but appear to have nuked the rest. If there is any possibility of bringing this back for final release I beg you to do so, otherwise I will likely be stuck on .NET8 indefinitely.

[maraf]

JSImport/Export doesn't support marshalling as JSON (JSMarshalerType.cs), marshalling as JSON is implemented wrapper layer in Blazor. What I was curious about is if using the same APIs that the generated code for JSImport/Export is using would solve supply the ask for custom marshalling method? (Maybe it's not the right idea..)

[legistek]

Ah, right. Well same difference - JSON is what I want to avoid anyway.

The APIs I'd be interested in using are likely the same as what the current marshalling system is using; I'd just then have control over how (or whether) each member of the struct was marshalled.

Wondering if I'd just be better off using Marshal.AllocHGlobal and StructureToPtr or PtrToStructure and then keep reading/writing heap JS side. At least then there's no risk of GC, nor future implementation changes. I had hoped to avoid making an extra copy but it might not make a noticeable difference.

[maraf]

The APIs I'd be interested in using are likely the same as what the current marshalling system is using; I'd just then have control over how (or whether) each member of the struct was marshalled.

Have you looked at the generated code for JSImport/Export? On C# side, you will be able to those APIs directly, but I'm not sure if you would be able to supply the (un)marshalling on JS side. I'm thinking if that's a way to go for advanced scenarios..

[pavelsavara]

The generated code is not doing any magic. It's serializing the arguments into "stack frame like" buffer. StructureToPtr is probably better than meddling with the JSImport generators or its infrastructure. On JS side we expose APIs for working with the heap.

https://github.com/dotnet/runtime/blob/91939711895b6141e1be509ee743a8afb7a64ee7/src/mono/browser/runtime/dotnet.d.ts#L497-L636

There is also Module._malloc and Module._free

[pavelsavara]

In the initial design of JSImport I drafted ability to use [MarshalAs(UnmanagedType.Struct)] but I cut it out of scope.
Mostly because I was not clear who would own the de-allocations.
At the time of Net7 this was not supported by LibraryImport generated style, if I remember correctly.
I would be willing to explore that again, especially if somebody is willing to contribute the implementation end to end.

In the initial design of JSImport I also drafted custom callbacks to be able to de/serialize simple flat structures as JS Object. It added too much complexity and not much benefit. All of this could be done by community in user code.