$modal does not provide proper scope to templates.

[monokrome]

When using templateUrl, the resulting template will not have the same scope as the instance controller. Instead, it is in the scope as passed to the scope option on $modal.open.

This is an issue, because it means that there is effectively no method by which to get the modal's scope without resolving the modal.

[paulpflug]

Same problem here. Do you have any sort of workaround?
I want to make a Login modal but the input values are put into a childscope of the controller scope and I can't access them.

[paulpflug]

I digged a bit and found a related issue. the Modal scope is not cleaned up on close.
Only the childscope of the controller gets cleaned up.
I am still clueless what the exact problem is.

[paulpflug]

I found a way to workaround:
doesn't work:

// in controller
$scope.username = ""

// in template
<input ng-model="username"></input>

works:

// in controller
$scope.user.username = ""

// in template
<input ng-model="user.username"></input>

When using a object in ng-model, it moves up the scope-chain. The problem persists nevertheless.

[monokrome]

I had to work around it by using a nested model in the inherited scope. However, this is not ideal and I think that it's important to fix in this library when possible.

This is basically what you have done, but my use case requires maintaining a lot more login state at a higher scope than preferable.

[callado4]

This seems to be just how scopes in AngularJS work. See Understanding Scopes, especially paragraph 2 and 3.

[pkozlowski-opensource]

@callado4 is right here, you guys need to realise that there is a scope between a controller and a template created by AngularJS transclusion. While I know it might be confusing, the main issue is that transclusion is creating a new scope in the current version of AngularJS. We could think of an implementation of a modal window that doesn't use transclusion but it would have number of other problems, I'm afraid.

@monokrome @paulpflug when you understand how scopes work it is pretty easy to handle things, please send a plunk if you've got cases that that give you a headache....

[monokrome]

The issue is that the scope of the template is not provided anywhere. I understand how it works, but suggesting that the library just creates a scope which is impossible to get a reference to as an intentional design choice for a modal library is a really poor solution.

I guess the "right" solution is to create yet another controller to bind into the modal's template. That means that it requires 3 controllers to get a modal to work properly if you want to expose the ngModel values without using resolve or dismiss, so that's too bad.

[pkozlowski-opensource]

@monokrome yes, it is a design choice of both AngularJS and this library. As bad as it might sound the alternatives are even worse... Having said this you've got reference, just use $parent. But more importantly - why do you need to have access to this scope. What is the use-case you are trying to solve? Please send a plunker with your use-case, will be easier to discuss.

[chrisirhc]

@monokrome , I'm not sure what you mean. Here's a simple ngModel example: http://plnkr.co/edit/ZPoOJbVWABHrsIQMWN0y?p=preview

[paulpflug]

I think this behavior it is not design choice of AngularJS
When using ngRoute for example, this works:

$routeProvider.when "/",
      templateUrl: "main.html"
      controller: 'MainCtrl'

The given controller is directly bound to the template.
For modals however

$modal.open 
      templateUrl: "modal.html"
      controller: "ModalCtrl" 

The controller is NOT directly bound to the template.
I understand why and found a way to workaround, but that took me several hours to figure out.. as it doesn't behave like angular

beside that: closing the modal doesn't clean up all the used scopes.
For each modal two scopes persist after closing.

[monokrome]

The suggestion which is being provided here is that the separation provided by the transclude is intended by Angular. The suggestion that I'm trying to make is a higher level suggestion.

Just because transclude works this way does not mean that transclude is the proper solution when a user is being given an interface which inhibits them or provides common confusion.

I am happy to make an example use case in plunkr. Is there a specific template that is recommended for using $modal with it?

[chrisirhc]

@monokrome , see the Plunker that I've set up, you can fork that to make your Plunker.
Are you suggesting that we use something besides transclude? There's actually an implementation detail that prevents us from doing this in any other way. It's a little difficult to explain but let me try..

• When a template is linked to a scope, all the Angular expressions that it contains ({{ things }}) are added as watchers into that scope.

In a modal, we're compiling and linking the template to the scope whenever the modal is displayed. Whenever the modal is dismissed, the modal's contents (the template that was linked) gets destroyed. Hence, when the modal is opened again, it needs to be compiled and linked again. Note that when the template is destroyed, the watchers are not removed from the scope.

Thus, there is then a watcher leak on the scope. The way to get around this is to create a new child scope for any template that is going destroyed and re-created, so that the scope itself can be destroyed along with it. If we don't use transclusion or a child scope, that means that the scope that you provide needs to be destroyed along with the template. I assume that's not desirable.

Alternatively, if we do keep the template when the modal is dismissed (so that later when it's displayed, it doesn't have to be re-linked again), then we have a DOM leak. No go as well.

Also note that Angular.js has an issue talking about how transclude's sibling scope doesn't work as expected: angular/angular.js#5489

@paulpflug , scope cleanup is a separate issue that may have been already addressed on the master.

[paulpflug]

wow. thanks for that response @chrisirhc !

why we don't use the proposed workaround for the transclude?

ui.directive('box', function() {
    return {
        restrict: 'E',
        transclude: true,
        template: '<div/>',
        replace: true,
        scope: {},
        link: function(scope, element, attrs, transclude) {
            transclude(scope.$parent, function(content) {
                element.append(content);
            });
        }
    };
});