Xaml.Label --> XF.Label or Forms.Label or View.Label or UI.Label

Feedback from @migueldeicaza and others:

rename Xaml.FooBar to something else, e.g. UI.FooBar or XF.FooBar or Forms.FooBar

Of these I think I would prefer XF.Label, XF.Button etc., but please chime in if you have a preference.

[dsyme]

Hi @charlesroddie

Yes, 2 is necessary for 1.

This enormous task is carried out in DynamicXaml.fs

The code is generated from the model in bindings.json and the binding.json is fairly straight-forward.

Regarding size - I’ve added to the roadmap to double check that the Xamarin tree-shaker removes unused portions of the code and only leaves the update code for the controls you use. If it doesn’t there’s something wrong with the tree-shaker, since there are no circular dependencies.

which attempts to maintain order in a large type-unsafe system.

TBH it’s actually fairly buttoned down. The process of code generation from bindings,json and subsequent compilation checks the overall validity of the construction of DynamicXaml.fs. There are niggles but the approach is sound in the sense that if properties are missing or the bindings.json model is ill-typed then you find out during the construction of the library. I’ve not encountered any practical typing problems from this approach.

You will have to maintain DynamicXaml.fs

You currently need to maintain bindings.json, and yes, there is a question of versioning and delivery.

For 3rd party controls there are various ways to skin this cat and we haven’t started skinning yet (as noted in the README.md). The approach closest to the results you want would be to make an F# type provider that automates the process. You would point the TP at any set of normal-looking control libraries (i.e. controls whose API surface area looks like the ones in Xamarin.Forms.Core.dll) and do the appropriate thing. An optional bindings.json could be used to configure this. The code would look something like this

type XF = XamlBindings<"Xamarin.Forms.Core; Xamarin.Forms.Maps; WidgetsInc.Widgets">

... code as before ...

In theory this approach could remove the need for any base Elmish.XamarinForms.dll library and all necessary code would be injected into the user application. This removes versioning problems but comes with some other drawbacks.

it will only apply to one UI framework

The approach is being prototyped over Xamarin.Forms but can in theory be applied to WPF and UWP directly. That’s a separate story though. XF is a sensible place to start. The approach is fairly straight-forward so it’s likely we’ll see other variations on it.

[dsyme]

Note that implementing the C# 5.0 “open static classes” feature in F# would allow th prefix to be dropped altogether, but right now we need a qualifier.