UI DependencyProperty/AttachedProperty Property Source Generator #449
Replies: 5 comments 8 replies
-
I would recommend using event arguments over multiple parameters.
Likely because it is a PITA to create DPs, as mentioned. In some cases though there may be performance concerns over using DPs over INPC, although all I have as a reference here is 3rd party anecdotes. I currently use the linked generator and would switch to this one once provided. |
Beta Was this translation helpful? Give feedback.
-
Looks fascinating. But I wonder if there is a way to make it easier to create For example, |
Beta Was this translation helpful? Give feedback.
-
@Sergio0694 FYI, updated the original post to link to the reference docs, add a few more open questions we had discussed/thought about, and also point out some more analyzer opportunities towards encoding guidance from the docs as best-practices for common mistakes that can be made setting up DP. |
Beta Was this translation helpful? Give feedback.
-
As we plan to create a bunch of custom controls in the future, we introduced our own source gen for DP (hopefully AP too) when we introduced our own first custom control. Generated code sample: public static readonly global::System.Windows.DependencyProperty IsToggledProperty =
global::System.Windows.DependencyProperty.Register(
nameof(IsToggled),
typeof(bool),
typeof(global::Files.App.Controls.ThemedIcon),
new global::Microsoft.UI.Xaml.PropertyMetadata(
(bool)true,
(d, e) => ((global::Files.App.Controls.ThemedIcon)d).OnIsToggledPropertyChanged(
(bool)e.OldValue,
(bool)e.NewValue));
public bool IsToggled
{
get => (bool)GetValue(IsToggledProperty);
set => SetValue(IsToggledProperty, value);
} Let me know what you guys think 🤔 |
Beta Was this translation helpful? Give feedback.
-
Opened #621 for tracking. Thanks everyone for the input! 🙂 |
Beta Was this translation helpful? Give feedback.
-
Preface
This topic comes up a lot and wanted to centralize the current thoughts and proposals around it for what we want to see in the Toolkit in the future.
First off, we're waiting on support in C# for partial properties; so, until that is implemented in C#, we don't have plans to do anything in this space. Please up-vote/react to that issue in the meantime.
Also, in the meantime, feel free to look at alternatives.
Props to @Sergio0694 for working with me discussing these and iterating on our ideas and proposals for the below.
Problem
Writing properties for UI code is cumbersome, clunky, and error-prone with many pieces that need to be aligned by type, class names, and/or 'mystically' named in order to work properly (e.g. including
Property
at the end).It'd be great instead, if we could leverage the power of source generators to perform this heavy lifting for us. And also gain the benefit of analyzers to ensure we set them up with proper names, semantics, types, etc... (more below)
DependencyProperty
For instance, with a Dependency Property, go from this:
API Proposal
Super simple! 🎉
Open Questions
oldValue
andnewValue
instead of the event args? (though, for the above question of sharing a method it would need the DP value too)AttachedProperty
The boilerplate for AttachedProperty is even worse:
However, since Attached Properties don't actually have a public property (it's defined as a public field)... a similar approach won't work here.
Implementation to Avoid
Ideally, we want to still avoid attaching an attribute to the class and using a string like so:
This has many drawbacks:
API Proposal
Instead, let's hook into some part of the code we already have to write instead:
This provides both the attachable type and the type of the 'property' in the signature, and provides a natural place to place the xmldoc. The setter and field definition would be generated along with the implementation for the partial getter method. And the callback would be optionally registered, if defined.
Open Questions
SetMyProperty
method instead in case that documentation makes more sense for a scenario? As long as both aren't defined...partial properties
for this Attached Property syntax to work, but they're not as common as Dependency Properties, so it seems better to wait and work on them together at the same time.Analyzers
With source generators, generally extra Roslyn analyzers are written to ensure proper usage and aid developers in implementing proper patterns.
To that end, we should provide some of the following checks around these new generators:
Property
(AP: Starting with 'Get')DependencyObject
inheritor (this also coversDependencyObjectCollection
as it inherits from DO)On_PropertyChanged
name and vice-versa (is there a partial method with the right types, but the name doesn't match a defined property we see)DependencyObject
DependencyProperty
on UI classes (inheriting fromControl
) instead ofINotifyPropertyChanged
... (see this 'mistake' a lot) - imagine we can detect a regular property that has a call toPropertyChanged
? At minimum if we detect theINotifyPropertyChanged
interface on a control class, we can call that out...These would all help ensure proper usages of the properties in the proper places and aid developers in using different features (like the callback) with less room for error.
References
Beta Was this translation helpful? Give feedback.
All reactions