promise within variable is not displayed

[pasunboneleve]

trafficstars

This is similar to #140. ng-inspector displays an icon for {} (object) in the right panel (Chrome 39), but when I try to open it, it will remain blank. However, if I click on the icon, it will log the promise object in the console.

I assume at least marking the object as a promise would be desirable? The current behaviour misleads the developer into thinking the object has no defined properties, which is incorrect. It may not be convenient to mark every possible object differently, but showing that there is something there and displaying its properties would be helpful.

[rev087]

@dmvianna thanks for the report! Are you using a particular promise library, or ES6 promises? Would it be possible to set up a simple JSFiddle/Plunkr example?

We might need to come up with a general solution for specialized objects like these, but my instinct is to simply add more supported types.

[pasunboneleve]

@rev087, I get lost when using ng-inspector in Plunkr. I am using $q.

[tdhsmith]

Here's a demo using $timeout and $resource: http://plnkr.co/edit/HnhaonputTaYoV1vo8Ju?p=preview

Notice neither resource.$promise or timeout.promise can be opened, as described.

I've also noticed that unresolved resources can't be opened either (hard to show here without an artificially-slowed resource). So maybe this is more generally an issue with any object that only has $-prefixed keys?

[DrewML]

@dmvianna @tdhsmith thank you guys for the info.

I'm curious - what is the use-case that y'all are exposing promises to the scope? I know this was fairly common in the older versions of Angular (<= 1.2x) since it had built-in promise unwrapping. However, I can't think of a scenario besides the unwrapping where it would make sense to expose a promise to the scope.

To be clear, not saying in any way that the issue is invalid -- I'm just trying to gauge the likelihood that a large group of users could be having the same troubles.

[tdhsmith]

I personally don't have much use for bare promises, but I do frequently expose $resources to the view (since they still auto-unwrap, and I think it's cleaner to interpret them as models, even if it takes a bit of magic), so the fact that an empty or unresolved resource doesn't open is certainly a minor annoyance. With complex apps, I may need to check quickly if the resource is failing at the network level or if I'm not instantiating/calling it correctly, and being able to glance at the $resolved flag or, occasionally, more advanced properties is an easy solution there.

EDIT: I guess my request is a bit separate from the promise one really. I don't know if I'd personally advocate for a specific promise type or not.

[DrewML]

Sweet, thanks for the clarification @tdhsmith -- it's appreciated.

I wasn't aware of that behavior with $resource (been > 1yr since I've used it), but I did notice it in the plunker you provided above shortly after I left that last comment.

I think we're now talking about two different issues here.

1. Promises exposed on the scope do not provide any useful debugging info in the inspector panel
2. $resource (which actually returns an object or an array ref, rather than a promise¹) does not display useful debugging info in the inspector panel when it is in an unresolved state.

@tdhsmith, would you mind opening up a separate issue on 2?

¹ _{"invoking a $resource object method immediately returns an empty reference (object or array depending on isArray)"}

[tdhsmith]

Yeah I'll do that after work tonight. And I agree the two are really only superficially related in that they are about non-display of objects that happen to both involve promises.

[tdhsmith]

I kinda waited on this because I haven't been able to reproduce it lately :confused: (though there have to be some side effects with how $ properties don't trigger watch, don't there? or do you guys already have some magic going on?)