Add support for different ServiceLifetime

[Carl-Hugo]

I needed to inject the services in classes with Singleton lifetimes (in a Blazor WASM app), so I needed a different lifetime than Scoped. Since the classes have an internal visibility modifier, I could not register them by hand.

I took the liberty to use TryAdd instead of Add so someone could replace bindings beforehand instead of registering overrides after. Please let me know if you prefer Add instead.

[chrissainty]

Hi Carl, could I ask why you needed to use Singleton instead of scoped?

[Carl-Hugo]

Because my services are all registered as singleton, and you can't inject a scoped service in a singleton.

[chrissainty]

Why can't you register your services as scoped? Singleton and scoped behave the same in Blazor Wasm.

[Carl-Hugo]

More context: I'm building a central state management library (still very experimental at this stage), so Singleton seems more semantically sound to me for a central state store than Scoped (even if they behave the same). Moreover, don't MSFT recommend using Singleton over Scoped in Blazor WASM? (I may be wrong on this one, but I'm pretty sure I read that somewhere in the docs a while ago)

That said, your suggestion works as long as I control all of the dependencies; what happens the day someone needs to inject a service that depends on SessionStorage in another service that has a singleton lifetime and that they can't control the lifetime of? Answer: back to this issue.

If you do not want to allow SessionStorage consumers to manage the lifetime of services or have a good reason to keep it as-is, that's fine; I can always write my own JavaScript interop. It was just faster to use an existing library to run my experiments, and when I faced the Scoped issue, I wanted to contribute the fix back, that's all. I won't be offended if you reject the PR (that I did not ask about opening in the first place).

Hopefully, this added enough context and clarity.

Thanks for your time, and happy new year!

[Carl-Hugo]

For the record, I went over the docs again, about the Singleton vs Scoped in Blazor WASM, and what I remembered was either old info or wrong; that memory was from more than a year ago for sure.

That said, I took a few hours to write an implementation of the Web Storage API, also open-source: ForEvolve.Blazor.WebStorage. The design is different, of course. I linked back to both your local and session storage projects in the README as related projects, as a courtesy; your projects are more mature after all.

So I won't need this PR anymore, thanks again for your time.