cases where onPush Change Detection will not improve performance

12 views
Skip to first unread message

Nitin Jain

unread,
Jun 7, 2020, 1:30:47 PM6/7/20
to Angular and AngularJS discussion
In my Project we are not passing values from parent to child, hence not using @input bindings. Besides in each component, we are making a XHR call to get the data from the server and showing it on the screen.

Earlier all of my components were running on default change detection strategy but later we though to move them into onPush to get better performance. But before this migration, I opened my dev tools and then added the Rendering tab to enable Paint flashing to analyze the changes in both the approaches. 

To my surprise, I didn't find any difference between onPush and default strategy as Paint flashing showing the same difference.

Can i assume that if we components are not using @input bound properties for data sharing and also they are not emitting data using @output then both the change detection strategy works same?    

Nitin Gupta

unread,
Jun 7, 2020, 3:23:12 PM6/7/20
to Angular and AngularJS discussion
I researched this topic. 

The onPush strategy relies on the immutability of the objects. Under this strategy only if the object reference has changed then Angular will perform a full check for change detection otherwise the . So it depends on the service if it is emitting a new referenceType object via the observable. When you are using XMLHttpRequest (XHR) in a service then service emits events on observable. The consumers consumes events on the observable via Async pipes and re-renders the UI. 

I am assuming that rendering is working correctly, when using default strategy vs using onPush. Meaning any data changes are getting reflected in the view. The reason why you are seeing same performance behavior is perhaps the service is enforcing immutability and returning changes into the new referenceType Objects. So the change Detectors are always running a full change detection in either of the strategies.
Reply all
Reply to author
Forward
0 new messages