Support arrow functions in template syntax

@mhevery

It's not uncommon for a component to take as input a transformation function or predicate function.

For example, this PR for @angular/forms adds an @Input for a predicate function for determining if two options in a <select> are equal. Right now, this looks something like:

<select [compareWith]="equals" [(ngModel)]="selectedCountries"> ...

equals = (a: Country, b: Country) => {
   return a.id === b.id;
};

With this feature, this could be written as

<select [compareWith]="(a, b) => a.id == b.id" [(ngModel)]="selectedCountries"> ...

There are other places in Angular Material where we're looking to add similar API, e.g., datepicker with something like:

<md-datepicker [allowedDateFilter]="d => isWeekend(d)">

Or autocomplete, where the component needs to take an arbitrary value and know what string to write into the text input:

<md-autocomplete [displayWith]="value => value.getFullName()">

This would have to account for:

Functions with multiple arguments ((a, b) => a + b)
Functions with param names that already exist in the context (<my-x #x [uniq]="x => x.id">)
Functions that return an object literal (x => ({name: x}))
Invoking functions on the context (x => isActive(x)
Passing functions through a pipe (x => x.activate() | debounce)

FYI @mhevery for planning

Thought: we could support x => {name: x} (without required "()") as we won't support fn body.

In AngularJS, we used to recommend against adding too much logic in the templates. For example:

[...]
The reason behind this is core to the AngularJS philosophy that application logic should be in controllers, not the views. If you need a real conditional, loop, or to throw from a view expression, delegate to a JavaScript method instead.

Is this less of a concern in Angular now?

I know this is meant for good and being able to (a, b) => a + b or x => x.someMethod() can come very handy (and doesn't include too much logic), but I am afraid people will end up doing things more like:

[displayWith]="x =>
  haveASideEffect(x) && 
  callMyApi({lastValue: x}) && 
  doSomethingElse() && 
  x.getFullName()"

@gkalpak

@gkalpak My opinion on this one is that while we do want to discourage complex logic in the template, ultimately the template syntax exists in the first place to be a convenience and improve developer productivity. This feature makes it simple and clean to capture a somewhat common use-case, especially for functional-style programming, which is worth the fact that some people may go overboard with it.

@gkalpak

Found the issue because I needed it to have thunks in my templates.

<comp *structural="() => some.undefinedValueAtViewInit"></comp>

So I think there are valid use cases (mine may seem strange but I can assure you that it makes sense with the thing I'm working on). But I agree with @gkalpak about potential abuses. Personally, I've not been surprised when the JiT compiler blown up when I tried to use an arrow function.

But still, that would be a nice and neat feature to have for responsible developers.

As a related issue, in Material 2 Autocompleter, the displayWith function is not binded to the Component, and I was not able to access the internal variables that I require to figure out the result.

I figured out a workaround that worked, to keep my logic in the Component:

displayFn() {
    return (value: StateOption): string => {
      return !value ? '' : value.viewValue[this.lang];
    };
  }

then "inject" it into the template:

<mat-autocomplete [displayWith]="displayFn()" #states="matAutocomplete">

Without wrap the arrow function, this.lang is undefined :(

@matheo

@matheo you can use .bind(this):

component.ts

displayFn(value: StateOption): string {
    return !value ? '' : value.viewValue[this.lang];
}

component.html

<mat-autocomplete [displayWith]="displayFn.bind(this)" #states="matAutocomplete">

this is in reference to the component instance.

Still would like to see this inlined arrow feature though.

Is there any update?

Is there any way to make a workaround for this? Something like a Pipe that supports multiple parameters and returns a function?

@jelbourn

@Franki1986: as far as I could tell, there are only two ways to get this:

Going for @jelbourn syntax. The function in the component has to be declared like equals = (a: Country, b: Country) => and not function equals(a: Country, b: Country) { or you'll lose this.
Declare the function normally and then inject this with bind, just like @mtraynham said. But this feels so 2014...

Pretty please 👍 🦄 especialy the displayWith usecase sucks 🤢 Maybe Ivy can handle this?

I really hope it will never be implemented. It will lead to such an awful code which I usually see just in the JS portion, but it will also lead to performance degradation, which will be visible as a framework issue, while it will be an issue of a developer.

@jjamid

Well @jjamid, the ? operator used in my example is just to avoid errors but we can decide not to use it if we are sure the find() method will always return a value, that check can be made prior execution of my example, that's not the point of this thread and it's absolutely irrelevant. The real point of this is to allow support for arrow functions in html templates, which I'm not the only one who thinks it won't break html template philosophy and it will make definitely life easier. if my example is wrong or not, it doesn't matter, it's only illustrating the problem and it could be even illustrated with pseudo-code. Don't focus on what my code is doing and focus on what you could do instead if the arrow feature would be supported in html templates. Thanks Regards

I don't agree. Commenting on problematic code is always relvant, even if it's not related, since it's public. You cannot "avoid errors"! You're just moving the problem to the next much harder to troubleshoot step. The "?" is responsible personally for thousands of bugs that I've seen in the developers' code (and it usually makes the code extremly hard to understand when used wrong), it's because it's the exact opposite of the Guard Clause idea.

Anyway, I think too that there should be arrow support in the angular html. And not only that, also access to Enums without workarounds and basically to be excatly like .NET's amazing razor files and Web Forms before that. Eventually the html will inherit the component, it's just a matter of time. They now allow accessing protected memebers in the html.

Everything can be abused (like the "?" operator) and it's not a reason to not implement it.

Anyway, I think too that there should be arrow support in the angular html. And not only that, also access to Enums without workarounds (...)

welcome to the pros list and don't worry about my awful code :), probably you will never have to deal with it.

I'd like to make some arguments for this:

Angular templates are not currently valid HTML anyway. Structural directives, string interpolation, property and event bindings all violate HTML specs (and that's fine).
you can reduce mental overhead for developers by not having to rely on a mapping function in the typescript code (which should really be ignorant of these rendering details anyway).
you lower the learning curve for developers coming from other frameworks, particularly React.
you can deprecate ng-template and ngTemplateOutlet which are a bit obscure to most devs, and have unresolved issues around type-safety.
you could still impose restrictions on arrow functions that limit the potential abuse expressed in this thread, for example they should always return HTML, should not allow side-effects, and perhaps some other restrictions too.

Syntax proposal:

<my-select
  [renderOption]="data => (          <- Note that anything inside '(' and ')' can be parsed (as if its top-level HTML)
    @let name = data.name;           <- local variables are legal (as if its top-level HTML)
    @return <div>{{name}}</div>      <- new @return variable operator              
  )"
/>

Hey!

I know it's gonna be a bit of a bold statement😅... but as part of a potential new authoring format, I personally would like to use arrow-func for events as well. Basically something like:

<MyComponent [anInput]="mySignal()" (anEvent)="(e) => method(e)" />

<!-- short version supported as well -->
<MyComponent [anInput]="mySignal()" (anEvent)="method" />

Some reasoning:

binding arrow functions for events (typically in the form { e => method(e) }) is basically industry standard: solid, react, svelte, vue (albeit with lots of options), lit, ... I think it might be time to align (less things to learn or remember).
I assume we're all used to such notation, but IMHO it's anyway a bit strange:
- with [anInput]="..." we expect the binding to apply immediately (pass / update the value),
- but following the same idea (anEvent)="method()" should call the method right away... rather than bind the func as an event handler. 😅

I've always dismissed "as naive" the frustration on this point among the colleagues having a react background. But now that I've spent the last month working with svelte, I get the point. 😅

Just an idea for the future.
Cheers!

feat(core): support arrow functions in expressions

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.}

Navigation Menu

Repository navigation

Support arrow functions in template syntax #14129

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support arrow functions in template syntax #14129

Description

Activity

vicb commented on Jan 27, 2017

gkalpak commented on Jan 27, 2017

jelbourn commented on Jan 27, 2017

toverux commented on Oct 28, 2017

matheo commented on Dec 8, 2017

mtraynham commented on Dec 21, 2017

antontrafimovich commented on Oct 26, 2018

frankiDotNet commented on Jan 29, 2019

Guatom commented on Feb 26, 2019

gotwig commented on Mar 7, 2019

21 remaining items

BestOfTheBestSir commented on Aug 9, 2023

jjamid commented on Aug 9, 2023

LeonardoX77 commented on Aug 9, 2023

StephenSPaul commented on May 18, 2025

mauriziocescon commented on May 21, 2025

angular-automatic-lock-bot commented on Feb 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions