I noticed that this event fires 2x for every property that gets updated. So if you have a control that has 10 properties That's 20 event fires for that update. This is detrimental to performance due to all the unnecessary renders. It should only fire once for every getOutputs return.
Or is there an architectural reason for this? I can confirm this behavior in the pcf playground, I haven't checked it in live environment.
Hey Diana, I agree on having a "need" of such design pattern. But unfortunately, not much mentioned in the documentation regarding "updatedProperties" for conditional rendering. I stumbled upon it quite late after spending some time scratching my head in disbelief 😄
Hi @Pourush ,
Calling updateView after notifyOutputChanges is by design; the Framework Runtime decides if the value can be accepted, and calls the updateView again with the newValue (if accepted) or the old value otherwise (maybe there are validation rules, onChange events on the form which doesn't accept changes, errors...).
Have a look at this learning resource for more details: https://learn.microsoft.com/en-us/training/modules/get-started-power-apps-component-framework/architecture?WT.mc_id=DX-MVP-5004107
I have a blog about optimizing rendering with React (React.memo for functional components or React.PureComponent and shouldComponentUpdate for class components). If the props are not changed, React won't render...
Maybe it helps: https://dianabirkelbach.wordpress.com/2022/05/06/updateview-in-virtual-pcf-components-and-how-to-optimize-rendering/
Many years gone by, still same behavior as mentioned by author - mostly seems by design.
In nutshell: If you try to send the latest updates to an "output" property (notifyOutputChanged), you will end up trigging updateView. Which is counter productive in many usecases, as it will update the states from old props.
Workaround: I used a circuit breaker in this case, render only your child components (tsx) in case update is done in respective "input" property --> context.updatedProperties.indexOf("InputParam") > -1.
This Worked, but i hope we could have a more sustainable solution that this.
jolake
Are you also aware of the issue with the test harness crashing when you are returning a property value other than a string?
Any idea when this will be fixed? Internal bug sounds like ... 'never' too me 🙂
This is a known issue that only occurs in our test harness, and should not reproduce in a live environment. We are tracking the issue with an internal bug.
This is what I did for my component.
https://github.com/rexkenley/d365AddressBox/blob/master/AddressBox/index.ts
Essentially the equivalent function is used to block any calls if all of the internal copy of the parameters matches the current parameters. There is no need to re-render something that the component already has.
I'm seeing the same behavior... any suggestions from the crowd?
WarrenBelz
87
Most Valuable Professional
mmbr1606
71
Super User 2025 Season 1
Michael E. Gernaey
65
Super User 2025 Season 1