Add DSL for Component Properties

[kMutagene]

Should be straightforward to implement a union case for the most used properties in callbacks, such as children or value. The rest can be captured by Custom:

type ComponentProperty =
| Children
| Value
| Custom of string

static member convert =
	//do the mapping to the correct string version here 

[kaashyapan]

Alfonso recently open sourced a standalone version of an Html engine and Css engine.
https://github.com/alfonsogarciacaro/Feliz.Engine/tree/main/src/Feliz.Engine

Can we convert the Dash Html components to have an api/DSL similar to what is in the Html engine ?
This would make it more usable.

Same goes for the Css DSL.

[kMutagene]

Interesting! I tried to stay similar with the original implementation to Giraffe.ViewEngine, as that is also used under the hood for some settings. The problem with just using the html of a view engine is that the resulting types will have to be convertible to JSON objects that can be send to the client side dash renderer. If we want a Feliz-style (or Giraffe / old react-style) DSL for the components there are 2 options as far as i see: 1. Making the existing DSL gradually more similar, but maintaining it on our own in this repo or 2. introducing a DSL from any of the DSL/ViewEngine options that can be translated to the JSON objects we need for the renderer. I agree that 2. is the cleaner solution long-term, but it feels like a significant chunk of work. Another consideration is that we want at least the option of the library feeling similar to the python version. If we would go all-in F# DSL only, we would loose that similarity and i also don't know how usable this style of DSL is from C#.

[kaashyapan]

Can you please checkout this commit ?
I have added Elm style DSL for Html and Css and many attributes.
kaashyapan@3940da6

I have copied things over from the aforementioned view engine repo and made the necessary changes.
I think this is better because the consumer need not open another namespace (Feliz or Giraffe) and also the Html stuff dont change. So it is not a maintenance overhead.

I have modified the sample you have in /dev to use the new DSL. So the Json objects and renderer are not affected.

The change lends itself well to C# I think. It is better to have members and interface driven api and avoid DUs.

[kMutagene]

Wow that is amazing! I have to admit i did not look too much into the Feliz.ViewEngine project, it seems to me like you can actually implement that one for any kind of input.

I think this is better because the consumer need not open another namespace (Feliz or Giraffe) and also the Html stuff dont change. So it is not a maintenance overhead.

Not sure about that one, i think the Feliz namespace should be opened implicitly when opening the Html namespace, no?

However, the changes to the Html / addition of the css DSL look very good to me. I think it is now even more similar to the python API as well. I would really much appreciate a PR (without the update to .NET5 for now, i'll address that in your other issue). If you still decide to not referene the Feliz.ViewEngine package, please add a note with a link in the comments in the top of the file to give credit ;) Thank you very much for looking into this!

[kaashyapan]

Not sure about that one, i think the Feliz namespace should be opened implicitly when opening the Html namespace, no?

Yes it does. Feliz namespace contains some useful css helpers.
You will need to open the Feliz namespace if you want to use them.
It is optional. You can do without it.

I will avoid the boiler plate and take a dependency on Feliz.Engine instead of Giraffe.ViewEngine.

I would really much appreciate a PR (without the update to .NET5 for now, i'll address that in your other issue).

I'm having some package downgrade issues on FSharp.Core if I do that. I think it is because of Feliz.Engine.
I've given up fighting with MS build.

Can we do the PR to update to .net5 first and then the Html stuff ?

[kMutagene]

Adding this section from #41 :

In general my preferred approach would be implementing an interface on every component property DU (and the common ComponentProperty type) and adapting @. and Input/Output.create to take that Interface as an input, meaning we can then do this:

let callback =
    Callback.singleOut (
        "clipboard" @. ComponentProperty.N_Clicks, // maybe rename to ComponentProperty -> CommonProperty
        "clipboard" @. Clipboard.Content,
        (fun (_: int) ->
            "clipboard" @. Clipboard.Content => "...clipboard content..."
        )

the interface can be very simple:

type IComponentProperty =
    abstract member PropertyName: string

as is the change on the operator

let inline (@.) (componentId:string) (componentProperty:IComponentProperty) =
    Dependency.create(componentId, componentProperty.PropertyName)

Here is a minimal example:

type IComponentProperty =
    abstract member PropertyName: string

type TestProp =
    | A
    | B

    interface IComponentProperty with
        member this.PropertyName= 
            match this with
            | A -> "a"
            | B -> "b"

/// Shorthand for creation of a dependency (binding of the property of a component)
let inline (@.) (componentId:string) (componentProperty:IComponentProperty) =
    Dependency.create(componentId, componentProperty.PropertyName)

let test = "someComponent" @. TestProp.A