Does this library supports Blazor? about prise HOT 6 CLOSED

Hi,

Blazor is not yet supported, but it will be in active development after the next release, which focuses on .NET 5 compliance

from prise.

Thanks a lot for your response. If you need help with anything, don't hesitate to reach out.

from prise.

@serge-wq there are two stories to Blazor (server-side, client-side).

For the server-side, the app would load the plugin assemblies from the server directory (wwwroot).
For client-side, it becomes a bit trickier.

The client would need to download these plugins over the network (I believe it should be packaged, like nuget packages) and load them up on-demand. Not to say it is impossible to achieve, but the design of the Blazor application should be well thought through.

In theory, it should behave similarly to the MVC plugin example found here: https://github.com/merken/Prise.Examples/tree/master/MVCPlugins
Meaning, the host application is a singleton, it loads all the plugins into memory and keeps it there until the app is restarted. The struggle is going to be in the unloading of the plugins.

Performance is also going to be an issue, most of the plugins are packaged with their versions of the dependencies, this results in a (necessary) bulky download for each active plugin.
Long story short, these are the points we need to consider or overcome before supporting Blazor plugins on the client side using Prise:

• Fast plugin download (compact packaging, caching)
• Unloading (re-loading) of plugins in a singleton lifetime
• Removing the Prise.Proxy support (losing backwards compatability) in order to provide faster plugin load times

Looking forward to insight from others...

from prise.

Another thing to keep in mind is that Client side Blazor relies on netstandard. Prise is a netcore-specific library that leverages some netcore 3.0 and 3.1 API's that are unavailable to netstandard 2 (or 2.1).

This does not mean porting Prise to netstandard is impossible, it's worth a try 👍

from prise.

For Blazor Server I don't see much of a problem. As you say the tricky part is client side, but maybe if the client is served by a ASP.NET Core backend the plugins could be loaded from there? This would limit the deploy options for Blazor WASM, though.

Also you can specify from which assemblies the Router component can fetch components to render as pages. This could be helpful if the plugin includes Blazor components as pages.

from prise.

Firstly, I'm checking whether (down)loading an assembly from the server is possible and having it invoked dynamically, but the project first needs to be ported to netstandard2.1 because mono only supports netstandard. You can track progress here: https://github.com/merken/Prise/tree/wasm

from prise.