Well, I'm not sure I see a whole lot of code where you use
directive="values" style of coding, especially interpolated "{{myValue}}".
95% or more of the directives I write and work with use isolate scope, for
just that separation reason. I don't want child directives doing anything
funky with my scope.
Plus, if you changed line 48 to:
<div directive-new-scope="myValue"></div>
and line 21 to:
return scope.$parent[attributes.directiveNewScope];
you'd get the behavior you wanted, albeit not really, since that wouldn't
work with (say) {{myVal + yourVal}} or something that's actually
interpolated. But I bet you could use $compile to get that feature if you
really wanted.
e
On Fri, Sep 26, 2014 at 10:48 PM, Zane Sumpter <[email protected]> wrote:
> I'm able to do the workaround, I just found this behavior bizarre,
> especially if you're writing a library. The user shouldn't have to worry
> about off limit scope variable names when using a directive. It would seem
> that using isolate scope would be the only way to make scope variable name
> clashes impossible. I submitted an issue on github for this, but it was
> closed with the reason being I asked a question. I would like more opinions
> on this behavior because I don't think this is intuitive in the least.
>
> On Saturday, September 27, 2014 12:20:16 AM UTC-5, Eric Eslinger wrote:
>>
>> I'm pretty sure that this is expected, given the protoypal inheritance of
>> child scopes from the parent. It's definitely odd now that you mention it,
>> but you can work around pretty easily by not shadowing scope variable
>> names, or by using an isolate scope.
>>
>> e
>>
>> On Fri, Sep 26, 2014 at 9:28 PM, Zane Sumpter <[email protected]> wrote:
>>
>>> A directive with a new scope is having it's element attributes evaluated
>>> with the new scope rather than the parent scope as I would expect. Using
>>> isolate scope does not have this problem and the parent scope is used to
>>> evaluate the attributes. I tested this in 1.3.0-rc.3 and went back through
>>> older versions of 1.2 and realized they all behaved this way. I am not sure
>>> whether this is a defect, or intended, but it definitely wasn't what I
>>> expected, or would want.
>>>
>>> I created a plunkr to demonstrate the issue: http://plnkr.co/edit/
>>> frk08dWVgZpXfFhqPBKy?p=preview
>>>
>>> Can anyone tell me if this is expected behavior, and if so, what's the
>>> use case for it?
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "AngularJS" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/angular.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "AngularJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/angular.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.
