Usage of local template variables in output callbacks (for example in *ngFor)
See original GitHub issueSometimes it’s important to access not only the argument $event
, but also the local template variables in the output callback, i.e. the array element (or index) coming from *ngFor
. I propose below some solution, but I’m curious if you have any better approach or suggestions:
We could define an object for [outputs]
not in the component controller (TS), but in the template (HTML), inside *ngFor
and use there .bind
(i.e. .bind(this, element, elementIndex)
). But I have the following concerns:
- memory: creating a fresh function on each change detection 👎
- freezed order of arguments: the argument
$event
must be the last (as we can bind only local template variables, but the argument$event
can be curried laizly only as the last one (when event occurs) . It’s an issue for library authors who sometimes need to add a new optional argument to an exising public method of a component and don’t want to reorder method’s arguments for backward compatibility
Maybe you have any other concerns? Or suggestions? Thanks in advance!
Issue Analytics
- State:
- Created 4 years ago
- Comments:7 (5 by maintainers)
Top Results From Across the Web
ngFor local variable for each element - angular
I know that I can not use local variables for this, but can you think of another solution? Live example: (a) is an...
Read more >Angular: local variables of *ngFor directive
ngFor local variables : From official documentation: NgForOf provides exported values that can be aliased to local variables. Explanation in ...
Read more >Using Template Reference variables in Angular7
The answer is “Template Reference variable”. Yes, by placing a template or local reference variable over that element. Angular provides us, a ...
Read more >ngTemplateOutlet: The secret to customisation - Angular ...
ngTemplateOutlet is a powerful tool for creating customisable components. It is used by many Angular libraries to enable users to provide custom templates....
Read more >Understanding template variables
In the template, you use the hash symbol, # , to declare a template variable. The following template variable, #phone , declares a...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I think that it’s not a good idea to introduce some kind of a custom variable like
ndcEvent
for passing the$event
argument to the event handler.Rather we can just bind the template arguments first to the handler function and then make the
$event
argument always last by convention. In this way we will not have to create extra stuff in templates and just assume that event is always the last argument in the handlers used withndcArgs
pipe.So
$event
will be first and last in the handler:$event
- then it will come last to the handler:$event
- then he only receives those and may ignore last extra argument that we will pass anyways:As you may see - passing the
$event
argument as a last variable makes it easier for user to skip it and also does not introduce any extra template variables.🎉 This issue has been resolved in version 6.1.0 🎉
The release is available on:
Your semantic-release bot 📦🚀