You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
Current behavior
NgForOf only supports IterableDiffer.
Expected behavior
NgForOf should support KeyValueDiffer by default, making ES6 Maps easily iterable using ngFor.
What is the motivation / use case for changing the behavior?
Iteration of an ES6 Map is currently possible by caching Map.entries() every time a change is detected manually within ngDoCheck (using our own injected KeyValueDiffer), and iterating through that. The caching is required because Map.entries() returns a different value on each call, making Angular's default change detection go crazy.
While this isn't a problem that's impossible to work around, it's certainly inconvenient, and a built-in way to tackle this would be much appreciated. Then again, if you believe that this change would introduce too much complexity to a core directive, and the trade is simply not worth it, please feel free to close the issue.
The text was updated successfully, but these errors were encountered:
I'm submitting a...
Current behavior
NgForOf
only supportsIterableDiffer
.Expected behavior
NgForOf
should supportKeyValueDiffer
by default, making ES6Map
s easily iterable usingngFor
.What is the motivation / use case for changing the behavior?
Iteration of an ES6
Map
is currently possible by cachingMap.entries()
every time a change is detected manually withinngDoCheck
(using our own injectedKeyValueDiffer
), and iterating through that. The caching is required becauseMap.entries()
returns a different value on each call, making Angular's default change detection go crazy.While this isn't a problem that's impossible to work around, it's certainly inconvenient, and a built-in way to tackle this would be much appreciated. Then again, if you believe that this change would introduce too much complexity to a core directive, and the trade is simply not worth it, please feel free to close the issue.
The text was updated successfully, but these errors were encountered: