Mark pure pipes dirty when a signal that they read changes about angular HOT 4 OPEN

@pkozlowski-opensource

A computed would certainly work.
I think pipes are a somewhat easier way of reusing data transformation logic in templates than having to expose a computed signal inside the components.

Let's imagine that the date pipe uses a globally configured signal holding the timezone or the locale, or the preferred pattern. I prefer having to import DatePipe and be able to use {{ someObject().someDate | date }}, than having to add

formattedDate = computed(() => formatDate(someObject().someDate));

to the component.

This is even truer if the pipe is used repeatedly inside a for loop for example.

If Angular was designed from scratch around signals now, my guess is that pipes would not exist. But since they do, I think they should work in the most intuitive way, and be consistent with the rest of the framework, where a signal change causes the template to be refreshed.

TBH, I don't have a real specific use-case here. This issue came out in a question in the Angular Discord, where someone else asked whether updating a signal would cause the pipe to be reexecuted.

from angular.

While we could make this change, there is a broader question about pure pipes usefulness with signals. Our thinking was that most of the pure pipe usages would be replaced by computed. Would this work for your case? If not, could you share more about your particular scenario?

from angular.

Well, I guess what you'd really like to do is something like this: signal() | mappingFunction and all you have to do is provide a source signal and a pure function. The computed part is done for you.

from angular.

While we could make this change, there is a broader question about pure pipes usefulness with signals. Our thinking was that most of the pure pipe usages would be replaced by computed. Would this work for your case? If not, could you share more about your particular scenario?

I think this is a wrong assumption. I use a lot of pipes that have additional parameters within an ngFor. Something like this:

<ng-container *ngFor="let item of list()">
  <div>{{ otherSignal() | somePipe : item }}</div>
</ng-container>

I'm not sure how to create computes with different parameters or compute factories or something like this? I think pipes are still a very useful and helpful way to isolate certain logic and not have it repeatedly inserted into multiple components computed properties.

I also just came across this issues while we had a very strange behavior with signals.

When putting a new object into a signal with spread operators everything worked fine. But as we wanted to optimize we added an equal function to the signal which then lead to strange behaviors on signals with pipes as the pipes were only triggered once.

from angular.