Solvedangular Misleading error message "Cannot find a differ supporting object '[object Object]'"
✔️Accepted Answer
I just ran into the same issue. I'm not sure if the recommended solution will work for my case.
I'm using an observer to pull a more complicated data structure from an external source (ie an observer on a service that persists the result of a GET request).
The part I'm trying to iterate over is a subset of the external source.
Data:
"vitae": {
{
"location": {
"address": "2445 Torrejon Pl",
"city": "San Diego",
"region": "CA",
"code": "92009",
"country": "US"
},
"social": [
{
"label": "",
"network": "GitHub",
"user": "evanplaice",
"url": "https://github.com/evanplaice"
},
{
"label": "",
"network": "Twitter",
"user": "@evanplaice",
"url": "https://twitter.com/evanplaice"
},
{
"label": "",
"network": "StackOverflow",
"user": "evanplaice",
"url": "http://stackoverflow.com/users/290340/evan-plaice"
},
{
"label": "",
"network": "HackerNews",
"user": "evanplaice",
"url": "https://news.ycombinator.com/user?id=EvanPlaice"
}
],
...
The source has more data but the point is, I want to extract the social
array and iterate over it in my template.
<ul *ngFor="#profile of vitae.social">
<li>{{ profile.network }}: <a href="{{ profile.url }}">{{ profile.user }}</a></li>
</ul>
Angular can't seem to recognize that the incoming data is nothing more than an array of objects.
To workaround, I created a hack that just creates a new array from the incoming array.
hack(val) {
return Array.from(val);
}
<ul *ngFor="#profile of hack(vitae.social)">
<li>{{ profile.network }}: <a href="{{ profile.url }}">{{ profile.user }}</a></li>
</ul>
The funny thing is, if I log the data before and after the hack it's virtually identical.
Using:
hack(val) {
console.log('Before:');
console.log(val);
val = Array.from(val);
console.log('After:');
console.log(val);
return val;
}
Other Answers:
@wardbell in your example, you're assigning a Subscription to the this.heroes property, not an Observable. Typescript should catch this, though I agree the error message could be better. The only thing we can really say is "you're not iterating over an array, you should be"?
There's a lot of mixed information going on here, let me see if I can clear it up.
First, pretty much anything that is not a primitive value (string, boolean, number) in Javascript is an Object. This includes Promises, Observables, Arrays, etc - they all are subtypes of Object.
An Iterable in javascript is, in the simplest terms, a "collection" - it's a data structure that allows iteration in an ordered manner. Arrays are the most common example of this. All arrays are iterable, but plain objects are not - importantly, the ecmascript specification does not guarantee the order of items in an Object - whereas an Array does guarantee order.
The IterableDiffer
you see in the error message is an angular mechanism that compares two collections (iterables) and returns:
- objects added to the collection
- objects removed from the collection
- objects that have changed their position in the collection
We do this to enable, for example - animations - we can tell when an item has moved from position 3 to position 0 in an array, so it can be appropriately animated:
//psuedo code!
//given two arrays:
let a = [1,2,3];
let b = [3,2,4];
iterableDiffer.create(a).diff(b) // 1 is removed, 4 is added, 2 and 3 are moved
Part of the reason (the other is performance) we don't support objects in ngFor/differs is that this mechanism doesn't work for objects - consider:
var foo = {};
foo.a = 1;
foo.b = 2;
Object.keys(foo) // [ 'a', 'b' ]
delete foo.a;
foo.a = 1;
Object.keys(foo) // [ 'b', 'a' ]
Objects have no concept of order - typically the keys are returned in insertion order (as above) - and so ngFor'ing over them doesn't make sense!
You could, of course, implement your own objectToKeys pipe, but then you run into ordering problems, and thus you have to maintain the sort order yourself somehow - there are a lot of edge cases here that might impact performance so we leave it up to the developer.
Regarding @evanplaice's example above - it's important to understand how javascript handles values and references:
//imagine you have an object of objects:
this.foos = {
a: { name: 'fooA'}
b: { name: 'fooA'}
}
//turn this into an array
this.listOfFoos = Object.keys(this.foos).map(key => this.foos[key]) // [{name: 'fooA'}, {name: 'fooB'}];
//objects are copied by reference:
this.foos.a === this.listOfFoos[0] //true -> they are the same reference
this.foos.a.name = 'fooA!'
console.log(this.listOfFoos[0]) // { name: 'fooA!' }
So simply moving an object from one structure to another does not "break" the reference - they would continue to update. See plunker: https://plnkr.co/edit/34dPSfL0bIDfGkdySExX?p=preview
The same does not hold true for primitive values:
//imagine you have an object of numbers:
this.foos = {
a: 1
b: 2
}
//turn this into an array
this.listOfFoos = Object.keys(this.foos).map(key => this.foos[key]) // [1, 2];
//values are simply copied
this.foos.a === this.listOfFoos[0] //true -> they are the same value
this.foos.a = 3 //change the value
console.log(this.listOfFoos[0]) //still 1
So with primitive values, they are "disconnected"
All of the above deals with simple synchronous values. The second round of confusion here has to do with Promises and Observables. You can deal with async values in Angular in the following ways:
By simply .then()
or .subscribe()
to a Promise or Observable, respectively, and assigning the output value:
somePromiseThatGetsAnArrayOfFoos().then(foos => {
this.foos = foos;
});
someObservableOfArrayOfBars.subscribe(bars => {
this.bars = bars;
});
To render these, you can simply ngFor over them:
<ul>
<li *ngFor="#foo of foos">{{foo.name}}</li>
</ul>
<ul>
<li *ngFor="#bar of bars">{{bar.name}}</li>
</ul>
What you cannot do here is *ngFor over a sub-property of an async delivered value - because when the view is initially rendered, the parent property is undefined.
//this.foo is undefined here!
somePromiseThatGetsAnObjectWithNestedBars().then(foo => {
// { bars: [ 1, 2, 3] }
this.foo = foo;
});
So doing
<ul>
<li *ngFor="#bar of foo.bars">{{bar}}</li>
</ul>
Will throw an error: EXCEPTION: TypeError: Cannot read property 'bars' of undefined in [foo.bars]
because foo is undefined on initial render.
This is exactly the same behavior you see in regular Javascript:
var foo;
somePromise.then(fooData => {
foo = fooData;
});
console.log(foo.bars) //Uncaught TypeError: Cannot read property 'bars' of undefined(…)
The simple fix is to use the ? operator:
<ul>
<li *ngFor="#bar of foo?.bars">{{bar}}</li>
</ul>
The other way of handing async values is to use the async
pipe:
this.foos = somePromiseThatReturnsFoos();
this.bars = someObservableOfBars;
<ul>
<li *ngFor="#foo of foos | async">{{foo.name}}</li>
</ul>
<ul>
<li *ngFor="#bar of bars | async">{{bar.name}}</li>
</ul>
Note here that we're assigning the Promise / Observable to the class, not the result of .then()
/ .subscribe()
To handle nested values, you can use the same ? operator:
<ul>
<li *ngFor="#bar of (foo | async)?.bars">{{bar}}</li>
</ul>
The same rules apply here with copy-by-value and copy-by-reference - so you could, in theory, store the returned objects in a service, return them in a promise, and two-way binding will work, as long as you maintain the references.
Summary:
- collections of things should almost always be kept in arrays if order is important.
- be sure to understand the difference between assigning an array to
this
and assigning a Promise or Observable of values tothis
- Databinding works fine as long as you aware of the semantics of javascript references.
- Don't attempt to access properties of undefined values that may be delivered at a later time.
Here's the hack (endearingly named DerpPipe
) that can be used to workaround the issue.
import { Pipe } from 'angular2/core';
/*
# Description:
Repackages an array subset as a new array.
**Reasoning:**
Angular2's change checker freaks out when you ngFor an array that's a subset
of a larger data structure.
# Usage:
``
<div *ng-for="#value of arrayOfObjects | derp"> </div>
``
*/
@Pipe({ name: 'derp' })
export class DerpPipe {
transform (value, args) {
return Array.from(value);
}
}
So, I think that still assigning an observable to this.heroes
after the refactor, is just one of those dumb things we developers sometimes run into. I don't think there's anything that Angular can help with here.
I DO agree, that this error message is very unhelpful as @wardbell pointed out. It's not clear what a differ is, it's not clear what the differ can't support. We should definitely improve this error message with something more useful.
I'm sorry for a probably uninformed comment, I'm very new to Angular 2. And I just came over this error with the code from the official Angular 2 tutorial that threw me a wonderful EXCEPTION: Cannot find a differ supporting object '[object Object]' in [heroes in AppComponent@4:16]
(!!).
...but aren't you talking about solving this at the wrong level? Should'n the actual mycrosyntax #item of items
be made "smart enough" to just be able to iterate over "almost anything" (like be smart enough to handle Array
, Promise<Array>
, Object
, Promise<Object>
etc.) automagically even at the cost of maybe increasing rendering time by even ~20% or stmh? Should a developer actually need to care what he/she is iterating over when writing a template?
EDIT+: my bad, I actually had an error in my code. But this is a very confusing error message indeed! (And I still think that ngFor
is the thing that should "behave smarter" here and try and to what "probably is the right thing" regardless of what's given to it...)
This error message gives us no clue as to what is wrong or what to do.
Repro
Misko and I experienced this while refactoring a Component from one using the async pipe to one using an array.
The async pipe version:
The refactored version:
The exception was:
Discussion
Do you see our mistake ... the one that threw the error? We didn't ... for about 5 head-scratching minutes (see below).
The developer has no idea what a "differ" is, what it is that the "differ" can't support, what might cause this, or what to do.
The "[heroes in TohComponent@4:8]" didn't help because line 4 of that component file is an import statement in the TS and nowhere near the template or the function in the transpiled JS. Something called "heroes" appears all over the place.
FWIW, I've received this error several times and I think the cause (bad list) was always the same.
Our mistake: after refactoring we were still assigning an observable to
this.heroes
.Recommended solution
Improve error message. Link to problem/solutions page?