Automate control generation

[TimLariviere]

It took a few months, but the Fabulous generator has finally been rewritten and is now easily customizable. :)

By forking the generator and reusing the JSON bindings file, there's 2 options:

• Continue like today and make fabulous-simple-elements a wrapper around Fabulous.DynamicViews controls (not really efficient)
• Bypass Fabulous.DynamicViews, and generate the same controls, with the same properties but directly adapted for the fabulous-simple-elements syntax.

https://github.com/fsprojects/Fabulous/blob/master/tools/Generator/CodeGenerator.fs

[dsyme]

@TimLariviere This work to generalize the bindings is amazing!

• Continue like today and make fabulous-simple-elements a wrapper around Fabulous.DynamicViews controls (not really efficient)

What's the root cause for the differences in efficiency? Is it that the creation of the ViewElement property bags just ends up less efficient?

[Zaid-Ajaj]

@TimLariviere Thank you for the follow-up, indeed the generator looks very clean! I will need to dive into it to see whether it will be applicable for simple elements because sometimes I want to customize extension methods into the property items (see Util.fs) which is not applicable to all elements and since the elements API is reasonably stable, I am not sure if I really need it.

Bypass Fabulous.DynamicViews, and generate the same controls, with the same properties but directly adapted for the fabulous-simple-elements syntax.

I would rather go for option 1 (with or without the generator) to keep the library backwards-compatible with what already exists in the core of Fabulous

Continue like today and make fabulous-simple-elements a wrapper around Fabulous.DynamicViews controls (not really efficient)

In theory it might be less efficient because of the intermediate steps, boxing and unboxing values etc. but in practice it does not really matter (I need numbers or user cases).

[TimLariviere]

What's the root cause for the differences in efficiency? Is it that the creation of the ViewElement property bags just ends up less efficient?

@dsyme No, ViewElement is fine. I meant avoiding to reuse the View DSL of Fabulous.
Currently fabulous-simple-elements builds its controls on top of it to create its own DSL.
This repo could be optimized by directly building against ViewElement like we do.
For instance, not sure if it benefits from the inlining of the methods like View.Button(...).

In theory it might be less efficient because of the intermediate steps, boxing and unboxing values etc. but in practice it does not really matter (I need numbers or user cases).

@Zaid-Ajaj I agree the impacts will be low, but some platforms are quite sensitive to this, like Android.
Even in release mode with full options (linker, proguard), an Android app will most likely need optimizations in the code to run smoothly.
I suspect it's a part of what led to the issue fabulous-dev/Fabulous#241

But for now, I think it's fine to continue the same way fabulous-simple-elements does.
And only change it if the need arises.