Provide a formalized mechanism with BindableObjects, so we can update the values but not trigger a handler update

[PureWeen]

Description

We're starting to see a number of scenarios where circular updates are causing performance issues.

#22347
#22413

You can see this pretty easily with any control that sends an update from platform code to xplat code.

For example, the radiobutton

• click the radiobutton
• radiobutton sets xplat value via (SetValue(IsCheckedProperty, true, specificity: SetterSpecificity.FromHandler);)
• this triggers OnPropertyChanged on the Element code

• this now propagates back down to the handler (Ideally this wouldn't happen)

Considerations

• Is there a SetValue Path we should make public to users?
• Is this something we should build into BindableObject? Shift all the code from Element.OnPropertyChanged up into BindableObject?

Related Issue

#5587

I'm curious if we can fix both of these issues with the same PR :-)

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• Shift Handler?.UpdateValue to happen after all PropertyChanged events have fired (#5587), similarity score: 0.70

Note: You can give me feedback by thumbs upping or thumbs downing this comment.