[Feature Request] Register services as singletons

Is your feature request related to a problem? Please describe. Hi, I see quite big flaw in the library design, that is - it is registered as scoped service, where in reality this is singleton (talking to window.localStorage). Using singletons and nested lifetime scopes is really common in GUIs (at least more common than in web servers), and I think frontend library should support such scenarios.

Describe the solution you’d like Register services as singleton, or maybe expose it so user can compose them.

[chrissainty]

That’s not correct, you may create your own lifetime scopes, and that’s really common in GUI apps, where you register context per tab. Lots of other libraries depends on things being singletons.

I think you’ve misunderstood my meaning. By default in ASP.NET Core, scoped services are scoped to a request and singletons are scoped to the lifetime of an application. In Blazor WebAssembly there is no request to scope scoped service too, hence they behave the same as a singleton. Also generally speaking, I don’t believe client-side web applications do create their own scopes. This sounds like a desktop development practice and this isn’t desktop development.

Anyway, as you may have seen, we’re going to be adding the ability to registered services as scoped based on the example provided by @Fabster1993.

[ShadowDancer]

Blazor WebAssembly doesn’t have the concept of a scoped service lifetime, scoped services behave as singletons. Blazor Server does have the concept of the usual service lifetimes, however, singleton services can be very dangerous as all clients of the app will share the same instance.

That’s not correct, you may create your own lifetime scopes, and that’s really common in GUI apps, where you register context per tab. Lots of other libraries depends on things being singletons.

Bringing this to your comment. If libraries such as this one registered their services as singleton, then Blazor Server applications would end up sharing the local storage of whoever was the first user to access the application with all subsequent users. I’m sure you can see how this is very very bad.

I do not use server so I had no idea about this 😦

In reality this wouldn’t happen as Blazor registers the IJSRuntime service with different scopes depending on whether its a Blazor WebAssembly or Blazor Server app, Singleton and Scoped respectively. So if we registered our services as Singleton, they would work in Blazor WebAssembly, but would throw an exception in Blazor Server as you can’t inject a service with a shorter lifetime into one with a longer lifetime (IJSRuntime (Scoped) into LocalStorageService (Singleton)).

I think libraries should follow this behavior, they do it for a reason.

I think exposing it as part of the LocalStorageOptions might be the best option. 99% of developers are only going to need the standard registration and I want there to be a little effort to doing this so people understand what they’re doing.

Maybe there should be two separate methods (building on top of what you said about IJSRuntime), to guide people in right direction? Like this:

Services.AddWebassemblyBlazoredLocalStorage();
Services.AddServerBlazoredLocalStorage();

This way both groups of people would get correct defaults, because as you pointed out these environments are totally different, and setting in configuration is something which is easy to miss, and someone could make his/her app around scoped services where it’d break in long run.