Add Content / Link to Converters chapter pointing to Community Toolkit

[DevTKSS]

What would you like clarification on

Summary: Please add a Link to the Converters given from Community Toolkit (link below) and add some how-to guide or at least add future description and mentioning into the existing converters documentation section.

My Context to this: On researching xaml and converters to get conditional xaml ability without having to add horrible amounts of overhead I did found this enchancement here: Community Toolkit Converters. They are all using the Normal Converters we know as far as I seen, but especially for beginners and people who hate doing the same functionality again and again, its very usefull if these Converters could be at least more mentioned in the Tutorials or Helpers section.

Additional spontane enchancement idea not related to documentation: A Genious enchancement (in my opinion) would be, if it would be possible to get these converters by default into the intellisense when doing a binding or x:bind that contains a Converter tag. Maybe that would make an additional xmlns: or using for this not longer be needed. But since I dont know, if such things are even possible, i would leave that decision up to the experienced ones of you 😁

Concern

Developing with Uno

Affected platforms

Skia (WPF), Windows (WinAppSDK)

Any feedback?

Read the existing issue to the conditional xaml from 2019 #789 And althought I am struggeling to understand all of whats written there, the converters provided in link might be also a kind of step foreward for this discussion there? Maybe some expert who fully understands the content of the linked issue could quickly have a look on it if that could match your needs there.

[jeromelaban]

Thanks for the suggestion. In general we're pushing developers towards x:Bind functions, which is more flexible and requires less code.

Additionally, with regards to standard XAML development, we encourage developers to read the Microsoft documentation first, which explains those topics in details.

[DevTKSS]

1. x:Bind

I did understand it as if it is outdated to use and Binding is the way to do, because of the caption in documenation to that:

Uno Support for x:Bind Uno supports the x:Bind WinUI feature, which gives the ability to:

bind to normal fields and properties static classes fields functions with multiple parameters events x:Bind on "Plain-old C# Objects" (POCO) created in XAML

e.g. if I tell

x:Bind local:MainModel.Title, Mode=OneWay

It do tell that Title is no static porperty as mentioned above and listed it as error. So for at least the Model Binding there seem to be no oportunity for that if it is not Static or will it compile althought correctly because the generator of the codebehind is pushed only then?

2. Converters and the CommunityTookit

You are absolutly right by guiding to their documentation, so maybe let me specify my idea behind my post here:

We do have a guide to "How to use CommunityToolkit 8.x" and somewhere else also a "Converters" Topic in the Documentation. The Toolkit Guide is telling about the imlementation of a Control section, where I did get the information from to add the package and that for using this, there is a minimum target version of windows needed. Not that there at least are samples of Converters are included

The Converters mentioned in Uno docs are only in the c# area and just telling that IValueConverter Interface is needed for that and giving implementation example how to use it in c# markup fitting to the area it is in. But giving the actual code which is provided there:

---

Using a Converter There may be times when you may want to simply use a converter instead of providing a delegate over and over. For these scenarios, you may want to provide some sort of static readonly context like:

public static class Converters
{
    public static readonly IValueConverter InverseBoolConverter = new InverseBoolConverter();
}

new Button()
    .Enabled(x => x.Binding(() => vm.IsBusy)
        .Converter(Converters.InverseBoolConverter));

---

I came to the result that this Converters Documentation should be clearer Marked as "WPF" section, because for non WPF using uno applications you would have to do this import:

using XCeed.WPF.Toolkit.Core;

but in a non WPF solution the question would be: Do we want to have a WPF import in a non-WPF Application? My Answer would be No. So resulting of that, my Idea was to add a guide for how to implement the CommunityToolkit in a Uno application for example Xaml Code in a non WPF Application like I did.

So minimal effort way for adjustment could be: If someone uses the searchbar with "Converters" and got ot the c# section, there could be a link in the "Using a Converter" for pointing towards the CommunityToolkit for non wpf applications, so there would be the way to go for having the whole way to go, not missing the maybe needed import and guide to use the toolkit in uno app before actually be able to use it without trouble.

On the WTK section I took a closer look and compared to the provided sample, there is missing a (for beginners who actually use tutorials and how to guides) section which tells the reader to do the section.

If there would be someone who could cross read and do the formatting (and Links, because seems that github web is not good for links), I could write the (for me missing) parts and provide it in a PR.

[jeromelaban]

Thanks for the update.

It do tell that Title is no static porperty as mentioned above and listed it as error.

Static properties are being addressed to some extents in https://github.com/unoplatform/uno/pull/18695.

Do we want to have a WPF import in a non-WPF Application?

You cannot import code from WPF as is, you need to convert it to WinUI first.

[DevTKSS]

Thats what I said, I would not want a wpf import in a non wpf application, so in my opinion for a not wpf application we would need at least mentioning in the documentation in the converters topic, that would lead the user of documentation e.g. to the CommunityToolkit import and their documentation, to know what is missing there. At the moment with just telling the reader to use this code mentioned in the converters section top area, and not mentioning this, the compiler will tell that this element is not known and leave the user with the idea to import the (like you said correcltly: not useable/wanted) wpf namespace or create this missing element.

[DevTKSS]

@jeromelaban and to the x:Bind: I do not fully understand what this PR is saying to the mentioned problem, sorry. You are telling "static properties are addressed" but (tell me if i am wrong) the properties like Title or Name, we have in the MainModel file, are not marked as static, instead as e.g.:

IState<string> Name

Which makes the compiler throw a error.

Using x:Bind for Binding to the TextBox.Text and a converter do work, but unlike in c# markup (my app uses navigation if thats relevant) I did not have the vm to bind that property or method to using x:Bind.

Tryed this code for e.g. Title Property:

.Text("{x:Bind local: MainModel.Title, Mode="OneWay"}")

And the error points to the .Title part there to be not static, what is correct, but I don't know how to change that, so the compiler is happy and Me using x:Bind instead of Binding for that. In the xaml I did not find the DataContext I have in c# markup

[jeromelaban]

I'm sorry, I misunderstood that you were talking about C# Markup. x:Bind is a XAML feature, not a C# Markup feature.

Essentially, C# Markup generally does not need converters. It is only needed to call methods that do bindings (including conversion) without needing to go to IValueConverter.

[DevTKSS]

no, I was not talking about c# markup, just compared the functionallity. In a c# app you do say vm.Title (that uses DataContext which is in a c# markup app set at the top of the page definition. is there a common workflow for that? if I am adding

public MainViewModel vm => (MainViewModel)DataContext;

The Project will not build anymore with the InitializeComponent issue and telling me that the Properties of e.g. Name and Title which the intellisense suggested to me for

x:Bind vm. //<-suggestion here after the dot

repo to that showing how i did the x:Bind: https://github.com/DevTKSS/MyUnoXamlApp.git

if there could be a relation to not just "me making issue in coding" then actually InitializeComponent() issue I can link it there also.