Blazor C# Wrapper for Office.js

[robertmclaws]

It would be amazing if the team could ship a C# wrapper for Office.js that would let us code C# directly against the Office APIs in a Blazor app without having to build our own JSinterop.

[gergzk]

Hi @robertmclaws -
Blazor is new to me, but I wanted to get your thoughts on how it would/could integrate with office.js. I'm starting with the top-level docs: https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-8.0&WT.mc_id=dotnet-35129-website

From my reading, the technology is server-rendered. This suggests the model would be that the manifest would point to an index.html that is rendered from a service owned by the add-in developer (eg: devserver.com/index.html). The implementation is in Blazor. So far so good.

The next hurdle is how and where office.js loads and runs vs where Blazor intends behavior to happen. The docs above say Blazor processes actions in the service. office.js needs to be present on the page in the iframe runtime of the host application. Suppose a user clicks a button to highlight the current selection.

The underlying code that needs to run is something like:

await Excel.run(context => {
const range = context.workbook.getSelectedRange();
range.format.fill.color = "yellow";
return context.sync();
});

This needs to run in the iframe though, because that's where we'd need to be able to post to the host from. From what I can tell, the point of Blazor is that the click would propagate back to the service and be processed by a C# handler, the page updated, and then sent back down and re-rendered.

How would the C# running in the service invoke the Excel.run in the iframe?

[gergzk]

Closing as not planned - technical feasibility seems unlikely.

[robertmclaws]

So, Blazor server rendering is just one option. However the Blazor stack has a unified way of invoking JS commands, no matter where it is happening. Blazor handles registering the Javascript and triggering the iframe loading and what-not.

Blazor can also be exclusively front-end through WebAssembly where the execution context and interop are running in the same process.

The point being is that you don't need to worry about "How would the C# running in the service invoke the Excel.run in the iframe?" as the Blazor runtime already handles that for you.

There are already examples of how to use Office.js in Blazor, and most of those examples involve people still writing their own extensive Javascript and just invoking the JS methods from C#.

What I am suggesting is a native wrapper that would use a TypeScript to C# generator to re-create all of these objects in C#, and then leverage the Blazor JSInvoke infrastructure to translate these calls into invoked Javascript commands.

Since it has been done before, it is technically feasible. It would need a commitment from Microsoft and some budget to spend time on it.

Since WASM is the future of the web, I'm honestly surprised that Microsoft hasn't prioritized this more, because packaging Excel for the web as a WASM desktop app seems like a no-brainer.

[4tti]

I agree this would be awesome!