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.

On Sunday, June 7, 2020 at 1:30:47 PM UTC-4, Nitin Jain wrote:
>
> 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?    
>

-- 
You received this message because you are subscribed to the Google Groups 
"Angular and AngularJS discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to angular+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/angular/a04eb1e2-d96a-4b20-a4fe-0637860739d4o%40googlegroups.com.

Reply via email to