Skip to content

[Samples] ToolkitSampleMultiChoiceOption should take a converter method parameter/Action #149

@michael-hawker

Description

@michael-hawker

Problem Statement

@Arlodotexe I was just creating a sample for Expander and was using ToolkitSampleMultiChoiceOption for the expand direction of 'Down' or 'Up':

[ToolkitSampleMultiChoiceOption("ExpandDirection", title: "Expand Direction", "Down", "Up")]

However, these are strings... so I needed to add a long unwieldy converter that most folks wouldn't need to the sample:

ExpandDirection="{x:Bind local:ExpanderFirstSamplePage.ConvertStringToDirection(ExpandDirection), Mode=OneWay}"

public static MUXC.ExpandDirection ConvertStringToDirection(string direction) => direction switch
{
"Down" => MUXC.ExpandDirection.Down,
"Up" => MUXC.ExpandDirection.Up,
_ => throw new System.NotImplementedException(),
};

Suggested Solution

It'd be nice if instead, we could have this be part of the Labs sample source generation process here to simplify they desired output for these scenarios:

ExpandDirection="{x:Bind ExpandDirection, Mode=OneWay}" 

As in an app scenario, the developer is probably just using the enum type directly, this is a sample implementation detail in the current setup.

Ideally, we could specify the method/action for converting in the attribute (as an Action I guess or delegate, that should mean llambda or method are supported I think):

[ToolkitSampleMultiChoiceOption("ExpandDirection", title: "Expand Direction", converter:nameof(ConvertStringToDirection), "Down", "Up")] 
...

public static MUXC.ExpandDirection ConvertStringToDirection(string direction) => direction switch 
 { 
     "Down" => MUXC.ExpandDirection.Down, 
     "Up" => MUXC.ExpandDirection.Up, 
     _ => throw new System.NotImplementedException(), 
 }; 

(I'm not sure how the current implementation works, so this may require two properties linked together, one bound to the generated UI that uses the string/radio connection, and another one which listens to that, passes through the function, and is the one bound by the sample.)

But the idea is, this would generate the ExpandDirection with the return type of the converter function instead of string and then when the user selects the option and updates the value would pass it through the action specified first.

Also, if a method is tagged in the attribute this way, we should hide it in the C# code view for displaying the sample code.

Other Considerations

Or maybe we want it to be based off a bool for the sample:

ExpandDirection="{x:Bind local:ExpanderFirstSamplePage.ConvertBoolToDirection(IsExpanderDown), Mode=OneWay}" 

In this case the sample class would actually have two converters, one that converts our string to the bool being expected by the sample for IsExpanderDown, and then the one the sample is actually using to demonstrate mapping that to an enum.

[ToolkitSampleMultiChoiceOption("ExpandDirection", title: "Expand Direction", converter:nameof(ConvertStringToBool), "Down", "Up")] 
...

// hidden from C# view
public static bool ConvertStringToBool(string direction) => direction switch 
 { 
     "Down" => true
     "Up" => false, 
     _ => throw new System.NotImplementedException(), 
 }; 

// Still seen, as in use by example
public static MUXC.ExpandDirection ConvertBoolToDirection(bool direction) => direction switch 
 { 
     true => MUXC.ExpandDirection.Down, 
     false => MUXC.ExpandDirection.Up, 
     _ => throw new System.NotImplementedException(), 
 }; 

Other Notes

The Sample Author may want to just show a converter, and that should be fine. This is more for cases with enums or other complex types where you want a simple selection choice and a simple binding (as would appear in an app).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    📋 Backlog

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions