Polymer SPA and DOM size

[cjc]

I'm building a a SPA with polymer that contains multiple pages, each page may consist of a large number of controls.  I've was using the core-pages control for this (as recommended: https://github.com/ebidel/polymer-change/blob/master/demos/spa.html) but I'm aware that the DOM tree may become quite large.  So instead I started to write my own polymer tab control that removes the non-visible pages from the DOM and switches the pages in/out when necessary.  

My control can be defined something like this:

<tab-control>

            <page-one Title="Page One"></page-one>

    <page-two Title="Page Two"></page-two>

</tab-control>

To acheive the desired result my element's script removes the pages from the light DOM and inserts only the selected page into the shadow DOM upon selection change of some paper-tabs.  However, when I do this the databinding in the child page does not work.

Questions:

1. Can the databinding work in this scenario, is there something I can do to kick it into life again?

2. Is this a valid approach when creating a SPA and trying to reduce the overall DOM size and if not can someone point me to a better pattern?

Many thanks!

[Scott Miles]

I recognize that I haven't answered your question, but I want to probe a specific part of your motivation, in particular: "I'm aware that the DOM tree may become quite large". My suggestion is that this fact by itself doesn't matter. DOM itself is relatively cheap.

If you have a problem with memory pressure, which is to say, "on platform X (e.g. mobile!) my pages uses Xmb of RAM and it's too much", this is more specifically actionable. Or ff there is a problem with rendering speed or startup time, these are also actionable, but possibly with different solutions.

Do you have one of these specific problems (or another one I didn't mention)?

Scott

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/fa387242-e47c-4304-ae29-30819733a404%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[cjc]

Hi Scott,

Thanks for reply.  It's the latter.  I take your point about DOM size so I should have said "performance".  If I extend my example a little:

<tab-control>

            <page-one Title="Page One" someAttrib="{{attribValue}}"></page-one>

    <page-two Title="Page Two" someAttrib="{{attribValue}}"></page-two>

</tab-control>

Each page has a number of child controls which will update their views when attribValue changes (these will include D3/SVG and threejs charts).  If page one is visible I don't want the controls in page two reacting in any way (trying to maintain that 60fps!).  I realise I can implement an events or interface framework between my polymer elements to simply skip over the rendering when the page isn't visible, but to truly guarantee these controls are disabled (and not have to rely on the control developers to ensure this) I figured it would be better to just remove them from DOM.

Thanks again,

Chris.