Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

Scope inheritance issue with isolating scopes (regarding $parent, not the prototypal inheritance) #12059

Open
NicBright opened this issue Jun 9, 2015 · 4 comments

Comments

@NicBright
Copy link

Hi there,

I'm not exactly sure whether this is intended behaviour or not. At least for me it looks odd.
The thing is, that an isolated scope of a directive that has only an isolated scope (and no template/templateUrl and no transclusion defined) is not considered as a $parent for child scopes inside that element. This makes it impossible to $broadcast down events (or $emit them up to this particular isolated scope), as the child scopes will not be able to register their listeners with that isolated scope (as it cannot be reached through the $parent lookup chain).

Here is a CodePen that illustrates this issue. It first starts with a working example and has further instructions inside how to quickly change it into the described scenario. It uses two simple directives, one of them does only ask for an isolated scope, and the other additionally uses a templateUrl and a transclude: true option. They both use exactly the same linking function which makes it easy to verify that they really only differ in their ddo.

http://codepen.io/NicBright/full/RPVvao/

What do you think? Is this a bug or intended behaviour? If it's the latter, why make a difference here? I do understand that the scope is semantically "isolated", which one could justify in one's head to refer to being isolated from events as well. What bothers me particularly here is, that the behaviour is inconsistent depending on other properties on the ddo.

Regards,
Nicolas

@lgalfaso
Copy link
Contributor

The reason is that when directive that asks for a new scope but does not have a template, then the scope will be a sibling of the base new scopes created within the child elements where that directive is.

If this is a bug or not, it is hard to say and would like other contributors to comment.

@Narretz
Copy link
Contributor

Narretz commented Aug 23, 2015

It's confusing and makes sense at the same time. Making the isolated directive's scope a parent of it's children scope would imo create an exception to the rule. I also would be interested why you'd want an isolate scope without a template. The current technique doesn't really make sense to me, as the children of the directive are not isolated anyway.

@NicBright
Copy link
Author

Making the isolated directive's scope a parent of it's children scope would imo create an exception to the rule.

What rule do you mean? The isolated scope usually already is a parent of the scopes of its contained (and transcluded) children.

About the use-case:

Consider an <overlay> directive which just wraps the contents of stuff that one wants to display relative to other elements. For this use-case I use a 3rd party library, namely Drop. In this case, I do not need to use a template and thus I do not need to transclude the contents (which one only needs to do if one uses a template). I do however add a lot of stuff inside the isolated scope of <overlay> (that's why I want to keep it isolated) to manage the state of the overlay (e.g. whether it's open or not), i.e. to be able to correctly talk to the Drop api. To be able to nest <overlay>'s I wanted to use Angular events ($emit / $broadcast) which brought up this issue.

To summarize:

This is not a critical bug (I ended up defining transclusion after all, and adding a dummy template ("<ng-transclude></ng-transclude>"). The behaviour described by this issue is just very confusing and counter-intuitive. Imo, scopes should try (regarding the $parent lookup chain) to mimic the DOM hierarchy as closely as possible in order to allow for easy event propagation (concerning $emit / $broadcast). It is much easier for a developer if he can rely on that regardless of how the ddo looks like.

@gkalpak
Copy link
Member

gkalpak commented Jun 8, 2016

I'm not sure why, but iirc there was a commit that explicitly changed the behavior to what it is today (and it was quite some time ago). So, I suspect there are specific reasons behind this behavior (although I can't tell what they are) 😁

@gkalpak gkalpak modified the milestones: Ice Box, Purgatory Jun 8, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants