CommunityToolkit
ObservableObjectAttribute does not work on a record
Describe the bug
The purpose of the ObservableObjectAttribute is, to add Member of ObservableObject to a type, that itself cannot derive from ObservableObject.
That is actually the case for record classes.
Because ObservableObject is a class and not a record class, a record class cannot derive from it.
But if I put [ObservableObject] on my partial record class there is no source generated.
Regression
No response
Steps to reproduce
1. Multi-Target: net472 and net6.0 (with LangVersion=12), project Type WinExe with WPF, VS 17.11.0
2. Use the following Code:
namespace Test;
using CommunityToolkit.Mvvm.ComponentModel;
[ObservableObject]
public partial record class MyObservableRecord(string Name)
{
private string _Name = Name;
public string Name
{
get => _Name;
set
{
OnPropertyChanging(nameof(Name));
_Name = value;
OnPropertyChanged(nameof(Name));
}
}
}
3. Compile
4. Error:
> error CS0103: The name 'OnPropertyChanging' does not exist in the current context
> error CS0103: The name 'OnPropertyChanged' does not exist in the current context
5. If you replace `record class` with `class` the same code works.
Expected behavior
The expected behaviour would be, that the methods "OnPropertyChanging" and "OnPropertyChanged" (among others) should be generated and be available at compile time.
Screenshots
No response
IDE and version
VS 2022
IDE version
17.11
Nuget packages
- [ ] CommunityToolkit.Common
- [ ] CommunityToolkit.Diagnostics
- [ ] CommunityToolkit.HighPerformance
- [X] CommunityToolkit.Mvvm (aka MVVM Toolkit)
Nuget package version(s)
8.2.2 (but also doesn’t work with 8.3.0)
Additional context
No response
Help us help you
No, just wanted to report this
Isn't the purpose of a record to be immutable? Making it an ObservableObject complicates this a lot. I have seen the use of records on structs but rarely in classes. What stops you from using a class? you could wrap your record (UserRecord) in the Observable class? May be I am missing something.
public class ObservableUser : ObservableObject
{
private readonly UserRecord user;
public ObservableUser(UserRecord user) => this.user = user;
public string Name
{
get => user.Name;
set => SetProperty(user.Name, value, user, (u, n) => u.Name = n);
}
}
Records have some very good features, that are also helpful, even if the object itself is not immutable. For instance, it automatically adds a GetHashCode and an Equals method, that compares the object member-wise. So in the end you save much code, by using a record, even for mutable objects. (
BTW record doesn’t enforce the object to be immutable, and I really wished MS had planned the feature more thoroughly, before releasing it. Like record struct explicitly differentiate between regular "record struct" (mutable) and "readonly record struct" (immutable). The same distinction in "record class" would have made the system better. Anyway, I digress.
To answer your question, nothing stops me from doing just that, I only think it should work on a record two, or - if (records are explicitly not supported) it should generate an error, that explicitly states "[ObservableObject] is not allowed on record class" or something like that.