Hi,
  This problem has two aspects:

1/ Is there a need to do something that cannot be done using normal 
interceptors?
2/ Are there performance reasons why there is a need to extend the API

About 1/, unless I am missing something, there is nothing that cannot be 
done right now. It may or may not be the most elegant API, but there is 
always a balance between features and what is worth to implement and 
maintain over time.

About 2/, I am not sure that the performance implications will be that big, 
there are PR in place to make $q faster, but overall, adding a $q.defer to 
the chain (or even 10) is super fast compared to making an http request. If 
you think this is an issue, please post a plucker that shows this 
performance degradation.


Please, do not take this as if I were disregarding this idea, but there is 
a balance on what can be part of the core and what can be done and 
maintained.


Regards,
  Lucas


On Tuesday, June 10, 2014 4:54:49 PM UTC+2, Javier Mendiara Cañardo wrote:
>
> As started here:
> https://github.com/angular/angular.js/issues/7771
>
> Lucas Galsafó (@*lgalfaso) *says to apply the flag in config work-around. 
> It's how I achieve the functionality, indeed. 
>
> But this does not solve the problem: Traversing interceptors, check the 
> config flag, and return immediately when the interceptor does not apply
>
>  Consequence: As interceptors are in a promise chain, $q creates defers 
> that are resolved, without any need. This can cause a performance downgrade 
> with complex Apps Ajax-intensive with several interceptors.
>
> merging per-request interceptors with global interceptors is not complex, 
> IMHO.
>
> global-request-interceptors -> per-request-request-int -> HTTP REQUEST -> 
> per-request-response-int -> global-response-interceptors.
>
> WDYT?
>
> Regards, Javier
>
>
>  
>
>
>
>  
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

Reply via email to