[object DocumentFragment] in dom #148

manuel-schoebel · 2013-09-19T08:29:10Z

Hey,

i created a very basic example.

https://github.com/DerMambo/iron-router-examples

If i use {{ renderRouter }} i get the string "[object DocumentFragment]" in the body, just before the template that should be rendered.

Am i doing something wrong here?

cmather · 2013-09-20T01:02:10Z

That should be fine. I'll check the lib/client/helpers.js implementation.

cmather · 2013-09-20T01:04:04Z

I'm not exactly sure why you're getting a string in the dom. Need to look into that. But make sure you configure the router not to autoRender if you're going to render yourself. The error checking around this should probably be better. Does this work?

Router.configure({
  autoRender: false
});

manuel-schoebel · 2013-09-20T08:01:38Z

autoRender did not helper either. I updated the code in my repo, too.

tgoorden · 2013-09-26T11:47:27Z

I'm running into this issue as well. It appears this is due to the fact that Router.render() outputs a DocumentFragment. Handlebars.SafeString doesn't really know what to do with that (it expects a string of HTML instead), so it spits out [object DocumentFragment].

AutoRender doesn't have this problem, because it directly injects the DocumentFragment into the DOM (using appendChild). For this reason, I'm not sure the current approach will work very well, because the DOM is quite likely not ready when/where {{renderRouter}} is called, I'm not sure if you can append DocumentFragments "on the fly".

It seems one of two approaches would be needed:

Convert the DocumentFragment created by Router.render() into a HTML string. DomUtils (Meteor internal package) seems to do stuff like that.
Find some way of inject the DocumentFragment "in place", so in essence where the HandleBars helper is called.

(FYI, this is behavior I'm seeing on Chrome, using the dev branch. There is a chance there are some browser diffs here?)

tgoorden · 2013-09-26T12:11:26Z

As a temporary hack, this seems to work for me at the moment:

Add some kind of container to your HTML, anywhere you like really

<div id="#box"></div>

And inject the rendered router when the DOM is ready:

$(document).ready( function() { $("#box").append(Router.render()); });

At first glance, this seems to work.

tgoorden · 2013-09-26T12:25:23Z

(Sorry for experimenting semi-live here.)

My hack seems to work until you switch layoutTemplates. Then it starts to break down, probably because the relevant yields become unavailable. I guess one could re-inject the rendered route every time you navigate, but that doesn't sound like a good idea.

cmather · 2013-09-26T17:35:14Z

I have to go back and revisit to get a better understanding. Spark uses a two phased method for rendering. In the first phase, you get a string of html from each of the components. This string looks like regular html with Spark annotations around it. In the second phase - "materialization" - the annotated html is turned into a dom fragment and returned. The body of the html is automatically turned into an anonymous template. The {{renderRouter}} helper gets called from within this template, and then the template is what gets appended to the dom at the end. This is why it should work. But maybe something is interrupting that process (like a delay in Router.render). My mind is filled with other models at the moment, so if anyone has any additional hints that would be great contribution!

- Fixes #148.

cmather · 2013-10-04T16:20:14Z

Hey guys, I just pushed a fix for this. Let me know if it works for you now. The problem was that the Router's PageManager (renderLayout) method was calling Spark.render which returns a document fragment. Now renderLayout just uses Spark.isolate which will either return raw html (if not called from within Spark.render) or annotated html if called from within Spark.render.

dgtlife · 2013-10-05T11:23:03Z

I tested commit 36a155b for manual rendering with layout (just because it was mentioned in Issue #3 above), and it was an improvement, but it appears to be still broken. It ignores the layout and just renders the {{yield}} in the body.

This is how my page layout is structured, and everything works fine with 0.5.4.

<body>
  {{renderRouter}}
</body>

<template name="layout">
  <div id="wrap">
    {{> header}}
    <div id="page" class="container">
      {{> alerts}}
      {{yield}}
    </div>
  </div>
  <div id="footer" class="navbar-fixed-bottom">
    {{> footer}}
  </div>
</template>

With 36a115b, whereas before I just got [object DocumentFragment] in the body, now I just get whatever the {{yield}} template refers to, i.e. no header, no alerts, no footer, no wrap div, no container div ... as if I had this

<body>
{{yield}}
</body>

So looks like you need one more iteration. :-)

cmather · 2013-10-05T14:38:07Z

Can you show me your router config?

Sent from my iPhone

On Oct 5, 2013, at 4:23 AM, Derek Gransaull notifications@github.com wrote:

I tested commit 36a155b for manual rendering with layout (just because it was mentioned in Issue #3 above), and it was an improvement, but it appears to be still broken. It ignores the layout and just renders the {{yield}} in the body.

This is how my page layout is structured, and everything works fine with 0.5.4.
{{renderRouter}}
{{> header}}
{{> alerts}} {{yield}}

{{> footer}}
With 36a115b, whereas before I just got [object DocumentFragment] in the body, now I just get whatever the {{yield}} template refers to, i.e. no header, no alerts, no footer, as if I had this {{yield}} So looks like you need one more iteration. :-)
—
Reply to this email directly or view it on GitHub.

cmather · 2013-10-05T19:13:13Z

@dgtlife, I just tested this and it's working okay for me. Make sure you're specifying a layoutTemplate in your route or global route options.

Router.configure({
  layoutTemplate: 'layout'
});

It looks like the default layout might be getting used which just has a {{yield}} in it and nothing else.

dgtlife · 2013-10-06T00:37:55Z

This is my router config; it's been this way since I started using Iron Router.

Router.configure({
  autoRender: false,
  layout: 'layout',
  loadingTemplate: 'loading', // triggered by waitOn
  after: function () {
    Alerts.clearAll();
  }
});

And everything renders fine with 0.5.4.

I notice you have "layoutTemplate" vs my "layout". Is that a new syntax beyond 0.5.4? I'll try that syntax with dev in about an hour and see if that does it.

cmather · 2013-10-06T01:40:30Z

Yes, and no backward compat yet. Will probably add backward compat before release. You can see History.md for changes in dev with 'breaking changes' highlighted.

Sent from my iPhone

On Oct 5, 2013, at 5:37 PM, Derek Gransaull notifications@github.com wrote:

This is my router config; it's been this way since I started using Iron Router.

Router.configure({
autoRender: false,
layout: 'layout',
loadingTemplate: 'loading', // triggered by waitOn
after: function () {
Alerts.clearAll();
}
});
And everything renders fine with 0.5.4.

I notice you have "layoutTemplate" vs my "layout". Is that a new syntax beyond 0.5.4?

—
Reply to this email directly or view it on GitHub.

dgtlife · 2013-10-06T02:14:29Z

And finally, yes, using the "layoutTemplate" syntax with 36a155b works fine. Thanks for doing Iron Router, and for your responsive support.

cmather added a commit that referenced this issue Oct 4, 2013

Fix PageManager renderLayout method to not use Spark.render.

36a155b

- Fixes #148.

cmather closed this as completed Oct 4, 2013

cmather mentioned this issue Oct 4, 2013

Iron-router swallows Accounts.sendEnrollmentEmail #3

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[object DocumentFragment] in dom #148

[object DocumentFragment] in dom #148

manuel-schoebel commented Sep 19, 2013

cmather commented Sep 20, 2013

cmather commented Sep 20, 2013

manuel-schoebel commented Sep 20, 2013

tgoorden commented Sep 26, 2013

tgoorden commented Sep 26, 2013

tgoorden commented Sep 26, 2013

cmather commented Sep 26, 2013

cmather commented Oct 4, 2013

dgtlife commented Oct 5, 2013

cmather commented Oct 5, 2013

cmather commented Oct 5, 2013

dgtlife commented Oct 6, 2013

cmather commented Oct 6, 2013

dgtlife commented Oct 6, 2013

[object DocumentFragment] in dom #148

[object DocumentFragment] in dom #148

Comments

manuel-schoebel commented Sep 19, 2013

cmather commented Sep 20, 2013

cmather commented Sep 20, 2013

manuel-schoebel commented Sep 20, 2013

tgoorden commented Sep 26, 2013

tgoorden commented Sep 26, 2013

tgoorden commented Sep 26, 2013

cmather commented Sep 26, 2013

cmather commented Oct 4, 2013

dgtlife commented Oct 5, 2013

cmather commented Oct 5, 2013

cmather commented Oct 5, 2013

dgtlife commented Oct 6, 2013

cmather commented Oct 6, 2013

dgtlife commented Oct 6, 2013