Skip to content

Commit f7fd837

Browse files
Merge pull request #23 from windows-toolkit/Sergio0694-patch-1
Added Preview 3 changelog
2 parents 1c5a2f4 + 5244c22 commit f7fd837

File tree

1 file changed

+96
-0
lines changed

1 file changed

+96
-0
lines changed

CHANGELOG.md

Lines changed: 96 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,96 @@
1+
# API changes in Preview 3:
2+
3+
🆕 New `ObservableValidator` class, which supports the [`INotifyDataErrorInfo`](https://docs.microsoft.com/dotnet/api/system.componentmodel.inotifydataerrorinfo) interface.
4+
5+
🆕 Added new constructors with cancellation support to the async commands, and added new cancellation-related properties to the async command interfaces.
6+
7+
🆕 Added a new `WeakReferenceMessenger` type. This type is less performant than the other messenger, and uses more memory, and in return only uses weak references to track recipients. This type essentially mirrors the behavior of the `Messenger` type from `MvvmLight`, making the transition easier for developers migrating from that library.
8+
9+
🆕 Introduced a new custom delegate to represent message handlers, which also receives the current recipient as additional input parameter (💥 breaking change, see code changes below).
10+
11+
✅ Renamed `Messenger` to `StrongReferenceMessenger` (💥).
12+
13+
✅ The `WeakReferenceMessenger` is now the default messenger used by the `ObservableRecipient` class (💥).
14+
15+
✅ Changed `ObservableObject` overloads using `Expression<Func<T>>` to be more efficient (💥).
16+
17+
✅ API changes to the `SetPropertyAndNotifyOnCompletion` (as detailed in [this blog post]( https://devblogs.microsoft.com/pax-windows/mvvm-toolkit-preview-3-the-journey-of-an-api/), 💥).
18+
19+
🚨 Removed the `Ioc` class (we will include docs on how to easily start using the `Microsoft.Extensions.DependencyInjection` library directly to work with dependency injection, 💥).
20+
21+
## Breaking changes
22+
23+
💥 If you were registering message handlers, no API changes are required for messages registered through the `IRecipient<TMessage>` interface. If you were manually registering handlers with the `Action<TMessage>` delegate instead, you will need to modify their code as follows:
24+
25+
```cs
26+
// Preview 2
27+
Messenger.Register<MyMessage>(this, message =>
28+
{
29+
// Do stuff with the message here...
30+
// Note that invoking this instance method means that
31+
// the lambda expression is also capturing "this".
32+
// This issue was also present in MvvmLight.
33+
SomeInstanceMethod();
34+
});
35+
36+
// Preview 3
37+
Messenger.Register<MyViewModel, MyMessage>(this, (recipient, message) =>
38+
{
39+
// Do stuff here...
40+
// Note that since we're accessing the recipient from the
41+
// input parameter, the lambda expression is not capturing
42+
// anything anymore, which allows the C# compiler to cache it.
43+
// Note that we can still access all private members of the
44+
// recipient from here, even if we're using the input parameter.
45+
recipient.SomeInstanceMethod();
46+
});
47+
```
48+
49+
💥 If you were directly referencing `Messenger.Default` to send messages (ie. outside of the `ObservableRecipient` class, which exposes a `Messenger` property which is unchanged), you'll need to replace that with either `WeakReferenceMessenger.Default` or `StrongReferenceMessenger.Default`, depending on the desired messenger to use.
50+
51+
💥 If you want to use the `StrongReferenceMessenger` class for better performance, make sure to pass that to the constructor of the `ObservableRecipient` class, otherwise the `WeakReferenceMessenger.Default` instance will be used.
52+
53+
💥 If you were using the `ObservableObject.SetProperty<T>(Expression<Func<T>>, ...)` overload, the code needs to be updated as follows to replace the LINQ expression with a stateless lambda expression:
54+
55+
```cs
56+
private readonly User user;
57+
58+
public string Name
59+
{
60+
// Preview 2
61+
set => SetProperty(() => user.Name, value);
62+
63+
// Preview 3
64+
set => SetProperty(user.Name, value, user, (u, n) => u.Name = n);
65+
}
66+
```
67+
68+
The syntax is slightly more complex, but results in a 150x speed improvement (that's not a typo), requires no memory allocations at all and no reflection, and ensures that all necessary validation of the arguments can be done at compile time too.
69+
70+
💥 If you were using `SetPropertyAndNotifyOnCompletion`, change the code as follows:
71+
72+
```csharp
73+
// Preview 2
74+
private Task<string> myTask;
75+
76+
public Task<string> MyTask
77+
{
78+
get => myTask;
79+
set => SetPropertyAndNotifyOnCompletion(ref myTask, () => myTask, value);
80+
}
81+
82+
// Preview 3
83+
private TaskNotifier<string> myTask;
84+
85+
public Task<string> MyTask
86+
{
87+
get => myTask;
88+
set => SetPropertyAndNotifyOnCompletion(ref myTask, value);
89+
}
90+
```
91+
92+
💥 If you were using the `Ioc` class, we will provide docs to illustrate how to setup a custom service container using the `Microsoft.Extensions.DependencyInjection` library soon. The temporary link with the preview docs for this is available [here](https://github.com/windows-toolkit/MVVM-Samples/blob/feature/preview2-update/docs/mvvm/Ioc.md).
93+
94+
## Notes
95+
96+
For additional info and discussion, see the related issue [here](https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3428).

0 commit comments

Comments
 (0)