There's a lot of individual features that would make this easy, but instead of asking for specific features, I'll start with the actual goal.
I'm starting dust.js on nodejs, using consolidate to link it in... I plan to set the templating up from the beginning to support partial-renders and client-side renders... Seems smart!
But I have this partial-render at the top of my index.tt:
{>layout layout/}
It works great, giving me an html wrapper... but it seems it should be trivial for me to set a variable that will override this, either not rendering that partial, or rendering something like "no_layout" where it's a passthrough partial.
If I use "{layout}" instead, I'm fine as long as I make sure every runmode explicitly sets layout="layout".
If dustjs had the concept of value-defaults, I'd be fine... but I tried it, and it looks like node has to do that part (wrapping an if statement didn't seem to work, nor did an inline ||).
If dustjs let me run dustjs code conditionally, I'd be fine... but it looks like all the @if statements are about rendering.
I get that we want to keep separation of concerns, which is why I'm going to use dustjs in the first place... This to me seems like it should be a view-side concern when it will happen in the default way 99% of the time.
Here's the code I have right now (except layout.dust, which doesn't matter):
index.dust:
{>layout "{layout}"/}
{<main}
Welcome to {title}
{/main}
{/profile}
index.js:
exports.index = function(req, res){
res.render('index', { title: 'Express',layout: "layout" });
};
Like I said, it works... but it feels hacky and makes me have the controller explicitly tell the view to "render normally".
I think I will conclude that this isn't possible, and that there are so few users on dustjs that picking it because "big companies are picking it up" was a bad idea.
This is a guess, but I think the answer to this question is that nobody ever thought of this obvious situation.