breaking change from MVVMLight? <TMessage> cannot be Value type (ex. Guid)

[bwjunkie]

mvvmLight allowed
Messenger.Register<Guid>(...
CommunityToolkit error:
Type argument 'Guid' does not satisfy the Class constraint for type parameter TMessage

Question: is this a breaking change from mvvmlight (which must have a different implementation of TMessage?)

note: the migration documentation : https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/migratingfrommvvmlight#migrating-observableobject

// MvvmLight
Messenger.Default.Register<MyMessage>(this, this.OnMyMessageReceived);

// MVVM Toolkit
Messenger.Register<MyViewModel, MyMessage>(this, static (r, m) => r.OnMyMessageReceived(m));

thank you
Josh

[hawkerm]

@bwjunkie the MVVM Toolkit is a spiritual successor not a fork, it didn't start from the codebase of MVVMLight. While it was intended to be easy to migrate from MVVMLight, there was not a goal to maintain complete compatibility with the API/behavior of MVVMLight.

I don't think there was ever an intent to support straight base types for messages. The main issue is Guid is a struct not a class, whether it makes sense or not to support structs as well here is an interesting question, but I'm not sure the implications of that. That's a @Sergio0694 question.

Generally, you'd create a record (class) to encapsulate your message data (which also makes it more extensible for adding other values to your message later on):

public record MyGuidMessage(Guid Id);

Messenger.Default.Send<MyGuidMessage>(new(_guid));

[Sergio0694]

This is correct. We need types to be classes to also enable a number of internal optimizations. It also saves a lot of size 🙂