Remove dependency on ViewModel Class type in Binding Data.

[marner2]

Allow Statically-typed View Models pt 1

It's not as big as it looks: a major change was to move most of the contents of Bindings.fs into a separate file without modification (first commit). Perhaps that could be a different Pull Request.

The big advantage to this refactor is that it fully decouples all of the binding logic from the actual type of the ViewModel, which is going to be important if we want those to be statically typed later on (See #447 for a very rough proof-of-concept).

[marner2]

@TysonMN I'm ready for this to be merged in if you think it's an ok change. There are a lot of smaller changes that can be added as a result of this one, such as splitting the ViewModel.fs file, removing all of those and's, etc.

I see two possible paths for the static view model approach. Either I could make a ViewModelBase that copies most of the code from ViewModel and instead of inhering/overriding DynamicObject it would instead offer base class helpers for property implementation that initialize the bindings the first time they are called.

The second option is to double down on the ViewModelHelper concept and move most/all of the bindings management logic inside of it, then reimplement ViewModel in terms of it and just use that as a pattern for other static view models. It would need a mutable Bindings list with members for adding/getting bindings, updating the underlying model (plus processing it), dispatching messages, and registering PropertyChanged and ErrorsChanged events.

[marner2]

This seems to be related to #418

[marner2]

I believe this is a pure refactor that does not change the existing external interface of the library at all. Everything is purely additive.

[TysonMN]

There are a lot of smaller changes that can be added as a result of this one, such as splitting the ViewModel.fs file, removing all of those and's, etc.
...
This seems to be related to #418

Yep, it is related. I would love for ViewModel.fs to be split up.

[TysonMN]

One of the inline comments requests one change be split off into its own PR.

[marner2]

@TysonMN see #452 for something approximating a final implementation

[marner2]

@TysonMN Every time I format this thing with F# formatter it always touches a ton more files than I intended. Does it work better for you? I'm wondering if it has something to do with Fantomas versioning or if somehow it's not picking up the .editorconfig file.

[TysonMN]

I don't use a formatter, but I am open to it. Want to create a PR where you format every F# file in the repository?

[marner2]

@TysonMN @the-not-mad-psychologist said he could do that. I told him to wait a bit on that, as we're going to have conflicts if we do it while a bunch of PR's are still open.

[TysonMN]

I left two comments

[marner2]

@TysonMN There are two commits here, if you want we can move the second commit to the next PR and then the end of this PR has them all internal