Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[Feature Request] Register services as singletons

See original GitHub issue

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.

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:6 (3 by maintainers)

github_iconTop GitHub Comments

chrissaintycommented, Mar 10, 2022

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.

ShadowDancercommented, Mar 10, 2022

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:


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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Dependency injection in ASP.NET Core
Overview of dependency injection; Register groups of services with extension methods ... Singleton objects are the same for every request.
Read more >
How to register a service with multiple interfaces in ASP. ...
In this post I describe how to register a concrete class with multiple public interfaces in the Microsoft.Extensions.
Read more >
Dependency injection guidelines - .NET
If a type or factory is registered as a singleton, the container disposes the singleton automatically. In the following example, the services ......
Read more >
Dependency Injection - Singleton? · Issue #504
ConfigureServices is run and an instance is specified with the service registration). Every subsequent request uses the same instance.
Read more >
DI : add support to eager load a singleton service · Issue ...
This adds a mechanism to register services to be activated during startup of a host instead of on first access.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found