Blaze rendering not tied to the DOM

[Gadi Cohen]

Hey David

I'm moving this to a new thread since it's quite specific and I don't want to complicate the main thread.

On Friday, September 5, 2014 9:03:12 PM UTC+3, David Greenspan wrote:

Hi Gadi, can you be more specific?  What does it mean to not render to the DOM?

I guess famous-views is probably the only example of this for now, but I can imagine there might be other use cases in the future.  Take for example this template structure:

{{#SequentialLayout}}

  {{>Surface template="t1"}}

  {{>Surface template="t2"}}

{{/SequentialLayout}}

When we "render" the SequentialLayout, famous-views adds it to the Famo.us Render Tree in memory, but it has no representation on the DOM itself.  We also use the render process to ensure any Views in the contentBlock are rendered.  The Surfaces of course do get parent elements, isolated divs we create and then hand over to Famo.us to insert in the appropriate place... but to be clear, they're never children of a "SequentialLayout" div/element (which doesn't exist in the DOM), and the SequentialLayout View doesn't add to or do anything with the DOM at all, it works with the Famous Render Tree (which is rendered to a flat DOM structure, managing positioning with matrix3d transforms).

I guess this raises some fundamental questions about Blaze as a generalized reactive template system vs a DOM-based one.  I admit that for example, I keep track of children to ensure they're all cleaned up properly, since Blaze tracks removals via the DOM.  And I implemented a {{#famousEach}} block helper which is also less tied to the DOM.

What are your thoughts? :)

Gadi

 

On Friday, September 5, 2014, Gadi Cohen <gadic...@gmail.com> wrote:

Hey, sorry, I haven't had a chance to play with the rc's yet, but I did just take a quick peak at the source :>  It seems like you're deprecating calling Blaze.Render without a parent element.  This has implications for apps/packages that use Blaze but don't render to the DOM.  Maybe famous-views is the only example for now :)

[David Greenspan]

Long-term, I'm actually pretty interested in Blaze without DOM.  With the current Blaze, I'm not sure how you're achieving it, but if what you're doing worked before 0.9.1, it should continue to work, unless you really needed the separation in time of UI.render and UI.insert.  You can give Blaze.render a div you construct to render into.

-- David

[Gadi Cohen]

Thanks for the super quick reply.  Very happy to hear about the long term :)

Yeah, it's still possible, it just seems wasteful to now be forced to create a div to be able to perform a render even when we know nothing will go into it - as is the case for all but one of the Views.  (Only the "Surface" view has content that is actually rendered into a div, all the other views are "DOM-less" and work directly on the Famous render tree.)

Most importantly, we can still publish the package :)  So this isn't excessively major from my side (it just mentally hurts to do something that has no purpose :)).  But in light of your long term vision, maybe better to loosen the DOM connection than tighten it.  Having had another look at Blaze.render, it looks like passing a parentNode of false would trigger a warning but not throw an Error or otherwise break.  Would you see this as an acceptable addition to the API as a contract by the developer saying "I'll keep track of children and ensure they are cleanly removed", and then not show the warning?  (Not sure what else we rely on the DOM for).