Approach for user-extensible Avalonia application.

[AlanPBourke]

Let's say I develop an MVVM Avalonia application and it can be used as is, out of the box. But I also want to allow it to be mutable and extensible to an extent by the end user.

For example the standard application might have a sales order entry view and associated viewmodel. But end users should be able extend the view and viewmodel by for example adding a new bound text entry control and button to the view, and some additional functionality in the viewmodel. They'd presumably be using Visual Studio for this because of the designer support.

Is there any common approach for doing this?

[thevortexcloud]

The simplest (and most stable, albeit not very nice way) of doing this would be to bind to a list of view models. The addin code can just register their view model (based on your child view model, EG TextEntryViewModel) which your view will display.

If you also don't care about trimming you can also just bind to a collection of objects and then let Avalonia/a view locator decide what user control to display inside your view. Which will allow people to make what ever they want appear on the page.

Another simple but also far dodgier option is to actually pass a reference to your view to the addin. At that point the addin can do what ever they want with it. But it also means they can horribly break things and cause conflicts.

Modification of an existing view model is trickier. You can use DI to override which view model gets used (which allows someone to subclass it) but it's fairly dodgy as well if you are dealing with conflicting third party code (EG you might have two different addins that both provide an implementation of a view model). In the past I have seen (non Avalonia) systems avoid this entirely and just stick with an event system. EG an event when text is entered will be fired, and the value in the event can be modified so the underlying view model gets the modified value.

Supporting entirely custom views from third party code though is a lot simpler. You just have to load their views and ensure the view models get assigned and instantiated properly.