SOLVED: WASM Databinding broken

[MCAleckson]

I'm writing an UNO WASM app, debugging locally but running in production served across the web from AWS Amplify.

When binding XAML text boxes to attributes and TreeViews to an observable collection on an object fully loaded in memory in the code behind, the locally-debugged page displays perfectly. When loading the page from the AWS Amplify-served app, the text does not display in the text boxes nor in the bound treeview. However, the bound treeview is clearly aware of the items in the collection as you can see the hierachical triangles displayed, however with no text. Note the attached pics.

The object thisOrg has public attributes including string Name and ObservableCollection SubOrgs(more organizations loaded recursively to implement an organizational hierarchy).

After setting the DataContext in the OnNavigatedTo event to:

DataContext = thisOrg;

I then use the standard old binding method for the text boxes:

And for the TreeView I'm using:

Again, everything works from the local browser, but when accessing the app from across the web via AWS amplify, no go. Here's the pics. Thanks in advance for your suggestions!

[jeromelaban]

Thanks for the report.

This looks very similar to the recently fix in #11841, and will be released as a service update to 4.8.x very soon. Could you try to update to a 4.9.0-dev.xx prerelease version so see if it helps?

[MCAleckson]

Jerome,

I've been beating my head against the wall on this (I tried your 4.9.0 dev release suggestion to no avail) - and this morning I finally see that this problem (neither the TreeView nor TextBoxes will display bound text when running from Amplify - they display text just fine when debugging WASM locally) is buried somewhere in:

awaiting asynchronous tasks

The app instantiates the objects in the code behind during OnNavigatedTo that are bound to these text boxes and treeviews - and the objects load their attributes from AWS RDS via the HttpClient.PostAsync method. So, I'm required to await the method (task), of course.

I perform this recursively during the loading of organization->sub-organization->sub-organization->sub-organization.

Again, when the app runs locally the necessary "awaits" run completely loading all data from the database into the instantiated objects, and the bindings in the XAML display text perfectly. When running the app after an Amplify build - the text in the controls is not displayed.

I wonder about CORS headers - but I'm in the dark at this point.

[ToddGlodek]

When you say "more organizations loaded recursively" - are you making a distinct HttpClient.PostAsync request for each node as you dynamically populate nodes in your control tree? Or, do you have a single pre-populated tree structure which you are dynamically data binding as you instantiate new nodes in your control tree?

If it is Option Two then you MIGHT be experiencing this problem: Loading, Loaded & Unloaded events are called too early #2895. I documented, what feels to be a very similar set of symptoms, as part of Page Loading Fails - Potentially because 2 nested XAML controls in a direct parent/child get instantiated/InitializeComponented/loaded in different order between WASM / WinUI #10276. This is also discussed as part of [EPIC] Controls initialization sequence #3519.

Although #2895 & #3519 do not specifically address the FrameworkElement.DataContextChanged Event (and when it fires); what I found was also a different order/sequence was also order between WASM / WinUI. In my case, I was recursively building custom graph/tree of controls and using the DataContext of the parent to instantiate/position the child controls in the graph (see #4073). My hope was to dynamically re-render the control graph whenever any observable property in DataContext changed.

As part of #10276 (comment), I created the following test code to illustrate the issue. I was looking to anyplace such as OnLoaded/OnDataContextChanged/etc where I could

namespace UnoBug2895Test.Views;

internal class SideBySidePanel: Microsoft.UI.Xaml.Controls.Control
{

    /*************************************************************************************
     *   This demonstrates the problem with the sequence of events being fired between   *
     *   WinUI and WASM.  On WinUI the sequence is as below, but on WASM the first       *
     *   step, OnDataContextChanged() is never called - even though ViewModel is         *
     *   instantiated already BEFORE OnApplyTemplate().  (Note: there may be additional  *
     *   intermediate steps in the middle that I am not tracking)                        *
     *                                                                                   *
     *   1)  OnDataContextChanged()                                                      *
     *   2)  OnApplyTemplate()                                                           *                                                 
     *   3)  OnLoaded()                                                                  *
     *                                                                                   *
     ************************************************************************************/


    public SideBySideGrid()
    {

        this.Log().MethodInvoked();

        DataContextChanged += OnDataContextChanged;
        Loaded += OnLoaded;

        DefaultStyleKey = typeof(SideBySideGrid);


    }

    private void OnDataContextChanged(FrameworkElement sender, DataContextChangedEventArgs args)
    {
        //**** WinUI  #1
        //**** WASM @ NEVER CALLED -  Yet, the ViewModel is instantiated already BEFORE OnApplyTemplate(). 
        //****         As a consequence, no event handlers (e.g. On_PropertyChanged) that a developer would attempt 
        //****         to attach here would ever get registered.   So instead, we will attach them in OnApplyTemplate  
        //****         when HAS_UNO.
        

#if !HAS_UNO 
        var vuMod = (args.NewValue as ObservableObject);
        vuMod.PropertyChanged += On_PropertyChanged;
#endif

        this.Log().MethodInvoked();

    }
    protected override void OnApplyTemplate()
    {
        //**** WinUI #2
        //**** WASM #1

#if HAS_UNO
        var vuMod = (DataContext as ObservableObject);
        vuMod.PropertyChanged += On_PropertyChanged;
#endif

        this.Log().MethodInvoked();

        base.OnApplyTemplate();

        var booText = GetTemplateChild("txtBoo");

    }

    private void OnLoaded(object sender, Microsoft.UI.Xaml.RoutedEventArgs e)
    {
        //**** WinUI  #3
        //**** WASM #2

        this.Log().MethodInvoked();
    }

    private void On_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
    {
        this.Log().PropertyChanged(e);

        LeftPanel leftPanel = (LeftPanel) GetTemplateChild("LeftPanel");

        if (leftPanel.IsLoaded)
        {
            if (e.PropertyName == nameof(ShapesDisplayPageVieModel.ShapesList))
            {
                (leftPanel.DataContext as ViewModelLeftCanvas).Shapes = ((ShapesDisplayPageVieModel) sender).ShapesList;
            }
        }
    }
}

@sam-wheat created very similar analysis in #11261 (reply in thread).

[ToddGlodek]

Also, this discussion is happening RelativeSource binding is not supported inside ListView ItemTemplate on uno #11925 - but that seems to be Android/iOS although oddly similar.

[sam-wheat]

@ToddGlodek I wrote a control in WinUI that might be similar to what @MCAleckson is working on in terms of being a node structure. This control exorcises WinUI binding capabilities - perhaps there is something here that might carry over to Uno Platform and be useful to you. This is my first and hopefully last WinUI project. The control is unusably slow - if you come across any tips to improve performance I would love to hear them,

LeaderPivot for WinUI

To appreciate how slowly it renders, here is a demo of the same control in Blazor. Same data, same node/matrix building code.

[ToddGlodek]

That is totally awesome... The speed of the BLAZOR control is amazing !!! NICE WORK !!

[sam-wheat]

Thank you - gotta give credit to Blazor tho - it is amazing.

[MCAleckson]

Todd,

It's multiple PostAsync calls. The Organization class contains a collection of subOrganizations - which are loaded from the database individually. Because organizations can, of course, encapsulate multiple levels of sub-organizations which can also encapsulate sub-organizations - I use the term "recursive". It's probably not correct that I do so.

Nonetheless, what is absolutely crazy is:

• it works just fine when debugging on my local browser.
• and it fails when served over https from AWS Amplify.

Today continues the head-banging. But thank you all for your thoughts on this!

[ToddGlodek]

Let me re-phrase, it works fine running from your local machine against your local test/data store, but when you publish it and host it on AWS Amplify - it doesn't work? Alas, that doesn't sound like the issue I was having.

[MCAleckson]

That's quite close Todd. To be specific, "Data binding works - that is, the data is bound to both text boxes and tree view items when the WASM app is served in debug mode from my local machine - loading data from AWS RDS via PostAsync calls through AWS API Gateway. Data binding fails - that is, no data is displayed in text boxes, and only the arrows (without text) appear for tree view items, when the WASM app is served in release mode from AWS Amplify servers - still loading data from AWS RDS via PostAsync calls through AWS API Gateway."

The "served from Amplify" thing is particular to me.

And again, the crazy thing is that while I can't verify what the Amplify-served app's text boxes know or don't know about their bound data sources - we can clearly see from my original screenshots that the the tree view items are created in precise number and indentation - just without displaying their bound text attributes.

Nuts!

[MCAleckson]

Simpler example of WASM remote-served data binding problem.

Here's the XAML:

Here's the working page. It is running in debug , served from localhost.

Here's the same page, failing when served remotely with the the following CORS headers set (just for testing).

- key: Cross-Origin-Opener-Policy value: unsafe-none
- key: Cross-Origin-Embedder-Policy value: unsafe-none
- key: Cross-Origin-Resource-Policy value: cross-origin
- key: Access-Control-Allow-Origin value: '*'
- key: Access-Control-Allow-Methods value: '*'
- key: Access-Control-Allow-Headers value: '*'

[jeromelaban]

If you're able to trim it down to a repro you can share, it will be easier to troubleshoot. What's in the browser logs, when running in the other environment?

[MCAleckson]

Jerome, I created a simplified test manually adding organization objects with collections of organizations within them to a collection declared in the page code-behind, and then bound the TreeView and TreeView items to that collection.

And in that test, binding works - text is properly displayed running locally and running off the server for this simple app. So I can't reproduce the above problem which I'm continuing to have in my production app, which has much more going on including those async calls. I won't bother sharing the simple repo since it works, and I can't share my production app.

Thank you all for your help!

[MCAleckson]

Okay folks - time for me to eat humble pie (I've gotten used to to the taste of it in my career).

If you've read the above, you can see I've been thrashing through everything from CORS headers, to WASM async-await, to reworking so many aspects of my design.

And the problem was simply that:

WasmShellILLinkerEnabled needed to be set to "false" in Release mode.

Y'all may be aware that in the standard Platform.Uno WASM project template, the property is not explicitly set. So the linker runs as "true". Which as it turns out, breaks my app no matter where it runs (local or remote server) in Release mode.

I know, I know. I'm the poster child for "stubborness can at times make up for knowledge and intelligence".

As I and my team continue building this app, we'll put some work into discovering exactly which libraries need to be explicitly linked and which don't, we'll set WasmShellILLinkerEnabled to "true" and then of course we'll have a smaller executable as a result. But for now, the exe is as big as it can be, and it runs, and we can continue development.

Thanks Jerome and everyone for your thoughts on this!

[sasakrsmanovic]

Thanks for closing off the issue and reporting on it!

[jeromelaban]

@MCAleckson In general, disabling the linker is a symptom of the use of a library or piece of code that is heavily relying on reflection, and does not support well having members being removed.

Disabling the linker also has the effect of making AOT builds a lot longer (a few hours) and also make applications take longer to load (as there's more code to download). It would be best to try and find which library is causing the issue.

You can take a look at this documentation for troubleshooting. You can try to remove individual assemblies from the linker to determine which is causing issues.

[MCAleckson]

Thanks Jerome, I will indeed continue investigating while we continue building required functionality into the app.