Add InvokeNew, GetValue & SetValue to JS interop API #61246

oroztocil · 2025-03-31T15:00:37Z

Description

Adds three new methods to the JS interop API and refactors existing interop communication to pass arguments using a JsInvocationInfo object.

The API design is based on conclusions in #31151 (comment).

Changes

Adds the following async methods:
- ValueTask<IJSObjectReference> InvokeNewAsync(string identifier, object?[]? args)
- ValueTask<TValue> GetValueAsync<TValue>(string identifier)
- ValueTask SetValueAsync<TValue>(string identifier, TValue value)
- The methods are added to IJSRuntime and IJSObjectReference and their implementations with the same scoping behavior as the existing InvokeAsync method.
- Overloads that take a CancellationToken argument, TimeSpan timeout argument, or params object?[]? args argument are also added to be consistent with the overloads of InvokeAsync.
- There is a special overload IJSObjectReference.GetValueAsync<TValue>() that does not take and identifier and simply returns the value of the object (TValue is here meant to be a model of the object's properties that the caller is interested in).
Adds the following synchronous methods:
- IJSInProcessObjectReference InvokeNew(string identifier, params object?[]? args)
- TValue GetValue<TValue>(string identifier)
- void SetValue<TValue>(string identifier, TValue value)
- The methods are added to IJSInProcessRuntime and IJSInProcessObjectReference and their implementations with the same scoping behavior as the existing Invoke method.
Refactors the existing interop bridge methods (e.g. BeginInvokeJS and InvokeJS on the .NET side) that previously passed interop call configuration as separate arguments. The configuration is now packaged into a JSInvocationInfo object which is serialized as JSON string (using a source generated JsonSerializer). Motivation for this change was to make the interop communication across the various supported channels better maintainable and extensible going forward.
Extends the Microsoft.JSInterop.JS library to support the new interop methods, including reading and modifying object properties and invoking constructor functions with the new keyword.
Adds Jest tests for the new functionality in the Microsoft.JSInterop.JS library.
Adds cases for the new functionality to the existing InteropTest in Microsoft.AspNetCore.Components.E2ETests.
Adds DotNetToJSInterop.razor component to BasicTestApp intended for manual testing and debugging of the JS interop functionality on different platforms.

…extension2

oroztocil · 2025-04-01T13:30:24Z

I have not benchmarked the effect of the change in how the interop configuration is passed (i.e. as JSON-serialized object). If needed, I can set up such benchmarks.

pavelsavara · 2025-04-01T13:51:58Z

src/Components/Web.JS/src/Boot.WebAssembly.Common.ts

@@ -14,6 +14,7 @@ import { addDispatchEventMiddleware } from './Rendering/WebRendererInteropMethod
 import { WebAssemblyComponentDescriptor, WebAssemblyServerOptions, discoverWebAssemblyPersistedState } from './Services/ComponentDescriptorDiscovery';
 import { receiveDotNetDataStream } from './StreamingInterop';
 import { WebAssemblyComponentAttacher } from './Platform/WebAssemblyComponentAttacher';
+import { DotNet } from '@microsoft/dotnet-js-interop';


Where is the source for this dotnet-js-interop ?

That's the Microsoft.JSInterop.JS library. See https://github.com/dotnet/aspnetcore/blob/main/src/JSInterop/Microsoft.JSInterop.JS/src/package.json#L2

pavelsavara · 2025-04-01T13:56:15Z

src/JSInterop/Microsoft.JSInterop/src/Infrastructure/JSInvocationInfo.cs

+    /// A JSON representation of the arguments.
+    /// </summary>
+    [StringSyntax(StringSyntaxAttribute.Json)]
+    public required string? ArgsJson { get; init; }


Could this be JsonObject, System.Object or System.Object[] so that we don't have to call JSON de/serialization twice ?

I love JSInvocationInfoSourceGenerationContext, makes trimming better. I wonder if that could also made work for application data types

Good idea, I wanted to do that but forgot 🙂

What do you mean by "application data types"?

2. What do you mean by "application data types"?

I mean that the json code gen would ideally also generate serializer for class Weather or whatever is the application payload passed as arguments by value. Or do we only support simple/value types here ?

The existing API of InvokeAsync takes object?[]? args. This gets serialized to JSON using JsonSerializer.Serialize with options that we set in the framework and don't give users way to customize them.

If I understand correctly how the source-generated features of System.Text.Json work, it is a opt-in thing configured per type (in several possible ways). Do you propose we expose a way for the users to give us a JsonSerializerContext for their types or something akin to that?

Yes, but I don't know how or if that's easy. It could be separate enhancement, because this was not code generated so far. I wonder if making this JsonArray would prevent it from being source-generated compatible.

I agree it would be interesting to investigate this further as a separate improvement. If we expose such optimization to the users it would be an opt-in thing, so the APIs that we're adding here (with default reflection-based serialization of user types) are still needed.

There are several reasons for which we don't do this:

We consider JSON an implementation detail of the IJSRuntime interface that we reserve the right to change in the future.

The serialization is used internally by the framework and we don't want any customization from the user to affect how we serialize and deserialize our internal payloads (for example JSObjectReferences, and so on).

Serialization and deserialization need to match between .NET and JS and there's not a great story for doing this on the JS side, and would require us to expose matching JS APIs.

We already give you a way to customize serialization as much as you want by performing serialization yourself and passing down a byte[] as an argument. We will marshall the byte[] instance and you can do your own serialization and deserialization.

pavelsavara · 2025-04-01T13:58:05Z

src/Components/WebAssembly/WebAssembly/test/PullFromJSDataStreamTest.cs

@@ -118,7 +118,7 @@ public TestJSRuntime(byte[] data = default)
            _data = data;
        }

-        public virtual ValueTask<TValue> InvokeAsync<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors | DynamicallyAccessedMemberTypes.PublicFields | DynamicallyAccessedMemberTypes.PublicProperties)] TValue>(string identifier, CancellationToken cancellationToken, object[] args)
+        public virtual ValueTask<TValue> InvokeAsync<TValue>(string identifier, CancellationToken cancellationToken, object[] args)


Why did the DynamicallyAccessedMembers go away ? They are helping with trimming, no? Do we need them on the new signatures too ?

Is trimming relevant in a test project? Anyway, this got removed by mistake. I thought I added it myself and removed it when reverting unintentional changes. I will add it back just in case.

We discussed this with Pavel. The attributes are used properly in all actual production code. They are not used in most existing mock implementations of IJSRuntime which are found in various test projects. This one particular implementation in PullFromJSDataStreamTest had the attribute and I removed it by accident.

I am going to keep it like that for consistency. (If anyone has a problem with that, then I argue we should add it to all test projects which is annoying because the JsonSerialized alias is declared in shared/LinkerFlags.cs which is not available in most of the test projects due to conflict in referenced projects.)

pavelsavara · 2025-04-01T14:00:22Z

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts


  class JSObject {
-      _cachedFunctions: Map<string, Function>;
+      // TODO(oroztocil): Is it correct to cache functions/properties when they can change?
+      _cachedMembers: Map<string, ObjectMemberDescriptor>;


When is this garbage collected ?

The lifetime of this cache (and the previously used cache for functions) is tied to the JSObject instance which is itself held by a module-scoped object cachedJSObjectsById. See:

aspnetcore/src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts

Line 95 in c13223b

const cachedJSObjectsById: { [id: number]: JSObject } = {

The JSObject reference can be deleted from the module-scoped cache using disposeJSObjectReference function. This is called via interop from the DisposeAsync method of the .NET JSObjectReference instance. (We also call the JS dispose internally for some objects allocated by the JS framework.)

Is DisposeAsync called by JSObjectReference finalizer ?

JSObjectReference does not define a finalizer.

Does that mean that if people don't call it explicitly this always leaks memory? Seems like no-go for me.

The caching is done for performance reasons. Let's not change things that aren't a problem today. The pattern has been to tell people to dispose their refs and this hasn't shown to be a problem in either direction. I would be more worried about DotNetObjectReference if anything than JSObjectReference. In general, we care 100 times less about browser memory than server memory, as in one case it might only crash the tab, in the other it might crash the server. In both cases, there's a bug in the application not correctly releasing the interop references.

The features we just added for dealing with properties are making memory leak worse, right ?
Before this was only caching functions, typically finite number of them.

The features we just added for dealing with properties are making memory leak worse, right ?
Before this was only caching functions, typically finite number of them.

I don't think this is a problem in practice, even if users fail to properly dispose things on the C# side. I don't see a difference between functions and properties, your objects are also going to have a finite set of fields.

There are two levels of client-side caching:

The global JSObject cache (map from numeric IDs to object references) - this is necessary for the JSObjectReference mechanism and we can't/don't want to change that at this point.

The per-JSObject cache of resolved functions - this is an internal implementation detail which is not necessary and I would argue does not make a difference performance-wise. It potentially saves a not very expensive client-side operation whose running time will be marginal compared to the network transfer. The downside is that the cache is never updated even though the things identified by the same names can change.

When I said I would personally be for removing caching, I was only talking about the second kind.

However, I leave it up to you. We can come back to it if someone complains :-)

pavelsavara · 2025-04-01T14:02:30Z

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts

+              return property.parent;
+          }
+
+          // TODO(oroztocil): Do we want to throw on undefined property or return null?


There are few TODO(oroztocil) still sprinkled in this PR

Yes, these are intentional and pertain to the questions below.

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts

src/JSInterop/Microsoft.JSInterop/src/JSRuntime.cs

oroztocil · 2025-04-01T14:10:21Z

There are some question that I want to discuss in this review:

What should happen if user reads undefined property using GetValue(Async)?
- Should we throw? Return null?
- Should it make a difference if only the property itself is undefined (e.g. when only z in x.y.z is undefined), or if some parent scope is already undefined (e.g. when y in x.y.z is already undefined)?
- The current PR implementation throws in both cases.
What should happen if user writes to undefined property using SetValue(Async)?
- Should we define new property?
- Should it make a difference if only the property itself is undefined (e.g. when only z in x.y.z is undefined), or if some parent scope is already undefined (e.g. when y in x.y.z is already undefined)?
- The current PR implementation throws when a parent scope is undefined but defines a new property if only the propert itself (i.e. the last part of the identifier) is undefined.
Do we want the GetValue overload on IJSObjectReference that enables getting the object state from the reference? I implemented support for it because it seemed nice and potentially useful, but I am not sure if we want to have a "too nice" API that would promote misuse of interop 😄

oroztocil · 2025-04-01T14:12:32Z

Previously, resolved JS functions were cached (per object) on the JS side. Do we want to keep that and/or extend it to other resolved properties? Caching can cause issues when the cached property/function gets modified.

pavelsavara · 2025-04-01T14:22:45Z

Non-authoritative, just my opinions

1. What should happen if user reads undefined property using `GetValue(Async)`?
   * The current PR implementation throws in both cases.

Correct.

2. What should happen if user writes to undefined property using `SetValue(Async)`?
   * Should we define new property?

Yes, recursive.

promote misuse of interop 😄

We are far beyond that point with Blazor interop.

Caching can cause issues when the cached property/function gets modified.

No, stale data and memory leaks. I would say that functions as well need to be resolved on every call, because they could be redefined. Especially now, that we have the setter.

javiercn · 2025-04-01T14:47:36Z

src/Components/Web/src/WebRenderer.cs

+                Identifier = JSMethodIdentifier,
+                CallType = JSCallType.FunctionCall,
+                ResultType = JSCallResultType.JSVoidResult,
+                ArgsJson = argsJson,


Including the arguments here is going to be a problem. As far as I can tell, JSInvocationInfo gets json serialized, so this means ArgsJson gets "doubly" serialized which is going to result in a bunch of additional unescaped characters.

I think we should keep the arguments outside of this struct for that reason. I believe the other implementation does it this way, doesn't it?

Could this be JsonObject or JsonArray ?

Regarding DotNetInvocationInfo: It is not comparable because that DTO is only used internally on the .NET side. It is not sent over the interop bridge (in neither SignalR, Wasm interop, nor WebView IPC). Rather, individual arguments are transferred and only then packed into DotNetInvocationInfo.

Meanwhile the JSInvocationInfo is created by the .NET side, sent over the respective bridge, and read by the JS side. The motivation for this is to set up this communication once and then be able to modify JSInvocationInfo without needing to go around and update all the layers of all the bridge implementations again.

I will check if passing args as a JsonObject or JsonArray works well (and what does the over-the-wire message looks like). If there are issues with that, then I will pass it as a separate string argument that is serialized once separately.

src/Components/WebAssembly/JSInterop/src/WebAssemblyJSRuntime.cs

src/Components/WebAssembly/WebAssembly.Authentication/test/RemoteAuthenticatorCoreTests.cs

javiercn · 2025-04-01T15:00:35Z

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts


  class JSObject {
-      _cachedFunctions: Map<string, Function>;
+      // TODO(oroztocil): Is it correct to cache functions/properties when they can change?


Functions could change too, couldn't they?

While it's potentially problematic if something on the path changes, I think we aren't doing anything different here, and this hasn't been a source of problems in the past.

javiercn · 2025-04-01T15:02:28Z

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts

-              const synchronousResultOrPromise = jsFunction(...(args || []));
-              resolve(synchronousResultOrPromise);
+              const valueOrPromise = this.handleJSCall(targetInstanceId, identifier, callType, argsJson);
+              resolve(valueOrPromise);
          });

          // We only listen for a result if the caller wants to be notified about it
          if (asyncHandle) {
              // On completion, dispatch result back to .NET
              // Not using "await" because it codegens a lot of boilerplate


Probably ok to use await here since we don't transpile to ES5 anymore (I might be wrong)

Based on package.json we're targeting ES2019. I'll look into refactoring this with await.

oroztocil · 2025-04-03T14:40:59Z

@javiercn What should in your opinion happen if someone calls SetValue("a.b.c", 123) in the case where a.b is undefined? Should we define both b (as an object containing c) and c (as the value 123)? And what if even a is undefined?

javiercn · 2025-04-03T14:49:03Z

@javiercn What should in your opinion happen if someone calls SetValue("a.b.c", 123) in the case where a.b is undefined? Should we define both b (as an object containing c) and c (as the value 123)? And what if even a is undefined?

We shouldn't do anything and let the browser throw an error same as if you wrote it directly on JS

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts

javiercn · 2025-04-03T15:08:39Z

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts

+          const result =  { parent, name: lastKey } as ObjectMemberDescriptor;
+


Instead of creating an object here, you could define a function function getOrSet(value) { if(arguments.length === 0) { return parent[lastKey]; } else { parent[lastKey] = value; } (or similar) and that way you can treat all options as a function and you don't have to change the cache.

javiercn · 2025-04-03T15:18:23Z

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts

+          if (!this.isWritableProperty(property.parent, property.name)) {
+              throw new Error(`The property '${identifier}' is not writable.`);
+          }


We should make these checks (if at all) when we search for the function/getter/setter as opposed to every time the developer tries to read/write the value. I also don't think we should make this check at all. If you try to write to a non-writable property the browser will already give you an error, so this is redundant work we are doing.

This is important because all these are hot paths.

We had checks for things that would throw in the browser already. E.g. we throw a custom error when we resolve a thing that is not a function while handling InvokeAsync interop call (even though it would be a TypeError in JS anyway).

Some things are not error in JS but could be reasonably expected by a .NET developer to be an error. E.g. reading from a setter-only property is not an error but returns undefined. Writing into getter-only property is not an error and simply does nothing. Both of these seem like a bug that a user would never want to do intentionally.

Is it actually a hot path? This code runs only as many times as the user calls and interop method. The entire interop operation will be dominated by the interop bridge communication (especially if that happens over network). If they call GetValue in a loop, the application will be killed by all the messages, not by this piece of client-side code.

However, if we keep caching resolved members, then it makes sense to do this check only when we resolve the property and not on every access. I can rewrite it like that 👍

I'm fine if we want to keep the checks as long as we only perform them when we look up the value/function.

I can also simply remove the checks and let whatever happens, happen. I did it this way as it seemed to me we are trying to protect the .NET developer a bit from common JS quirks.

Is it actually a hot path? This code runs only as many times as the user calls and interop method. The entire interop operation will be dominated by the interop bridge communication (especially if that happens over network). If they call GetValue in a loop, the application will be killed by all the messages, not by this piece of client-side code.

It's still part of the hot path, and there isn't a significant overhead when we are calling a function from webassembly.

For such fundamental operations like these it's important to "trim the fat" as much as possible as in many situations all these calls accumulate and "compound" over time

I agree with performing the checks once when we resolve and cache the property (or the property access function as you want) but I would still argue for keeping the checks in for the .NET developer's sake. Is that ok with you or should I remove it wholesale?

javiercn · 2025-04-03T15:19:41Z

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts

+          }
+
+          // For empty identifier, we return the object itself to support "dereferencing" JS object references.
+          return property.parent[property.name];


What does this mean "dereferncing" a JSObject reference. Can you provide a concrete example of where and how this is used?

Currently, when you have a JSObjectReference in .NET that points to some JS object, there is no way how to directly get the state of that object. This special case is here to enable doing things like:

IJSObjectReference myObject = await JS.InvokeNewAsync(...); // Do some work with the object like: await myObject.InvokeAsync(...); // Later MyObjectModel data = await myObject.GetValue<MyObjectModel>();

As mentioned in my question #3 before I am not sure if to add that feature. It seems nice but I won't miss it if I remove it.

javiercn · 2025-04-03T15:26:09Z

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts

          }
      }

+      handleJSCall(targetInstanceId: number, identifier: string, callType: JSCallType, argsJson: string | null) {
+          const args = parseJsonWithRevivers(this, argsJson) ?? [];
+          const member = findObjectMember(identifier, targetInstanceId);


findObjectMember needs to receive the JSCallType and create a function that can be cached and used to perform the expected invocation without requiring any additional check/validation.

We can keep JSCallType on the cache for matching purposes if we want to support being able to have the same "path" match multiple JSCallTypes but I don't think that's necessary.

For example, we don't need to support a developer calling a.b.c() as a function and then also being able to call it as new a.b.c()

I am not sure how turning the access into a function is better but you're the boss.

The rest of the code becomes returnValue = func(args)

javiercn · 2025-04-03T15:51:54Z

src/Components/Server/src/Circuits/RemoteJSRuntime.cs

@@ -123,9 +138,11 @@ protected override void BeginInvokeJS(long asyncHandle, string identifier, strin
            }
        }

-        Log.BeginInvokeJS(_logger, asyncHandle, identifier);
+        var invocationInfoJson = invocationInfo.ToJson();


We shouldn't serialize things to a big string here.

We should keep _clientProxy.SendAsync (and the equivalent webassembly method) the same, unpacking the JSInvocationInfo and passing in the individual members.

So you want to keep passing individual arguments across the interop bridge? I.e. only add the new JSCallType value to the already long list of arguments?

Yes, those are not part of the public API, so it's fine, we can change those whenever we want. We can't avoid serializing the arguments as a string, but we don't want to wrap that string into something else and serialize that too.

javiercn · 2025-04-03T15:58:04Z

src/Components/WebAssembly/JSInterop/src/InternalCalls.cs

-        int resultType,
-        string argsJson,
-        [JSMarshalAs<JSType.Number>] long asyncHandle);
+    public static partial string InvokeJSJson(string invocationInfoString);


We shouldn't stringify things here, we need to keep this API the same, including the additional info and passing down the individual members.

What is the point of JSInvocationInfo that you made me implement then?

The point is that whenever we need to add things to the public API we don't need to keep adding overloads to JSRuntime and other public classes.

I see, that makes sense. However, I thought it was also to not having to rewrite the three different transport channels whenever we add some parameter to the interop (which based on my recent experience is the part that takes the most work to do).

javiercn

I haven't finished looking at it but looks like a good starting point. However, there are several things we need to cleanup/polish before this is ready to go. In general terms:

The implementation needs to remain as allocation free as possible:
- JSInvocationInfo needs to be a struct.
- JSInvocationInfo is for the public API only.
  - It should not be JSON serialized, internal APIs need to continue unpacking the parameters and passing them down to the JS side. Otherwise, we pay the cost of:
    - One large string allocation for JSInvocationInfo (in addition to the one for the parameters which we can't avoid).
    - The cost of JSON serialization (which is not negligible in these cases, even with SG).
    - Double encoding of the arguments, since they are already serialized.

javiercn · 2025-04-03T16:10:26Z

src/JSInterop/Microsoft.JSInterop/src/IJSObjectReference.cs

+    /// <param name="identifier">An identifier for the constructor function to invoke. For example, the value <c>"someScope.SomeClass"</c> will invoke the constructor <c>someScope.SomeClass</c> on the target instance.</param>
+    /// <param name="args">JSON-serializable arguments.</param>
+    /// <returns>An <see cref="IJSObjectReference"/> instance that represents the created JS object.</returns>
+    ValueTask<IJSObjectReference> InvokeNewAsync(string identifier, object?[]? args);


Can you provide an example for the case where a IJSObjectReference would invoke a member property using new?

For example when you load a module as IJSObjectReference.

Also simply for consistency sake. There is no rule in JS that you can't have constructor functions in an object.

If you want it remove to save code, sure.

oroztocil · 2025-04-03T16:11:16Z

JSInvocationInfo is for the public API only.

What level do you mean by public API? The user-facing API will not use it. The internal communication methods will not use it. It seems useless to pack arguments into some struct just to destructure them a few lines of executed code later.

javiercn · 2025-04-03T16:15:00Z

src/JSInterop/Microsoft.JSInterop/src/JSInProcessRuntime.cs

+    /// </summary>
+    /// <param name="invocationInfo">Configuration of the interop call.</param>
+    /// <returns>A JSON representation of the result.</returns>
+    protected abstract string? InvokeJS(JSInvocationInfo invocationInfo);


This needs to be (JSInvocationInfo info, string argsJson)]

Ok. It should be said that if we won't be serializing the JSInvocationInfo and sending it to the JS side then it does not matter if we pass argsJson at this level separately.

Fair enough

javiercn · 2025-04-03T16:52:48Z

What level do you mean by public API? The user-facing API will not use it. The internal communication methods will not use it. It seems useless to pack arguments into some struct just to destructure them a few lines of executed code later.

This is in JSRuntimeBase and its public API

    protected abstract void BeginInvokeJS(JSInvocationInfo invocationInfo);

oroztocil added 21 commits March 18, 2025 16:16

WIP implementation with JSInvocationInfo

df3822f

WIP implementation for other platforms, fix tests

bdea46d

Fix function calls, add JS tests

8e51e9c

Add JS interop tests

f227e09

Add new interop methods to InProcessRuntime

9717446

Merge remote-tracking branch 'origin/main' into oroztocil/js-interop-…

1c525a4

…extension2

WIP wasm & webview fixes

e653a00

WebView test fixes

4009275

Add DotNetToJSInterop component to BasicTestApp

5e273e3

Merge remote-tracking branch 'origin/main' into oroztocil/js-interop-…

0443be5

…extension2

WIP add E2E tests for new interop methods

951de51

Add & fix E2E tests for interop

7056120

Merge remote-tracking branch 'origin/main' into oroztocil/js-interop-…

200d736

…extension2

Add test for reading JS property from prototype

e7294ce

Remove debug prints and unwanted changes

42617e4

Remove unwanted indentation changes in legacy code

21caedd

Fix API, remove uneeded files

c7f49d6

Add missing extension overloads, clean up code

93d3006

Rollback unwanted changes

2508129

Revert submodule to origin/main state

45260dd

Merge remote-tracking branch 'origin/main' into oroztocil/js-interop-…

5270dd8

…extension2

dotnet-issue-labeler bot added the area-blazor Includes: Blazor, Razor Components label Mar 31, 2025

Rollback unwanted changes in submodule

c6934f6

oroztocil force-pushed the oroztocil/js-interop-extension2 branch from e6be100 to c6934f6 Compare March 31, 2025 15:10

Fix Microsoft.JSInterop tests

c13223b

oroztocil marked this pull request as ready for review April 1, 2025 13:28

oroztocil requested a review from a team as a code owner April 1, 2025 13:28

pavelsavara reviewed Apr 1, 2025

View reviewed changes

javiercn reviewed Apr 1, 2025

View reviewed changes

src/Components/WebAssembly/JSInterop/src/WebAssemblyJSRuntime.cs Outdated Show resolved Hide resolved

javiercn reviewed Apr 1, 2025

View reviewed changes

src/Components/WebAssembly/WebAssembly.Authentication/test/RemoteAuthenticatorCoreTests.cs Outdated Show resolved Hide resolved

javiercn reviewed Apr 1, 2025

View reviewed changes

Code review fixes

2f84ea0

javiercn reviewed Apr 3, 2025

View reviewed changes

src/JSInterop/Microsoft.JSInterop.JS/src/src/Microsoft.JSInterop.ts Outdated Show resolved Hide resolved

javiercn reviewed Apr 3, 2025

View reviewed changes

Minor code review changes

28c8d39

Remove JSInvocationInfo from interop bridge communication

1d8495c

		const result = { parent, name: lastKey } as ObjectMemberDescriptor;

Add InvokeNew, GetValue & SetValue to JS interop API #61246

Are you sure you want to change the base?

Add InvokeNew, GetValue & SetValue to JS interop API #61246

Conversation

oroztocil commented Mar 31, 2025 • edited Loading

Description

Changes

oroztocil commented Apr 1, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oroztocil Apr 2, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oroztocil Apr 1, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oroztocil commented Apr 1, 2025

oroztocil commented Apr 1, 2025 • edited Loading

pavelsavara commented Apr 1, 2025 • edited Loading

Choose a reason for hiding this comment

pavelsavara Apr 1, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oroztocil commented Apr 3, 2025 • edited Loading

javiercn commented Apr 3, 2025

javiercn Apr 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oroztocil Apr 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

javiercn Apr 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

javiercn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oroztocil Apr 3, 2025 • edited Loading

Choose a reason for hiding this comment

oroztocil commented Apr 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oroztocil commented Mar 31, 2025 •

edited

Loading

oroztocil Apr 2, 2025 •

edited

Loading

oroztocil Apr 1, 2025 •

edited

Loading

oroztocil commented Apr 1, 2025 •

edited

Loading

pavelsavara commented Apr 1, 2025 •

edited

Loading

pavelsavara Apr 1, 2025 •

edited

Loading

oroztocil commented Apr 3, 2025 •

edited

Loading

javiercn Apr 3, 2025 •

edited

Loading

oroztocil Apr 3, 2025 •

edited

Loading

javiercn Apr 3, 2025 •

edited

Loading

oroztocil Apr 3, 2025 •

edited

Loading

oroztocil commented Apr 3, 2025 •

edited

Loading

javiercn commented Apr 3, 2025 •

edited

Loading