Elm module about gjallarhorn HOT 12 CLOSED

Why do you define your functions (such as wrapRO and wrapRW using lambdas? That looks a little odd in F#.

from gjallarhorn.

I wanted to emphasis that these methods generate ViewBinding<'model, 'msg>
Any idea to improve readability is welcomed

from gjallarhorn.

This is interesting. I've been trying to wrap my head around your wrappers (since Gjallarhorn's framework already acts unidirection).

From what I can see, the main benefit here is getting rid of working with the BindingSource/Model, and focusing on the "getter" and "setter" when mapping through the data bindings. I think some of this could be integrated into the core framework (esp. since I'm looking at making some changes there) - I definitely see some of the benefits with regards to simplicity.

from gjallarhorn.

Looking more - I'm not sure why ViewBinding is an option. Was that mainly so you could include oneWay in the list? It definitely adds some unnecessary overhead - and I'm trying to think about ways that could be eliminated cleanly.

from gjallarhorn.

You are right. Option was to distinguish ReadOnly/ReadWrite components or in other words components that generate Observable or not.

Do you need my help to integrate this wrappers inside Gjallarhorn ? If so, have you any requirements on how to integrate them ?

from gjallarhorn.

@bcachet So - I'm taking some inspiration from this, and looking at breaking Gjallarhorn's API and integrating these ideas into "v2"

I've been working on eliminating the magic strings, as well. I'd love your take on the following. Right now, I've been working on rethinking/reworking how this example is done: https://github.com/ReedCopsey/Gjallarhorn/blob/master/samples/ElmInspiredOne/ElmInspiredOne/Program.fs#L32-L41

My current version looks like the following:

namespace ElmInspiredOne

open Gjallarhorn.Bindable

// Note that this program is defined in a PCL, and is completely platform neutral.
// It will work unchanged on WPF, Xamarin Forms, etc
module Program =    
    // ----------------------------------     Model     ---------------------------------- 
    // Model is a simple integer for counter
    type Model = int
    let initModel i : Model = i

    // ----------------------------------    Update     ---------------------------------- 
    // We define a union type for each possible message
    type Msg = 
        | Increment 
        | Decrement

    // Create a function that updates the model given a message
    let update msg (model : Model) : Model =
        match msg with
        | Increment -> min 10 (model + 1)
        | Decrement -> max 0 (model - 1)

    // Our "ViewModel". This is optional, but allows you to avoid using "magic strings", as well as enables design time XAML in C# projects
    type ViewModel = 
        {
            Current : Model 
            Increment : Cmd<Msg>
            Decrement : Cmd<Msg>
        }    

    // This is our design/compile time ViewModel used for XAML and binding for naming
    let d = { Current = 5 ; Increment = Cmd Increment; Decrement = Cmd Decrement }
         
    // ----------------------------------    Binding    ---------------------------------- 
    // Create a function that binds a model to a source, and outputs messages
    // This essentially acts as our "view" in Elm terminology, though it doesn't actually display 
    // the view as much as map from our type to bindings
    let bindToSource =           
        // Create our bindings - the VM type defines the name, the Bind call determines the type of data binding
        [
            <@ d.Current    @> |> Bind.oneWay id
            <@ d.Increment  @> |> Bind.cmdIf (fun v -> v < 10)
            <@ d.Decrement  @> |> Bind.cmdIf (fun v -> v > 0)
        ]         
    // let appComponent = Component bindToSource

    // ----------------------------------   Framework  -----------------------------------     
    let applicationCore = Framework.basicApplication (initModel 5) update bindToSource

I'm curious what you think of this as a potential "primary" API moving forward. I'm considering taking the current approach (which is more flexible) and moving it to a separate namespace to work in untyped/string form if you need the flexibility, and having a "clean" API be the default.

from gjallarhorn.

Your approach offer the flexibility to have optional ViewModel to avoid magic string and being able to define DataContext in Xaml.
I really like the ViewModel approach. It will help use to use all the features of WPF tools which require ViewModel.
In the end, we use Unidirectional Flow to update our Model, and create a ViewModel to satisfy WPF framework. The View part of Elm is our ViewModel.

Defining the ViewModel can be verbose. Maybe we can create modules/types to simplify this part.

Really nice work

from gjallarhorn.

I think the verbosity issue will solve itself. Theres a language feature approved for f# 4.2 that simplifies it... Anonymous records. That lets you define the design time type in one line, without having to write out the VM, and should work from xaml tooling and the quotations. The ViewModel makes a good interim solution.

from gjallarhorn.

from gjallarhorn.

Alright - I'm going to close this issue (for now) - Work is underway for vNext which will include a variation of this.

@bcachet If you want to discuss further, I'm happy to chat on the F# Software Foundation slack team - I'm on there frequently (and often chatting about Gjallarhorn :) ) Would love to be able to bounce ideas off you in real time occasionally.

from gjallarhorn.

The vNext api looks really good 👏

from gjallarhorn.

@bcachet Just pushed this as a prerelease to NuGet https://www.nuget.org/packages/Gjallarhorn.Bindable.Wpf/1.0.0-beta1- Let me know what you think!

Still going to work on nav support before an official release, I think - I pretty sure I have an approach locked in

from gjallarhorn.