So, I have this working, sort of. What I'm doing is using Multi-Providers
to add additional pipes to the application at bootstrap time. This is fine
because we need these pipes to be available globally.
This looks like this:
export const APPLICATION_PIPES = [
BytesPipe // This is a custom pipe.
];
export const PIPES = [
provide(PLATFORM_PIPES, { multi: true, useValue: APPLICATION_PIPES })
];
Then, in a PipeResolverServer, I load PLATFORM_PIPES and build a hashmap:
(lodash is available here)
constructor(private injector: Injector) {
this.pipes = keyBy(flattenDeep(injector.get(PLATFORM_PIPES)), 'name');
}
Now, to get a pipe by name it's a simple lookup.
HOWEVER, there's one huge caveat here that is a dealbreaker: IE has no support
for using the 'name' property of an object. So I need to figure out a better
way to get the list of pipes, by name, from the PLATFORM_PIPES injected array.
I would love to get any thoughts you have on this.
On Thursday, May 12, 2016 at 10:16:00 AM UTC-7, Aaron Smith wrote:
>
> The goal here is not to have a filter filter, or even a filter that runs
> with every change detected. Really, the goal is to employ Angular's already
> built pipes + pipe extensibility to pass data through arbitrary filter
> during metadata reference resolution. In fact, the system is designed so
> that most of the displayed data is a one time binding; the filter does not
> run more than once. Most of the time the filters employed are the ones
> included in Angular's existing pipes (lowercase, json, currency, etc).
>
> This is how this would work:
>
> <Data comes in, with metadata (i.e. "CurrencyPipe")> -> MetadataPipe ->
> Applies whatever pipes are in the metadata -> Currency Pipe -> Resolved
> data -> Resolved data is shown on UI.
>
> And sometimes we do place the MetadataPipe directly in the UI, but again
> it's sending the data through quick pure filters. So I hope this update
> helps clarify the goal, because it's not necessarily to have a "filter
> filter."
>
>
> On Wednesday, May 11, 2016 at 10:37:11 PM UTC-7, Sander Elias wrote:
>>
>> Hi Aaron,
>>
>>
>> I was about to make you a sample on how to build a pipe that does what
>> you need. However, while preparing that I did reread the (apparently quite
>> updated) pipe docs.
>> Here is a quote from the docs
>> <https://angular.io/docs/ts/latest/guide/pipes.html>:
>>
>> No FilterPipe or OrderByPipe
>>> Angular does not ship with pipes for filtering or sorting lists.
>>> Developers familiar with Angular 1 know these as filter and orderBy. There
>>> are no equivalents in Angular 2.
>>> This is not an oversight. Angular 2 is unlikely to offer such pipes
>>> because (a) they perform poorly and (b) they prevent aggressive
>>> minification.
>>> Both filter and orderBy require parameters that reference object
>>> properties. We learned earlier that such pipes must be impure
>>> <https://angular.io/docs/ts/latest/guide/pipes.html#pure-and-impure-pipes>
>>> and that Angular calls impure pipes in almost every change detection cycle.
>>> Filtering and especially sorting are expensive operations. The user
>>> experience can degrade severely for even moderate sized lists when Angular
>>> calls these pipe methods many times per second. The filter and orderBy have
>>> often been abused in Angular 1 apps, leading to complaints that Angular
>>> itself is slow. That charge is fair in the indirect sense that Angular 1
>>> prepared this performance trap by offering filter and orderBy in the first
>>> place.
>>
>>
>> If you after reading the last few paragraphs of the (linked above) docs
>> still want a filter_filter pipe, I will prepare a sample for you.
>>
>> Regards
>> Sander
>>
>>
>
--
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 https://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.
