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

[johnthecat]

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]

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]

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.

[Narretz]

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]

Ignore that. Sry.

[Tim91084]

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.