Can Source Generators Further Simplify Synchronization in MVVM Community Toolkit
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
Direzione di ricerca
Non vengono nominati file del repository, test o punti di ingresso del generatore. Inizia esaminando il comportamento esistente del generatore di codice sorgente ObservableProperty e gli attributi di sincronizzazione proposti, quindi determina se il wiring dichiarativo richiesto per proprietà e raccolte è fattibile. Il lavoro sarà considerato completato quando saranno definiti un’API concordata e un comportamento di sincronizzazione bidirezionale generato, inclusa la prevenzione dei loop.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Overview
I’m using the MVVM Community Toolkit to keep a ViewModel synchronized with a Model, handling both properties and collections. The [ObservableProperty] attribute already simplifies INotifyPropertyChanged implementation, but bidirectional synchronization between the ViewModel and Model still requires manually writing event handlers and update logic. This becomes repetitive and prone to errors, especially with multiple properties or collections.
Current Code:
Here’s my current ViewModel implementation, which synchronizes a Name property and an Items collection with a Model:
using CommunityToolkit.Mvvm.ComponentModel;
using System.Collections.ObjectModel;
using System.Collections.Specialized;
public partial class ViewModel : ObservableObject
{
private readonly Model model;
private bool isSyncing = false;
[ObservableProperty]
private string name;
[ObservableProperty]
private ObservableCollection<string> items = new ObservableCollection<string>();
public ViewModel(Model model)
{
this.model = model;
// Initialize properties from the Model
Name = model.Name;
// Initialize the collection from the Model
foreach (var item in model.Items)
{
Items.Add(item);
}
// Sync properties: Update ViewModel when Model changes
model.PropertyChanged += (sender, e) =>
{
if (e.PropertyName == nameof(Model.Name))
{
Name = model.Name;
}
};
// Sync collections: Update ViewModel.Items when Model.Items changes
model.Items.CollectionChanged += (sender, e) =>
{
if (!isSyncing)
{
isSyncing = true;
if (e.Action == NotifyCollectionChangedAction.Add)
{
foreach (string item in e.NewItems)
{
Items.Add(item);
}
}
else if (e.Action == NotifyCollectionChangedAction.Remove)
{
foreach (string item in e.OldItems)
{
Items.Remove(item);
}
}
isSyncing = false;
}
};
// Sync collections: Update Model.Items when ViewModel.Items changes
Items.CollectionChanged += (sender, e) =>
{
if (!isSyncing)
{
isSyncing = true;
if (e.Action == NotifyCollectionChangedAction.Add)
{
foreach (string item in e.NewItems)
{
model.Items.Add(item);
}
}
else if (e.Action == NotifyCollectionChangedAction.Remove)
{
foreach (string item in e.OldItems)
{
model.Items.Remove(item);
}
}
isSyncing = false;
}
};
}
// Sync properties: Update Model when ViewModel's Name changes
partial void OnNameChanged(string value)
{
model.Name = value;
}
}
Issue:
While functional, this code involves a lot of boilerplate:
- Manual event subscriptions for
PropertyChangedandCollectionChanged. - Explicit initialization of properties and collections from the Model.
- Repeated logic to update one side when the other changes, including an
isSyncingflag to avoid infinite loops.
Question:
Could the MVVM Community Toolkit leverage source generators to eliminate this boilerplate? I’d love to see a solution where synchronization is defined declaratively (e.g., via attributes), and the source generator handles all the event wiring and updates behind the scenes.
API breakdown
How It Could Work:
[SyncWithModel(typeof(Model))]specifies that this ViewModel synchronizes with theModelclass.[SyncProperty("Name")]marks thenameproperty for bidirectional synchronization withModel.Name.[SyncCollection("Items")]marks theitemscollection for bidirectional synchronization withModel.Items.
The source generator could then:
- Initialize
nameanditemsfrom the Model in the constructor. - Subscribe to
PropertyChangedon the Model to updatename. - Subscribe to
CollectionChangedon bothModel.ItemsandViewModel.Itemsfor two-way updates. - Generate the update logic with an
isSyncingguard to prevent infinite loops.
Usage example
Hypothetical Example:
Here’s what I envision the code could look like with source generators:
using CommunityToolkit.Mvvm.ComponentModel;
[SyncWithModel(typeof(Model))]
public partial class ViewModel : ObservableObject
{
private readonly Model model;
public ViewModel(Model model)
{
this.model = model;
}
[SyncProperty("Name")]
[ObservableProperty]
private string name;
[SyncCollection("Items")]
[ObservableProperty]
private ObservableCollection<string> items = new ObservableCollection<string>();
}
Breaking change?
No
Alternatives
None
Additional context
Would the MVVM Community Toolkit team consider adding this kind of source-generator-based synchronization? It would make the code much cleaner and more maintainable. If this is doable, what challenges might arise in implementing it? Alternatively, if there’s an existing way to achieve this with less boilerplate, I’d appreciate pointers or examples.
Help us help you
No, just wanted to propose this
- Lingua principale
- C#
- Stelle
- 3.8k
- Fork
- 401
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di CommunityToolkit/dotnet
-
RelayCommand<T>.CanExecute(null) returns false for value types without a predicateForse già presa @apachezy l’ha presa 77 giorni fa. Apertabug :bug:
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
CommunityToolkit/dotnet#1206 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
CommunityToolkit/dotnet#1186 ·
-
bug :bug:
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
CommunityToolkit/dotnet#648 ·
-
bug :bug:
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
CommunityToolkit/dotnet#1215 ·
-
Add segmented buffering and sequence reads to `ArrayPoolBufferWriter<T>`Forse già presa @paulomorgado l’ha presa 14 giorni fa. Apertafeature request :mailbox_with_mail:
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
CommunityToolkit/dotnet#1214 ·
Tutte le issue di CommunityToolkit/dotnet
Issue simili
-
[誤判定] `define` が `デフィね`・`デフィ値` になるForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta再現済み 要トリアージ 誤判定
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
yksr-melt/Meltype#421 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
Facepunch/sbox-public#12063 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
facioquo/stock-indicators-dotnet#2316 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
lostindark/DriverStoreExplorer#477 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
eriknihlen/OpenAC#219 ·
I maintainer di solito rispondono entro 1 giorno