Can you compare the Epoxy and CommunityToolkit.Mvvm?

[sappho192]

Hi, thank you for maintaining this amazing lightweight library in open-source.

Out of the pure curiosity, can you compare this library and CommunityToolkit.Mvvm (former Microsoft.Toolkit.Mvvm)?
Because both library provides Mvvm structure and can be used in .NET environment, there should be core difference or advantage between them. For me, I'll prefer Epoxy to CommunityToolkit.Mvvm but I want to make a decision with more information.
Sorry if it's already decribed in the README. I'm newbie on MVVM pattern and have very little experience on CommunityToolkit so I don't know they have same features or not.

[kekyo]

Until now, I have designed Epoxy based on my own ideas without referring to other MVVM auxiliary libraries. The only points of reference are the very first 'Prism' and 'ReactiveProperty'. I know only using a base class to assist with PropertyChanged and the latter being able to convert to IObservable<T>.

I know the naming 'CommunityToolkit.Mvvm', but for those reasons, I don't know much about its contents myself. Therefore, the items listed below may be inadequate or incorrect. Therefore, I would appreciate it if someone who knows more about it could supplement this information.

Target platform problems

'CommunityToolkit.Mvvm' targetted for netstandard2.1, but Epoxy has split the package for each platform.
This was a policy that was decided after much agonizing at the beginning of the design process. Certainly, conformance to netstandard allows us to remain neutral for a fairly wide range of platforms. However, I could not compromise on our desire to include the following interfaces in Epoxy:

• Adopt a complete and default asynchronous interface: At the time, there was considerable confusion about having an asynchronous (Task-based async-await) implementation on a UI framework. There was a prevailing misconception of any best practices out there, which created incomprehensible problems (especially deadlocks and race conditions). So I wanted to move in the direction of a compiler type system that could solve this, but to do so, netstandard was not enough, we needed to have access to UI threads, like Dispatcher in WPF. (In Epoxy: UIThread)
• Similarly, if we focus only on the 'ViewModel' side, there is no problem, but netstandard cannot provide an implementation for the 'View' side. This applies to EventBinder and Anchor.
• This is a bit similar to the above, but when implementing custom controls, it is necessary to determine whether or not design-time editing is taking place (In Epoxy: Designer). This is also not possible with netstandard.

Finalized feature for PropertyChanged

Made PropertyChanged handling without any reflection.

This was inspired by a performance improvement request that arose during business applications. In the case of WPF, the data binding is reflection, so it is not possible to improve the speed by handling PropertyChanged only. But at the same time, a method to intervene in the build with MSBuild scripts was established (See RelaxVersioner), which lowered the hurdle of realization. The advantage of Epoxy is that you can automatically use this feature by simply installing the Epoxy package.

Uses with F#

I want to make GUI apps with F#. I want to use MVVM in F#.

As you know, F# is a functional language. And XAML and MVVM, which are OOP-based technologies are not welcome in F# to begin with. Whether to use FP or OOP can be considered a relatively trivial issue in the larger context of realizing a GUI application. And in fact, the knowledge required to realize a modern UI is much more complex. And while such knowledge can be obtained by searching the abundant articles on XAML. It seems that using new FP-based framework, it is rather difficult to reach a modern UI, even if a basic UI can be achieved. Although, if limited to Avalonia, it is possible to achieve a modern UI by using the Avalonia.FuncUI is an excellent option for Avalonia. However, this falls short of the goal of Epoxy, which is to achieve a common interface across multiple XAML platforms.

Alternative to the messenger pattern

The messenger pattern is a technique used when you want to manipulate UI elements directly (it means no data binding possible), but it is problematic in that it places a heavy burden on designing process to separate and bind interfaces. I have seen many beginners who could not understand this and ended up using the code-behind methodology. Therefore, I thought of Anchor/Pile as a structural solution without relying on the user's design skills.

Simplist and covered the DI container

GlobalService is a fairly simple DI container, but I implemented it after realizing that the use of DI is almost non-existent outside of the requirement to separate platform-dependent implementations provided by singletons. A similar implementation is XF's DependencyService, but it is not released in dotnet BCL. In other words, this is positioned as a DI container that Epoxy wants to use commonly on all supported platforms.

---

In addition to the features listed here, I believe that there are many other issues left behind in XAML-based technology. If any of them are not specific to each platform, but are common XAML issues, they may be solved by Epoxy.
If you have such issues, please leave a comment 😄

[sappho192]

@kekyo Thank you so much for your detailed illustration.

Yes, your Anchor/Pile solution helped me easily understanding and utilizing MVVM a lot.
I also like functional programming, so I think your functional implementation can be a really good starting point for me to make a practical GUI program using F#.

I hope more people to know your project. I think it's well worth it :)