[XC] Propagate x:DataType from parent scope to "standalone bindings"

[simonrozsival]

Description of Change

The x:DataType should always match the current BindingContext of the current scope. When you pass a binding to the Picker component, the binding context for that binding will be each individual item in the list of items to choose from and not the parent binding context. This is similar to how we have a warning when you don't set x:DataType on DataTemplate and instead the data type from the parent scope would be inherited by the template. That is likely an oversight and should be fixed.

In the cases mentioned in #25141, DataTrigger and MultiBinding, the same reasoning doesn't apply, I think. It makes sense for the binding to inherit the parent binding context type.

Looking at this design in #22023 again after some time, I don't find it intuitive and rather confusing. Especially since the warning doesn't mention that there is a special rule for "standalone" bindings. Unless we are able to distinguish the "Picker" scenario from the "Multibinding" scenario, I think we should remove the restriction. If we do that, we should also revisit #24513 to match the behavior in runtime XAML parsing.

Issues Fixed

Fixes #25141
Fixes #5342
This restriction was introduced in #22023
This change is also related to #24513

[bcaceiro]

Hi @simonrozsival so, to be clear, with this PR, code like this:

  <Border.Triggers>
      <DataTrigger Binding="{Binding Quantity}"
                   TargetType="Border"
                   Value="0">
          <Setter Property="IsVisible" Value="False" />
      </DataTrigger>
  </Border.Triggers>

won't need to specify the DataType ( i'm getting warnings for these in net9) or what should I do?

[simonrozsival]

@bcaceiro you would still need to specify the x:DataType somewhere in the parent scope. The compiler needs to know the exact type of the source type so it can turn the "Quantity" path into a Func<MyViewModel, string> getter = (MyViewModel source) => source.Quantity. We don't want to guess what the right type might be, so you need to do this manually.

at the moment, you need to do this:

  <Border.Triggers>
      <DataTrigger Binding="{Binding Quantity, x:DataType=MyViewModel}"
                   TargetType="Border"
                   Value="0">
          <Setter Property="IsVisible" Value="False" />
      </DataTrigger>
  </Border.Triggers>

if we remove the restriction, it could look like this:

<ContentPage ... x:DataType="MyViewModel">
  <!-- ... -->
  <Border.Triggers>
      <DataTrigger Binding="{Binding Quantity}" <-- this x:DataType would be inherited from the ContentPage
                   TargetType="Border"
                   Value="0">
          <Setter Property="IsVisible" Value="False" />
      </DataTrigger>
  </Border.Triggers>
  <!-- ... -->
</ContentPage>

If you are not worried about non-compiled warnings, for example if your app doesn't have performance issues and you don't have the time to update all the bindings, you can suppress this warning by setting the NoWarn property in your project file:

<NoWarn>$(NoWarn);XC0022</NoWarn>

Does this answer your question? If you have some specific problem you want to discuss, I recommend opening a new issue so we can look into it separately.

[bcaceiro]

@simonrozsival thank you for your explanation. Indeed I already have the x:DataType in the parent scope, in this case the Page, that's why I was wondering if I need to replace, like you suggested right now, or in a future release it won't be necessary. I indeed am most interested in compiled bindings and performance.
I will probably open a new issue for other binding error, namely StaticResource , but will ping you once I have a small repo.

[StephaneDelcroix]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[simonrozsival]

The ItemDisplayBindingWithoutDataTypeFails is now failing because of the bug that will be fixed by #25151

[PureWeen]

/backport to release/9.0.1xx

[github-actions]

Started backporting to release/9.0.1xx: https://github.com/dotnet/maui/actions/runs/11352802876