Ngrx needed that convention to strongly identify action types by name
C# isn't duck typed, so we can do strong type checking
Which is much better
with, init and data should all be really useful for protecting us from ourselves. I've goofed with Fluxor more than once by accidentally changing data within the state store because it's mutable and readonly doesnt always get me where I want to be. Force immutability will help and using with rather than a constructor taking all of the previous state's values save for the changed value will really clean things up.
Or not have setters at all?
I took a few iterations to get my head around immutability, and will be totally refactoring my state stores soon by removing the setters completely. A key business object is however in the store, and that object itself needs to be mutable, or at least does until perhaps I can have the with statement in a few months. There may be a better way of doing things with this business object (and I hope there is), but it will take a lot of thinking. For now I can of course make the state store itself immutable and just need to have a disciplined coding pattern not to abuse its complex constituent parts.
Can I inject a specific State at startup?
No, ignore that
I would create an IHttpClientFactory service
That depends on the state you need and HttpClient
Then it puts the property into the HttpClient that you need, and returns the HttpClient
Then it puts the property into the HttpClient that you need, and returns the HttpClient
Register it as scoped
@BeardyC The
IHttpClientFactory acts a little weired. I wrote a generic auth system so I can use different mechanisms across different Blazor apps. While implementing an OAuth / IdentityModel provider I gave up on the IHttpClientFactory. I have a generic DelegatingHandler which handles HTTP authorization based on the users auth scheme. Therefore it needs to have access to other services which provide the actual authorization implementation and data. Long story short: Somewhere in the pipeline the IHttpClientFactory creates a new DI scope in which the DelegatingHandler processes the request and there is - to my knowledge - no way to access the users auth data within the users „main“ scope. Keep that in mind in case you want to implement something more complex.
The default one is behvaing this way. Took me a while to figure out why all my services got instaciated multiple times until I took a look at the source code. I found a GitHub issue (unrelated to Blazor) which discussed this.
The reasoning behind it is - as I understood it - the lifecycle of the HttpClient and the MessageHandlers which is the reason to use the IHttpClientFactory in the first place.
I created my own interface
And had my own class implement it, and that news up an HttpClient instance and injects stuff from an Auth service
Yes, I did this as well since my apps usually dont serve many thousands of request. But using the IHttpClientFactory can have performance benefits since it shares sockets between HttpClients (when I remeber it correctly) and doesn’t have DNS issues. In a WebAssembly project, there is no issue with this. But a long running Blazor Serverside could, potentially, run into issues. These were the reason why they shipped the Factory some relases ago.
Write a class that passes stuff through to an injected HttpClient
You only need one HttpClient per scope that way
The benefit of the IHttpClientFactory is that it takes care of these issues.
Not in my case. I am authenticating the server-side app itself against a IdentityServer for password resets, lockouts etc. I have a WebAPI build around ASP.NET Core Identity which requires authentication and the blazor app calls. This is handled with a different instance of the HttpClient and DelegatingHandler passing a different bearer token to the request.
This is where I encountered the strange behavior of the IHttpClientFactory.