Type provider instead of generator?

[cmeeren]

Have you considered using a type provider instead of the current generator? Seems to me that it would make it easier for users to get types for 3rd party libraries. They'd just need to create a JSON configuration file, and the type provider could do the rest. AFAIK currently one has to run the generator (an external tool) and check the generated file into source control.

[rastreus]

The Roadmap mentions that switching to a type provider is a discarded idea and directs to a comment.

[cmeeren]

Thanks. Searched the issues for "type provider" before posting, but got no results.

In any case, the comment doesn't mention any reasons not to use a TP - just that it "comes with other drawbacks". I have no problems with that, but it would be great to have these drawbacks on record.

[cmeeren]

Could anyone provide some clarity on the drawbacks of using TP instead of a generator? I'm asking because I'm trying to create a dynamic UI library for WPF, and I don't want to spend a lot of time testing TP generation if Fabulous contributors have already found out there are good reasons it doesn't work. :)

[TimLariviere]

@cmeeren I don't know the exact reasons why the TP idea was discarded. Maybe @dsyme can tell you more about that.

But from my handling of Fabulous day to day, I can say that correctly supporting dynamic view is hard.

Not all controls are good to expose, not all properties either (*Template, CommandParameter, etc.).
Some properties accept a lot of types (string, View, etc.) and you need to provide a conversion from ViewElement to those types when it makes sense (and vice-versa).

Those remaining properties each have their own update logic sometimes.
As you can see from the bindings json file and the ViewConverters file (though to be honest, we can do some cleanup in those files).

Transcribing that into TP would prove really hard.
It's good only when there's a repeating pattern that's consistent...

Even the generator is showing its limits.

I'm currently trying to iron out our implementation of Shell by re-implementing an existing official sample, and there is a lot of specifics that make the generated code of Fabulous.DynamicViews crashes...

Like attached properties, Shell accepts elements deep inside the hierarchy to have attached properties for Shell. The generator can't handle that for now.

Also Shell has a big hierarchy and so to help devs, there is some implicit conversions that create intermediate controls.
So when using Shell, your virtual UI (View.*) does not map 1-to-1 to the existing UI tree, and so you need some specific code to workaround that.

I saw you started adding dynamic UI to Elmish.WPF.
Did you go with TP?

[cmeeren]

I saw you started adding dynamic UI to Elmish.WPF.
Did you go with TP?

No, I went with a generator. TPs are completely new to me so I would have to spend a lot of time learning it, and I figured that in this case, things would take 50x longer to develop if I can't control and verify the output directly. I have no plans of experimenting with a TP at this point.

Not all controls are good to expose, not all properties either (*Template, CommandParameter, etc.).

Yes, I noticed the same thing myself. My weakness here is that I really don't know that much about WPF development, so for each possible thing to exclude I have to dig into it to make sure there's another included way to accomplish the same thing. As a first iteration/POC, my thinking is to include more or less everything that I can reasonably get to compile, discarding stuff I already know doesn't make sense (like command stuff, and I guess templates too). That way I know that it's flexible enough to do whatever needs to be done. Guiding users by only including what makes sense from a non-XAML perspective must come later, because I don't have the expertise right now to list everything that's safe to exclude. For example, I initially thought that styles are pointless because they're bags of setters, but if I don't include Style properties I can't use 3rd party styles (e.g. from Material Design in XAML Toolkit, which I want to use). So while creating new styles aren't important, using existing styles must be possible. So currently I'm erring on the side of caution and including "everything".

And if I adopted a pure whitelist approach, I would have to consider very carefully all possible use-cases for a property. Does the user really need the MouseButtonClickedOnYellowButtonWhileFullMoonPreview event? Well, who the heck knows - it's there, isn't it? (It's not, but you get my point.) At this point at least, that's a lot of unnecessary work. But I'm very open to insights regarding which strategy to choose in the long run.

Some properties accept a lot of types (string, View, etc.) and you need to provide a conversion from ViewElement to those types when it makes sense (and vice-versa).

Yep, such as Button.Content which is obj. I discovered that just last night, but it should be fairly easy to handle things that might or might not be a "shadow DOM" type - a wee bit of boxing/unboxing and type checking. Of course, once you introduce boxing/unboxing (or casting in general) you're opening up a whole category of runtime errors, but I don't see any way around that at the moment. At least it's not like the existing Elmish.WPF (static views), where the architecture is completely based on boxing/unboxing (though thoroughly tested).

Those remaining properties each have their own update logic sometimes.

I have identified a handful of different "prop types" so to speak (e.g. simple types, simple collections, DOM types, DOM collections, events, indexer props which I convert to collection setters, and now also props that might be either simple or DOM such as Button.Content, so I might have to revise these categories), and written update helpers for them. There might be more, but I'll just have to take that as I discover them.

Like attached properties

That's on my list, but I haven't looked into that yet so I don't know exactly how I can solve it. Might be challenging since I would need a solution that supports 3rd party attached properties. But AFAIK it must be done if "Elmish.WPF.Dynamic" (name not decided) is to be generally viable.