Client-Side Blazor - losing ClientContext entries

[mattj-1]

Hi all,

I'm very new to Blazor and CSLA 5.4.1 (previously worked with 4.3), so I'm probably doing something daft... but it seems the Csla.ApplicationContext.ClientContext only survives one trip to the DataPortal. I add a few ClientContext entries and do a Csla.DataPortal.CreateAsync and the values are there at the DataPortal, but if I make a second DataPortal call (of any sort) my entries have disappeared, with just a "__dataportaltimer" entry showing.

Any thoughts on what I am missing or doing wrong?

Matt

[rockfordlhotka]

Is this a wasm client or server-side Blazor?

[mattj-1]

Hi Rocky, thanks for your reply. It's a wasm client.

[rockfordlhotka]

Well, I've narrowed it down to a client-side issue. The client value flows through the data portal just fine - but for some reason the value is being lost on the client.

[rockfordlhotka]

@mattj-1 I have a potential solution, and am wondering if you would be able to help test?

The issue is that the wasm environment isn't maintaining AsyncLocal values like in other environments, which is where the context values are normally maintained. The alternative is usually to maintain them in thread-local storage, but that isn't available either.

So here's a context manager that maintains the values in static fields:

using Csla.Core;
using System;
using System.Security.Claims;
using System.Security.Principal;

namespace Csla.Blazor.WebAssembly
{
  public class ApplicationContextManagerStatic : Csla.Core.IContextManager
  {
    public bool IsValid => true;

    private static ContextDictionary currentLocalContext = new ContextDictionary();
    private static ContextDictionary currentClientContext = new ContextDictionary();
    private static ContextDictionary currentGlobalContext = new ContextDictionary();
    private static IPrincipal currentPrincipal = new ClaimsPrincipal();
    private static IServiceProvider currentDefaultServiceProvider;
    private static IServiceProvider currentServiceProvider;

    public ContextDictionary GetClientContext()
    {
      return currentClientContext;
    }

    public IServiceProvider GetDefaultServiceProvider()
    {
      return currentDefaultServiceProvider;
    }

    public ContextDictionary GetGlobalContext()
    {
      return currentGlobalContext;
    }

    public ContextDictionary GetLocalContext()
    {
      return currentLocalContext;
    }

    public IServiceProvider GetServiceProvider()
    {
      return currentServiceProvider;
    }

    public IPrincipal GetUser()
    {
      return currentPrincipal;
    }

    public void SetClientContext(ContextDictionary clientContext)
    {
      currentClientContext = clientContext;
    }

    public void SetDefaultServiceProvider(IServiceProvider serviceProvider)
    {
      currentDefaultServiceProvider = serviceProvider;
    }

    public void SetGlobalContext(ContextDictionary globalContext)
    {
      currentGlobalContext = globalContext;
    }

    public void SetLocalContext(ContextDictionary localContext)
    {
      currentLocalContext = localContext;
    }

    public void SetServiceProvider(IServiceProvider scope)
    {
      currentServiceProvider = scope;
    }

    public void SetUser(IPrincipal principal)
    {
      currentPrincipal = principal;
    }
  }
}

Add this to your wasm client project (or your shared project).

Then, in the Program.cs for the wasm client project, alter your UseCsla call to indicate you want to use this context manager:

      builder.UseCsla(c => c.Configure()
        .ContextManager(new Csla.Blazor.WebAssembly.ApplicationContextManagerStatic())
        .DataPortal()
          .DefaultProxy(typeof(Csla.DataPortalClient.HttpProxy), "https://localhost:44320/api/DataPortal"));

In my preliminary testing, this appears to resolve the issue.

I don't believe it will cause unexpected side-effects, because Blazor WebAssembly is single-threaded and so there can't be concurrency issues against the static collections.

[mattj-1]

Rocky, thank you so much - that works.

[rockfordlhotka]

I've implemented the static context manager solution into #2161, so it will be in v5.4.2 and CSLA 6.