[discussion] dust.renderTo

[sethkinast]

@jimmyhchan would like a function called dust.renderTo:

dust.renderTo = function(tmpl, ctx, el){}

[prashn64]

I don't like it much and seems to be an request out of needing to statically analyze rather than a reasonable feature.

There are a few things to consider though:

1. While we are supposed to be agnostic of what we actually output, the percentage of people using Dust as an HTML outputter is likely very high.
2. It's backwards compatible. You don't have to use the function if you don't need it.
3. We could just break it out into it's own module, so that people that don't want to use HTML specific functions don't get the extra weight.

[sethkinast]

If it's its own module that's effectively a monkeypatch.

I think that it doesn't seem that useful because it's basically just sugar for one possible usecase, and it doesn't even work on the server like the rest of Dust.

[smfoote]

I actually like the idea of a renderTo method. Though it is just sugar, I think it's really nice sugar.

dust.renderTo(tmpl, ctx, el).then(() => attachEventListeners);

That would be pretty cool.

[jimmyhchan]

Use cases:

• DRYing Sugar: developers repeat the callback block often.
• an abstracted (centralized) method to attachHTML so that it can be tweaked by the environment: e.g. use innerHTML vs $.html vs other fanciness
• Not thinking in strings makes it safer and more forward facing towards tornado where we start expecting DOM nodes instead of strings

Issues:

• IE8 innerHTML needs the html5shiv

TODO: flush this out better

[sethkinast]

@smfoote Dust won't support Promises like that for quite a long time.

Although that means that renderTo probably needs a callback arg too, gross.

@jimmyhchan html5shiv is the implementor's problem, not Dust's.

[smfoote]

I know it won't, but it would be pretty great.

[sethkinast]

What about chaining, so I do the render as normal and then "pipe" it somewhere?

Keep the existing dust.render semantics as is, and add:

dust.render(tmpl, ctx, function(err, out) { ... optional ...}).toElement('#foo');

[smfoote]

That seems reasonable