[Dependencies] In what cases (if any) is it advisable to directly depend on WPF?

[YkTru]

Hi @TysonMN, I was wondering looking at the Capabilities sample:

1 - Is it advisable (or if the project grows potentially “bad”) to be linked to WPF (System.Windows) other than through ElmishWPF Bindings exclusively?:

  let boolToVis = function
    | true  -> Visibility.Visible
    | false -> Visibility.Collapsed

2 - I assume you've created this function to avoid the usual WPF boilerplate, to be more declarative, and as it goes into/with the ViewModel, there's no problem putting converters into it? So in a way, would it make more sense conceptually to put “boolToVis” (and all that depends on WPF) in a “FsWPF.fs” helper file so that it can be reused and not “contaminate” the other files (which should all be UI-agnostic (with the exception of bindings))?

3 - In this post, you said you've never liked WPF converters (and DataTemplateSelector if I understand correctly? ), but for best separation of concerns + reuse + better Xaml integration, could an independent “[ProjectName].FsWPF.proj” (IMO legitimate code-behind) project where I put all the code related to converters, datatemplate selector, behaviors, etc. be the most MVU independent and Xaml-compliant option? eg:

namespace Converters

open System
open System.Windows
open System.Windows.Data

type BoolToVis =
    interface IValueConverter with
        member _.Convert(value, _, _, _) =
            match value with
            | :? bool as b -> 
                if b then Visibility.Visible :> obj 
                else Visibility.Collapsed :> obj
            | _ -> Visibility.Collapsed :> obj
        
        member _.ConvertBack(value, _, _, _) =
            match value with
            | :? Visibility as v -> 
                box (v = Visibility.Visible)
            | _ -> box false

I know I have to add Xaml boilerplate (.Resources) to use such features, and your approach eliminates that nicely. But how would you implement DataTemplateSelector (which I can't see implementing without code-behind)? I used my “FsWPF.proj” (which unidirectionally depends on my Core project, so it can access its types) to implement DataTemplateSelectors for a basic Form Designer, and it worked very well (exhaustive pattern-matching, concise, clean, type safe, etc.); although you seem to have a promising approach), could you share with us a code sample please? (or should I create a new thread?)

Thank you for your time

[TysonMN]

1. Hybrid apps are possible. I have never done that. I have seen some do that while doing a gentle migration from not using Elmish WPF at all to using it completely. I don't know of any other reason to have a binding that doesn't use Elmish WPF.

2. Yes. I don't remember the details now, but I d definitely created that function and put it somewhere that it could be reused.

3. I am not sure what you are asking. Maybe you are asking about the compossible binding API. Although there is still more that I could do, the binding API is now highly composeable.