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

Directive: working with html fragment in documentFragment instead of direct modifying DOM #13423

Closed
johnthecat opened this issue Dec 1, 2015 · 6 comments · Fixed by #13424
Closed

Comments

@johnthecat
Copy link

I am very disappointed with the behavior of the angular when it works in a DOM tree.
It inserts and parses directives directly in the HTML, but does not use documentFragment.
Why it can't make something like this?

Directive => inserting innerHTML into documentFragment => doing usual things with it => finding inner directives => parse them => repeat, until all directives into this fragment will be resolved => insert ready-to-use fragment into real tree.

I think, that must be a flag, because some peoples uses templateUrl without caching in production, so there will be a white screen for a log time.

Thanks!

Narretz added a commit to Narretz/angular.js that referenced this issue Dec 1, 2015
… them

During parent structural animations, ongoing animations on child elements
are closed. These children are looked up by checking the data-ng-animate
attribute. If an element is the clone of an animating element,
it might have this attribute, but no animation runner associated with it,
so we need to ignore it.

Fixes angular#11992
Closes angular#13423
@Narretz
Copy link
Contributor

Narretz commented Dec 1, 2015

Sounds interesting, but I can't currently see what use case or problem would this approach solve. Can you give an example where the current behavior is not sufficient?

@johnthecat
Copy link
Author

Now i have large app on angular, and first render totally blocks page. It happens, because when directive inserting template inside element, it makes:

  • composition/repaint
  • parsing and applying bindings
  • repaint
  • parsing directives
  • composition/repaint
  • recursively, till all inner directives will resolved

And if one of the basic directive has a lot of attachments, it becomes very heavy-to-parse.

@johnthecat johnthecat changed the title Directive: working with html fragment in documentFragment, then insert in into DOM Directive: working with html fragment in documentFragment instead of direct modifying DOM Dec 2, 2015
@Narretz
Copy link
Contributor

Narretz commented Dec 2, 2015

We've seen reports about this, and in most cases it's because apps load many different templates via XHR. Have you tried caching the templates in a build-step? Does that improve the performance?

It's also not completely obvious to me that documentFragments would improve performance.

@Narretz Narretz reopened this Dec 2, 2015
@Narretz
Copy link
Contributor

Narretz commented Dec 2, 2015

Ignore that. Sry.

@Tim91084
Copy link

I'm also curious about this. I'm going to see if I can get anywhere myself, but I have the same problem.. A larger app taking a while to render. I suspect that if it was easy to do, though, the angular team would have already done it.

@Narretz
Copy link
Contributor

Narretz commented Jun 3, 2016

There's not really enough substance in this issue to keep it open. A PoC that uses documentFragment would be required to gauge the benefit of this approach. There's also the problem as of how Angular should determine when to use a documentFragment and when to parse the DOM directly. So a PR with a PoC is welcome, but otherwise this discussion isn't very fruitful.

@Narretz Narretz closed this as completed Jun 3, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants