Document DataContext type inference.

[pixsperdavid]

Is your feature request related to a problem? Please describe.

Currently, binding to the data context of a parent control requires a verbose syntax including a cast. E.g. from the Avalonia docs:

<ItemsRepeater ItemsSource="{Binding MyItems}">
<ItemsRepeater.ItemTemplate>
    <DataTemplate>
    <StackPanel Orientation="Horizontal">
        <TextBlock Text="{Binding DisplayName}"/>
        <Grid>
        <Button Command="{Binding $parent[ItemsRepeater].((vm:MyUserControlViewModel)DataContext).DoItCommand}"
                CommandParameter="{Binding ItemId}"/>
        </Grid>
    </StackPanel>
    </DataTemplate>
</ItemsRepeater.ItemTemplate>
</ItemsRepeater>

The {Binding $parent[ItemsRepeater].((vm:MyUserControlViewModel)DataContext).DoItCommand} in the above example is tricky to get right (personally I still constantly get the casting syntax wrong) and hostile to new users for what is a very common scenario. Additionally the syntax currently requires the import of an additional XAML namespace in order to specify the type cast when this could otherwise be inferred.

Describe the solution you'd like

The simplest solution would be to automatically infer the parent data context's type when resolving the binding.

Another possibility could be the introduce a new binding syntax along the lines of $parentDataContext which infers the type.

Describe alternatives you've considered

No response

Additional context

I'm willing to look at implementation of either the above solutions, or any other suggested way of improving this pain point.

[grokys]

This should have been implemented in 1.3.0 by AvaloniaUI/Avalonia#17204.

What version are you using?

[pixsperdavid]

11.3.7. Apologies I was unaware of this improvement as the docs are outdated.

I just tried removing the cast. It does actually compile, but the Rider syntax highlighting still displays it as an error.

[grokys]

Oh nice! Glad it worked for you. There's not much we can do about Rider as the Avalonia XAML parsing there isn't controlled by us, but we can definitely document this. I will move this issue over to the docs repo.