Blazor.Permissions

[vsvsav]

Subj for Web App/Server package?

[IEvangelist]

Hi @vsvsav - I started on building the permissions package using the source generator, initially for the WebAssembly. This is when I realized that the source generator was going to need more work to better understand the TypeScript type declarations. I do have a branch that I've been working on to incorporate this functionality, but it's still a WIP as it's a huge effort and I'm a single dev who only works on side projects when time permits.

The branch is named new-parser, if you have time and are interested maybe we could collaborate on that?

[vsvsav]

Oh.... I will do it much faster and easier with https://www.learnblazor.com/javascript-interop for my project. But I like your "auto" approach.

[vsvsav]

For history: There are no [Blazor.Permissions] in the new branch, but there is [Blazor.Permissions.WebAssembly]

[vsvsav]

BTW, separating packages for WASM and the server is not a good idea. A lot of things could be done universally there. For example, my project uses shared lib for both wasm and the server. SyncFusion controls libs are the same for wasm and for the server app. Only specific things could be different, but not the interface. You have two IGeolocationService versions... I wouldn’t do it that way and a lot needs to be changed, or a wrapper with a unified public interface needs to be written.

[IEvangelist]

BTW, separating packages for WASM and the server is not a good idea.

I disagree, perhaps you're unaware, but WASM has a special use case that avoids a lot of overhead. By targeting the IJSInProcessRuntime specific to WASM, we get synchronous APIs as everything happens client-side, which avoids the async state machine altogether.

A lot of things could be done universally there.

I agree, but the source generator eliminates that concern as it's written for both on my behalf - no need to share code.

[vsvsav]

Perhaps you're unaware, but Blazor Web App (.NET8) with AutoRendering & per component interactivity have 2 projects, and one has a reference to another wasm and you will receive compile errors at the intersection of packages.

PS The type 'IGeolocationService' exists in both 'Blazor.Geolocation.WebAssembly, Version=8.0.0.0, Culture=neutral, PublicKeyToken=null' and 'Blazor.Geolocation, Version=8.0.0.0, Culture=neutral, PublicKeyToken=null'

PPS MS mostly created the same packages for WASM & Server (& even MAUI). Maybe they created one global interface in a package and diff implementation. Package separation is a thing of the past.

[IEvangelist]

Perhaps you're unaware, but Blazor Web App (.NET8) with AutoRendering & per component interactivity have 2 projects, and one has a reference to another wasm and you will receive compile errors at the intersection of packages.

I'm aware, the WebAssembly packages will remain and are for standalone scenarios. Nothing to do with anything related to server-side processing at all. See here: https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0

Observe the note:

I have not had time to add bits for any of the new rendering modes stuff.

Package separation is a thing of the past.

You're free to use the Blazor.Geolocation library, and it will work for everything you're trying to achieve, regardless of Server-side or WASM. But, if you want to target WASM with the standalone model, and would like to take advantage of the reduced overhead, you can use the Blazor.Geolocation.WebAssembly alternative. Anyone who tries consuming both is doing it wrong.

[vsvsav]

Yeah, MS said about old WASM, you can look at CSR (Interactive WebAssembly). Here you have 2 projects (not one!!). So you did not create this project type/auto+per component in VS. And the second part of this project is Microsoft.NET.Sdk.BlazorWebAssembly. Ok, no questions now.