Jump to content

Using documentFragment to model DOM


dgabrahams

Recommended Posts

Hi all,

 

I'm looking into performance, one thing was to stop accessing the DOM all the time and using document fragments to construct what I want to change and then making a single push to update the DOM.

 

I want to take this a step further and keep a constant model in memory, make changes then push every so often. I was thinking of pushing at a rate of around 60hz, and keeping the model alive in memory by making an update to the DOM every so often (60hz) using the settimeout method. The documentFaragment will be initially populated using a getElementById on either the main div or a selection of divs when the page is initially loaded.

 

Essentially this would involve creating an infinite loop (continuous settimeout updates) that will run in the background until the website is navigated away from or window closed etc. I am cautious about this approach as infinite loops are not something I like doing - is my design or approach to this problem going wrong in any way?

 

 

Many thanks in advance for any help or tips.

Edited by supasoaker
Link to comment
Share on other sites

Your document fragment is being managed by the browser in the exact same way the DOM is, so there would be no efficiency benefit. It would actually not be good to have a function running 60 times a second just to manage its own data structure.

 

It's best to just let the browser handle the document, make changes whenever you need them and that's it.

Link to comment
Share on other sites

Your document fragment is being managed by the browser in the exact same way the DOM is, so there would be no efficiency benefit. It would actually not be good to have a function running 60 times a second just to manage its own data structure.

 

It's best to just let the browser handle the document, make changes whenever you need them and that's it.

 

This is contrary to what I have been told. Apparently it is expensive to cross over into the DOM, so say I have 20 document.getElementByid lines in a row, it makes sense to put these into a fragment then update once. The issue was mostly around reflows, as each change would spark a reflow, so using fragments prevents this.

 

The fragment is static apparently and not live updated, so you can make changes then push to the DOM without causing any reflows. I was using the cloneNode method when populating a fragment (getElementByid.cloneNode) to help guarantee this...

 

I was simply thinking of moving this to the next level with a constant JavaScript model to prevent unnecessary reflows and document accesses when I want to use the model...

Edited by supasoaker
Link to comment
Share on other sites

Browsers today usually wait for multiple changes before re-rendering.

 

When it comes to DOM efficiency, each case is particular, there isn't a general solution that would solve everything.

 

If you're going to stick with the document fragment idea, there's no need to update the structure 60 times per second. Generate the document fragment the moment you're going to apply changes, do all the changes you want to do, and then append it to the document. The problem with cloning elements and re-appending them is that you'll lose theis event handlers.

 

Overall, don't worry about efficiency until you actually see problems on your website. This might be a case of preemptive optimization.

Link to comment
Share on other sites

Browsers today usually wait for multiple changes before re-rendering.

 

When it comes to DOM efficiency, each case is particular, there isn't a general solution that would solve everything.

 

If you're going to stick with the document fragment idea, there's no need to update the structure 60 times per second. Generate the document fragment the moment you're going to apply changes, do all the changes you want to do, and then append it to the document. The problem with cloning elements and re-appending them is that you'll lose theis event handlers.

 

Overall, don't worry about efficiency until you actually see problems on your website. This might be a case of preemptive optimization.

 

Thanks that was a good link. It was kind of what I was doing, I have been suffering recently! :P

 

I was using documentFragments before and performance was always ok...

 

To confirm a document fragment is static isn't it and not dynamically linked to the DOM in any way? CloneNode too is not linked to the DOM? Also, is there a way to restore event handlers?

Edited by supasoaker
Link to comment
Share on other sites

Anything you create is not linked to the DOM in any way until you use appendChild() to append it to one of the elements in the DOM. That means DocumentFragments and elements created using cloneNode as well.

 

There's only one way to restore event handlers:Every time you create an event handler, remember the path in the DOM that you used and remember what event it was. Every time the DOM is changed you need to check whether the element was removed or not and when it is put back put the event handlers back. This is probably what jQuery does with its on() and live() functions. If you really are planning on cloning, deleting and appending nodes then using jQuery to remember the events is probably easier than trying to build a whole event control system yourself.

Link to comment
Share on other sites

Anything you create is not linked to the DOM in any way until you use appendChild() to append it to one of the elements in the DOM. That means DocumentFragments and elements created using cloneNode as well.

 

There's only one way to restore event handlers:Every time you create an event handler, remember the path in the DOM that you used and remember what event it was. Every time the DOM is changed you need to check whether the element was removed or not and when it is put back put the event handlers back. This is probably what jQuery does with its on() and live() functions. If you really are planning on cloning, deleting and appending nodes then using jQuery to remember the events is probably easier than trying to build a whole event control system yourself.

 

Thanks, I know what an event handler is, but mostly I use things like 'onclick' with some JavaScript functions - I presume this will not need to be edited? What type of handlers were you referring to?

 

I like to stay close to the bone if I can, but I do need more JQuery experience...

Link to comment
Share on other sites

Event handlers that are appended as element.onclick will stay when the elements are clones, since they are properties of the element. If you used addEventListener() or attachEvent() then the events won't be cloned.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...