Using the Blazor.SourceGenerators package 📦

As an example, the official Blazor.LocalStorage.WebAssembly package consumes the Blazor.SourceGenerators package. It exposes extension methods specific to Blazor WebAssembly and the localStorage Web API.

Consider the LocalStorageExtensions.cs C# file:

This code designates itself into the Microsoft.JSInterop namespace, making all of the source generated extensions available to anyone consumer who uses types from this namespace. It uses the JSAutoInterop to specify:

• TypeName = "Storage": sets the type to Storage.
• PathFromWindow = "window.localStorage": expresses how to locate the implementation of the specified type from the globally scoped window object, this is the localStorage implementation.
• HostingModel = BlazorHostingModel.WebAssembly: tells the generator to create synchronous extension methods on the IJSInProcessRuntime type (default), use .Server for IJSRuntime and Task-based asynchronous methods instead.
• OnlyGeneratePureJS = true: configures the source generator to emit only C#, when false will emit JavaScript.
• Url: sets the URL for the implementation.

The file needs to define an extension class and needs to be partial, for example; public static partial class. Decorating the class with the JSAutoInterop attribute will source generate the following C# code:

Using the Blazor.LocalStorage.WebAssembly package 📦

The Blazor.LocalStorage.WebAssembly package is a WebAssembly specific implementation of the localStorage Web API that has been source generated. The example above is the result of this published package.

This package exposes a convenience extension method on the IServiceCollection type, named AddWebAssemblyLocalStorage. Calling this will expose the IJSInProcessRuntime as a dependency injection service type as a scoped lifetime. Consider the following Program.cs C# file for an example Blazor WebAssembly template project:

Then, in your components you can consume this as you would any other service type. Consider the Counter.razor file:

Design goals 🎯

I was hoping to use the TypeScript lib.dom.d.ts bits as input. This input would be read, parsed, and cached within the generator. The generator code would be capable of generating extension methods on the IJSRuntime. Additionally, the generator will create object graphs from the well know web APIs.

Using the lib.dom.d.ts file, we could hypothetically parse various TypeScript type definitions. These definitions could then be converted to C# counterparts. While I realize that not all TypeScript is mappable to C#, there is a bit of room for interpretation.

Consider the following type definition:

This is from the TypeScript repo, lib.dom.d.ts file lines 5,498-5,502.

Example consumption of source generator ✔️

Ideally, I would like to be able to define a C# class such as this:

The source generator will expose the JSAutoInteropAttribute, and consuming libraries will decorate their classes with it. The generator code will see this class, and use the TypeName from the attribute to find the corresponding type to implement. With the type name, the generator will generate the corresponding methods, and return types. The method implementations will be extensions of the IJSRuntime.

The following is an example resulting source generated GeolocationExtensions object:

The generator will also produce the corresponding APIs object types. For example, the Geolocation API defines the following:

• PositionOptions
• GeolocationCoordinates
• GeolocationPosition
• GeolocationPositionError

In addition to this GeolocationExtensions class being generated, the generator will also generate a bit of JavaScript. Some methods cannot be directly invoked as they define callbacks. The approach the generator takes is to delegate callback methods on a given T instance, with the JSInvokable attribute. Our generator should also warn when the corresponding T instance doesn't define a matching method name that is also JSInvokable.

The resulting JavaScript will have to be exposed to consuming projects. Additionally, consuming projects will need to adhere to extension method consumption semantics. When calling generated extension methods that require .NET object references of type T, the callback names should be marked with JSInvokable and the nameof operator should be used to ensure names are accurate. Consider the following example consuming Blazor component:

Pseudocode and logical flow ➡️

1. Consumer decorates a static partial class with the JSAutoInteropAttribute.
2. Source generator is called:
   • JavaScriptInteropGenerator.Initialize
   • JavaScriptInteropGenerator.Execute
3. The generator determines the TypeName from the attribute of the contextual class.
   1. The TypeName is used to look up the corresponding TypeScript type definition.
   2. If found, and a valid API - attempt source generation.

Known limitations ⚠️

At the time of writing, only pure JavaScript interop is supported. It is a stretch goal to add the following (currently missing) features:

• Source generate corresponding (and supporting) JavaScript files.
  • We'd need to accept a desired output path from the consumer, JavaScriptOutputPath.
  • We would need to append all JavaScript into a single builder, and emit it collectively.
• Allow for declarative and custom type mappings, for example; suppose the consumer wants the API to use generics instead of string.
  • We'd need to expose a TypeConverter parameter and allow for consumers to implement their own.
  • We'd provide a default one for standard JSON serialization, StringTypeConverter (maybe make this the default).

References and resources 📑

• MDN Web Docs: Web APIs
• TypeScript DOM lib generator
• ASP.NET Core Docs: Blazor JavaScript interop
• Jared Parsons - GitHub Channel 9 Source Generators
• .NET Docs: C# Source Generators
• Source Generators Cookbook
• Source Generators: Design Document

Contributors ✨

Thanks goes to these wonderful people (emoji key):

This project follows the all-contributors specification. Contributions of any kind are welcome!