support resolve option for directives

[ewinslow]

They have template and controller options. Seems consistent to give them a resolve option as well, just like routes, unless there's some philosophical reason for leaving them out in this case...

[IgorMinar]

We want directives to be as synchronous or as close to synchronous as possible so that we reduce user perceived flicker and jank. Delaying directive resolution would work against this goal.

[IgorMinar]

I'm closing this, please feel free to reopen if you have suggestions on how to avoid the flicker issue.

[ewinslow]

The only solutions I can come up with would immediately lead to very poor performance due to the delays in rendering (e.g., block parent directive rendering on child directive resolution). Even so, I think there are certain times where "flicker" is acceptable (e.g. late-loading comments below a blog) and would like the freedom to code my controller in a synchronous fashion even though the data is fetched asynchronously.

[arush]

This is my BIGGEST gripe with Angular. I think there should be a concept of a loading state in angular given 99% of projects are likely to need a loading state of sorts. Let people define their own templateUrl for the directive while it's in a loading state.

I'm constantly having to deal with directives that can't cope with asynchronously loading data. Even angularStrap can't deal with bs-typeahead="obj.someArray" being asynchronously loaded.

e.g.

... resolve: [...] resolveTemplate: '<div style="width:100px; height: 100px; background: url('/images/loader.gif') 50% 50% transparent no-repeat"></div>' ...

It would be wise to assume that asynchronous developers are going to want to put loading gifs in their apps. Why not make it easy? Without being natively , more Angular apps are going to look janky

[ultrawebsites]

In my humble opinion, there definitely needs to be something done to simplify handling asynchronous data and directives (it is driving me insane too) - everyone keeps on saying how DOM manipulation should be done in directives, but often DOM manipulation in directives depends on asynchronous data having been loaded first, so given this I don't understand how/why directives are designed to be 'as close to synchronous as possible'?

I am relatively new to Angular, and maybe I just need to be pointed to a good article on directives with asynchronous data, but 'setTimeout' just doesn't cut it, and from what I understand there is "no way to know for sure when a directive has finished loading" (eg. can't use viewContentLoaded), so I'm unclear how it should be handled (and it doesn't make sense to me currently either).

Whether there is a "loading state" or perhaps better still a way of knowing when a directive has finished loading, I don't know, but I'd love to know how this should be handled the 'Angular way'.

[arush]

Matt,

I agree, it is counter-intuitive.

They way we currently deal with the async loading is we always have to wrap
our directive controller/link logic in promise.then statements. Sometimes
we also need to implement $watch. This means more strain on the CPU, and
hence more 'jank' which is the exact thing we are supposed to be avoiding
with 'synchronous' directives.

It would be a simple win-win fix just to add a 'resolve' state to
directives, with a 'resolveTemplateUrl' and 'resolveTemplate'. I could
build this as a universal directive, but it seems so overkill, it should
just be native. It doesn't harm anyone who doesn't want to use it!

---

Arush Sehgal
CTO, BRANDiD
mobile: +44 7917 138 230
twitter: @arush http://www.twitter.com/arush
skype: arushsehgal

twitter: founders.getbrandid.com

BRANDiD is a Seedcamp http://www.seedcamp.com/ company

Follow us on AngelList: angel.co/brandid

The information contained in this email is intended for the named recipient
(s) only. It may also be privileged & confidential. If you are not an
intended recipient, you must not copy, distribute or take any action in
reliance upon it. No warranties or assurances are made in relation to the
safety & content of this email & any attachments, no liability is accepted
for any consequences arising from it. Please ensure you activate an up to
date virus checker prior to opening any attachments.

On Thu, Apr 25, 2013 at 2:35 AM, Matt Jensen notifications@github.comwrote:

In my humble opinion, there definitely needs to be something done to
simplify handling asynchronous data and directives (it is driving me insane
too) - everyone keeps on saying how DOM manipulation should be done in
directives, but often DOM manipulation in directives depends on
asynchronous data having been loaded first, so given this I don't
understand how/why directives are designed to be 'as close to synchronous
as possible'?

I am relatively new to Angular, and maybe I just need to be pointed to a
good article on directives with asynchronous data, but 'setTimeout' just
doesn't cut it, and from what I understand there is "no way to know for
sure when a directive has finished loading" (eg. can't use
viewContentLoaded), so I'm unclear how it should be handled (and it doesn't
make sense to me currently either).

Whether there is a "loading state" or perhaps better still a way of
knowing when a directive has finished loading, I don't know, but I'd
love to know how this should be handled the 'Angular way'.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2095#issuecomment-16984268
.

[inscapist]

it would be a great feature to have!

[georgiosd]

I agree it would be a good idea to facilitate a loading state + resolve for directives

[troygoode]

👍

[j8]

+1 Yeap, just dealing with a lot of async data and promises, resolve in directive will defiantly enhance user usability

[kbanman]

+1

[JordyMoos]

+1 here

+1. @IgorMinar, the original reason for closing doesn't seem like a complete explanation. Lots of things can cause jankiness and flickering, ng-cloak was added for that purpose, I thought.

[kuraga]

+1 for resolve option for directives