Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does this library supports Blazor? #32

Closed
serge-wq opened this issue Jul 10, 2020 · 6 comments
Closed

Does this library supports Blazor? #32

serge-wq opened this issue Jul 10, 2020 · 6 comments

Comments

@serge-wq
Copy link

Hi, I just found this and the library seems awesome. I will definitely give it a try. I was just wondering if I could use this to map routable and not routable razor components to the host project, similar to how the MVC stuff works.

@serge-wq serge-wq changed the title Does this library support Blazor? Does this library supports Blazor? Jul 10, 2020
@merken
Copy link
Owner

merken commented Jul 30, 2020

Hi,

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

@merken merken closed this as completed Jul 30, 2020
@serge-wq
Copy link
Author

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

@merken
Copy link
Owner

merken commented Aug 11, 2020

@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...

@merken merken reopened this Aug 11, 2020
@merken
Copy link
Owner

merken commented Aug 11, 2020

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 👍

@serge-wq
Copy link
Author

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.

@merken
Copy link
Owner

merken commented Aug 28, 2020

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

@merken merken closed this as completed Sep 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants