-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Remove Behaviors reference? #67
Comments
Hello michael-hawker, thank you for opening an issue with us! I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌 |
FYI @shweaver-MSFT let me know your thoughts! |
I think we settled on something like this:
I'll submit a PR with the code to make this work. |
Describe the problem this feature would solve
We currently use the Behaviors package (via the Toolkit) to ensure all properties are loaded before we initialize the Graph via our XAML Provider helpers. This is a larger dependency (and causes more issues with our dependency issue from #66) for this small benefit. We should use an alternate solution to provide the same benefit without the overhead.
Describe the solution
We should add an attached property for Page (or maybe Control/FrameworkElement) which is named something like
GraphProvider
and accepts one of our Graph Providers. This would when the property is set, look atLoaded
event for the attachedFrameworkElement
parent and at that point call ourInitialize
method on the set provider.This would allow the
Initialize
method to still have access to all the property values we need on the providers to initialize the graph components, but without the need for the full Behaviors package which we utilize no other parts from.Initialization Before
Initialization After
Other Considerations
We currently ship a WPF based package for our providers for use within XAML Islands. Not sure if we'd still want to ship a similar solution or not, we'd have to discuss. It was a bit easier before as we could leverage the same behavior code pretty easily between the two, not sure if this solution would be similar...
The text was updated successfully, but these errors were encountered: