by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Peter Morris
    @mrpmorris
    Anything can be an action, including api responses from a server, so having a base class requirement was removed very early on
    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
    Peter Morris
    @mrpmorris
    No need to force any conventions on my users
    Joey Mckenzie
    @joey32793
    Perfect, exactly the answer I was looking for. I completely agree, no need for convention with built-in statically typed actions. Thank you sir!
    Peter Morris
    @mrpmorris
    You're welcome
    Peter Morris
    @mrpmorris
    The C# 9 with statement is going to come in useful!
    Simon Ziegler
    @simonziegler
    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.
    Peter Morris
    @mrpmorris
    Why aren't your property setters private?
    Or not have setters at all?
    Simon Ziegler
    @simonziegler
    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.
    Peter Morris
    @mrpmorris
    Don't have a business object in your state :)
    Jan-Willem Spuij
    @jspuij
    ^^^ this
    Simon Ziegler
    @simonziegler
    Ok. The whole page is there only to show the business object. No business object, no page! What would you suggest as an alternative? Tx
    Peter Morris
    @mrpmorris
    Your view of the business object is not the business object
    Simon Ziegler
    @simonziegler
    I'll admit to not understanding that properly! Let me have a think and maybe ask a bit more later or in a day or two if that's OK. There's no need for me to rush at this because I have other essential work lined up ahead of it. Tx!
    Peter Morris
    @mrpmorris
    Sure, ask later
    Simon Ziegler
    @simonziegler
    Thanks Peter
    BeardyC
    @BeardyC
    Hi guys, qq regarding injecting at startup. Is that possible? I need to inject a token which I'm storing in my state into my HttpHandler since the user is setting this after startup
    Can I inject a specific State at startup?
    Peter Morris
    @mrpmorris
    Do you have the value when the Program.cs main method is running?
    BeardyC
    @BeardyC
    No, the user will be passing it in after startup - it's a token
    Peter Morris
    @mrpmorris
    services.AddScoped<HttpClient>(sp =>
    {
    var yourState = sp.GetRequiredService(typeof(IState<YourState>));
    return new HttpClient { set some properties here };
    });
    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
    Register it as scoped
    BeardyC
    @BeardyC
    @mrpmorris perfect, thank you
    Peter Morris
    @mrpmorris
    Does the user have to sign in before they can use the app?
    BeardyC
    @BeardyC
    The aim will be to redirect to another svc and callback to the page
    Peter Morris
    @mrpmorris
    Like Azure Active Directory or something?
    Tobias Punke
    @Gaulomatic
    @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.
    Peter Morris
    @mrpmorris
    Your own IHttpClientFactory class creates a new scope?
    Tobias Punke
    @Gaulomatic
    When the IHttpClientFactory creates the HttpClient alongside with all the Handlers, a new scope is created.
    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.
    Peter Morris
    @mrpmorris
    I don't use the IHttpClientFactory
    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
    Tobias Punke
    @Gaulomatic
    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.
    Peter Morris
    @mrpmorris
    You could create your own IHttpClient interface instead
    Write a class that passes stuff through to an injected HttpClient
    You only need one HttpClient per scope that way
    Tobias Punke
    @Gaulomatic
    You could potentially run out of sockets when you instanciate HttpClients on your own. Also, changes in DNS are not reflected within the lifecycle of a HttpClient.
    The benefit of the IHttpClientFactory is that it takes care of these issues.
    Peter Morris
    @mrpmorris
    You only need one HttpClient per scope
    Tobias Punke
    @Gaulomatic
    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.
    Tobias Punke
    @Gaulomatic
    A user should not be able to doing something on this API other than resetting his own password. When a user lost the password, the app has to reset the password on his / her behalf.
    This is where I encountered the strange behavior of the IHttpClientFactory.