Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ui-view initial content compiled multiple times #2315

Closed
savcha opened this issue Oct 15, 2015 · 6 comments
Closed

ui-view initial content compiled multiple times #2315

savcha opened this issue Oct 15, 2015 · 6 comments

Comments

@savcha
Copy link

savcha commented Oct 15, 2015

My expected behavior is that if a state does not declare a template then whatever markup exists in the ui-view is assumed to be the template. However, the content is removed and re-inserted multiple times which results in multiple child directive compilations. This multiple executions could be costly based on the complexity of the child directives.
http://plnkr.co/edit/31jhTIEQ4VvVsnU640zF

I've tracked this down to the ui-view directives, but I'm somewhat lost in the design. For starters why is there a need for two directives?
angular.module('ui.router.state').directive('uiView', $ViewDirective);
angular.module('ui.router.state').directive('uiView', $ViewDirectiveFill);

By their definitions It looks like $ViewDirective should run first because it has a higher priority and terminal set to true. $ViewDirectiveFill should only run after transclude function has been called, but if you set a breakpoint on both directives the compile of $ViewDirectiveFill runs first. Not sure if this is intended behavior. This might be an angular issue, but to be thorough here's a plunker showing the behavior http://plnkr.co/edit/sQfALc7uIKUsYbdNx0i8.

@WolfieWerewolf
Copy link

Hey.. I'd be keen to know this too. Is there any documentation regarding the internals of this particular pattern? I can look at the code and try to understand what it's doing but it would be helpful to know what it's supposed to be doing from a design perspective. Thanks.

@savcha
Copy link
Author

savcha commented Mar 22, 2016

As a hack I used a terminal directive to prevent initial compilation. The ViewDirective compiles the contents manually. This is implementation specific to 0.2.15.
return {
restrict: 'A',
terminal: true,
priority: -400 //priority of ui-view directive
};

@WolfieWerewolf
Copy link

Thanks for the quick reply. The user side documentation is awesome but I wondered if there was any more dev focused documentation. I'm just looking for a paragraph that explains what's happening, in what order, so I can better understand what's going on.... I appreciate that you are probably busy like the rest of us and I massively respect the value of your time. Anything you can offer, or direct me to, would be greatly appreciated. Kind Regards.

@christopherthielen
Copy link
Contributor

For starters why is there a need for two directives?

I can tell you how this came to be; the ui-view design was adopted from ngRoute's ng-view. The two directive pattern was introduced into ng-view here: angular/angular.js@f8944ef?diff=unified

Your plunk is compiling the default template three times:

  1. The initial ui-view is linked... updateView(true) calls $transclude. The "initial content" gets compiled.
  2. $stateChangeSuccess triggers a updateView(), which calls $transclude. The "initial content" gets compiled again
  3. The "Fill" directive is linked. Since the plunker's default state has no template, the initial template is $compile()d

If the state had a template, the initial content would be compiled during #1 and #2.

Sorry, I know that this doesn't fix your problem, but maybe sheds some light on what's happening.

@WolfieWerewolf
Copy link

Mate this is brilliant.. I'm not the OP but that information is absolutely helpful! Thank you so much. I will take that away and study the related pieces and leave you in peace. Again many thanks.

Kind Regards.

/W

@stale
Copy link

stale bot commented Jan 24, 2020

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs.

This does not mean that the issue is invalid. Valid issues
may be reopened.

Thank you for your contributions.

@stale stale bot added the stale label Jan 24, 2020
@stale stale bot closed this as completed Feb 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants