fix(docs): remove statement about isolated scopes and ngModelController

[cburgdorf]

It's obviously possible to use ngModelController in a directive that uses an isolated scope, so this sentence seems to be outdated.

E.g. the bootstrap datepicker does that:

https://github.com/angular-ui/bootstrap/blob/master/src/datepicker/datepicker.js#L131

[mary-poppins]

Thanks for the PR!

• Contributor signed CLA now or in the past
  • If you just signed, leave a comment here with your real name
• PR's commit messages follow the commit message format

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[cburgdorf]

My real name is "Christoph Burgdorf" and I signed the CLA before.

[btford]

Looks good. Thanks, @cburgdorf!

[petebacondarwin]

Well, while the wording is misleading the sentiment is correct. What the docs are saying is that if, inside the template of a directive that has isolated scope, you try to bind an input (using ng-model) to a value (not a property on an object) that is mapped through the isolated scope of the directive, then changes to that value inside the isolated scope will not be propagated to the outer scope.

[petebacondarwin]

So it is still an issue, that has been a gotcha for quite a few people of the last few months.

The solutions are

• not nice - always pass objects through isolated scope if they will be used with ng-model
• nasty - use $parent inside the template
• complex - set up your own manual custom watch handlers on the isolated scope to synch the value back out when it changes

How about we reword it rather than remove it?

[petebacondarwin]

The last item being the kind of solution used in the date picker.

[cburgdorf]

I see! Thanks for clarifying. It should be really reworded then. But as I'm still trying to wrap my head around it, I'm probably not the best candidate to come up with a great suggestion :)

[cburgdorf]

Ok, I think we should not only reword but also provide plunkrs with examples to the different approaches. I'm currently getting into the topic anyway so I'm willing to come up with something soon.

[petebacondarwin]

@cburgdorf - Hope you don't mind but, in that case, I'll close this PR and either you or I will open a new one with better wording.

[cburgdorf]

Sure, that's fine!

[petebacondarwin]

I had a play around with this issue and actually I don't think my comments earlier are necessarily correct.
The only problem I could come up with is the one I demonstrate in f12c61e.

[cburgdorf]

That's certainly going into the right direction. However, I still find the wording confusing. "you cannot require ngModel" sounds very strict. It's certainly possible to use ngModel with isolated scopes. It just takes some more manual wiring.

[0x-r4bbit]

@cburgdorf @petebacondarwin Just for the records, regarding your rewording, what if one does something like

scope: {
  ngModel: '='
}

This actually would fill the gap right?

[cburgdorf]

@PascalPrecht I don't really get what you mean with your comment. Should this be a possible solution to the problem? Because then I have to say that the possible workarounds a slightly more involved ;-)

But there are better tickets to discuss about the issue itself (e.g. #1924).
This one is more about how to communicate it to the people. My stand is, that we are too strict when we say

"Note that if you have a directive with an isolated scope, you cannot require ngModel"

It's like, "hey, stop working on this custom directive, it will never work together with a form." But that's actually not true. There are solutions/workarounds, we just need to point that out properly.

[0x-r4bbit]

@cburgdorf Pete described in his commit, that the model will not be updated on the outer scope, but when setting up a bi-directional data binding with ngModel: '=', the outer scope would get informed. With that combination, it would be possible to have an isolated scope, that uses ng-model and also updates to the outer scope.

Just a thought.

[cburgdorf]

@PascalPrecht Ok, I think what you meant to say was rather innerModel: =ngModel.

This seems to work fine for the example given by @petebacondarwin.

Here is a working plunkr: http://plnkr.co/edit/pUZI3f?p=preview

I was also able to use it for my custom directive where I previously used a slightly different approach but this one seems to be even easier. But I'm pretty sure there must be something we are missing. It just can't be that easy in all circumstances, otherwise what's the deal about the FUD haha ;-)

@petebacondarwin can you shed some more light on the topic?

[cburgdorf]

@PascalPrecht Or, well you can have it your way, too ;-)

http://plnkr.co/edit/Wn1qga?p=preview

So, what's the deal?

[ffesseler]

Yep , would like to know too what's wrong with innerModel: =ngModel !