This requires some design that needs @mhevery. E.g. we can't use reflection in an ad hoc way as this won't work in Dart.

So first I checked Angular.dart and filter/orderBy pipes are broken as far as static reflection analysis goes. Technically it is clear that as long as something like myList | orderBy:someContextVar is desired, no static analysis can generate the proper getters for the field that is known only at runtime. In other words for maintaining this syntax, dev should manually indicate these reflective fields with type annotation or similar.

In practice though no bug is filed against angular.dart for this broken behavior and the reason could be that the getter is very likely to be generated for some other reason. For example if you're sorting a table this way, you most likely will display the sorted column or otherwise the data would look random.
In summary the solutions are:

• Using type annotations for getters that are not statically detectable (dart only).
• Not supporting these pipes. (dart or both)
• Not supporting the syntax that requires reflection i.e. orderBy would only take Function | Function[]. Although I think this will ruin the whole point of these pipes. (dart or both)

That said at the core of this problem I would blame Dart's haphazard mirrors lib which makes it virtually unusable in production. If dart has to be compiled to js for production, simple reflection like accessing getters/setters should be just as easy as it is in javascript and while the performance would remain at same level as pure js, a few more kilobytes could be saved from final output.

@mhevery What should we do with this pipe? Just support it in JS?

Yes, JS only

PR is updated.

Let's not do this as part of angular core, as it won't work with the precompiled templates that we are about to do. Please feel free to publish this as a standalone directive.

From the user perspective, if orderBy is not working with precompiled templates – that is the problem with template compilation, and not orderBy. I can not imagine a single angular codebase today without orderBy.

Is my understanding correct that ng2 will not include orderBy by default? If so, most users will be quite alienated by this decision.

@tbosch Can you clarify your thoughts about not doing the orderby pipe in angular core. If this was done as a standalone pipe in common/pipes would that be acceptable?

Also, @tbosch and @mhevery what are your thoughts on orderby implemented as a pure pipe? It seems that a non-pure orderby pipe would perform poorly, but a pure version could be confusing if a developer didn't understand that the pipe is pure. Would we need pure and non-pure versions of the pipe (appropriately named to self-document what they are -- orderByPure and orderByImpure) or just make it a pure pipe and let it be discovered how it is intended to be used? Thoughts?

The issue with orderdBy is that it relies on reflection. This means that it will be broken when you run your code through a minifier. AngularJS did not work with minification, but with Angular 2's goal is to work with minifiers. In general we have been staying away from things which would break minification. Implementing orderBy is easy and can be done by our community as a stand alone library.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}