New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accessing parent scope #399
Comments
This is not in |
I agree there's often need to access things in the parent scope. My pragmatic approach has always been to avoid ambiguous property names. That has worked for a long time for me, although it often results in strange objects. On the other hand, speaking of experience with handlebars; having this ability might tempt people creating crazy tangled parent scope resolution: |
It's true that using "../" could lead to unreadability. But in the other way using caml to resolve parent can not be achieve as you can have caml in local scope. Morever, defining a keyword to access parent would not respect Mustache philosophy I think. speaking frankly I could not come to a simpler and better idea than using the the directory representation. |
Yeah, avoiding ambiguous property names also leads to more readable/verbose templates. But I understand why some people would like this feature. What about writing a separate package that modifies the inner workings of |
To be honest, I don't really see this happening unless via a plugin, or a pragma. And a plugin API doesn't seem to be the priority right now. |
I've been thinking a bit more about this... I believe Mustache's philosophy is not to pass in data as-is to the renderer, but to 'prepare' it into a view beforehand. You'd then have a It's also easier to read and maintain templates that have more verbose variables: {{ id }}
{{#children}}
{{children.id}}
{{id}}
{{/children}} Before vs After {{ nodeId }}
{{#children}}
{{ nodeId }}
{{ parentId }}
{{/children}} (sorry to summon you @bobthecow, but I always appreciate your mustache wisdom 😄) |
you can already go up, so all ones needs to do to fix the problem shown with the first template is to wrap the data with a temp object |
feels much like a patchy work-around. It also works only with simplistic 2-levels model where you can solve by an envelope wrap for the outer layer. But what if the model is deeper? that feels juggling. Often I need to bind a model I get from lower data layers, and my job is to present it - in whatever form I got it from the infra. The proposition here is that I have to convert the model recursively all way deep to a presentable state - what would be considered here IMHO, I think the tool should leave the choice to the user, rather than imposing opinionated rules |
For readers, example of what @rndme is suggesting: const Mustache = require('mustache')
var view = {
node: {
id: 5,
children: [ { id: 6 }, { id: 7 } ]
}
}
const template = `
{{#node}}
children:
{{#children}}
id: {{ id }}
parentId: {{ node.id }}
{{/children}}
{{/node}}
`
const output = Mustache.render(template, view)
console.log(output)
Using the following template doesn't work as of const template = `
children:
{{#node.children}}
id: {{ id }}
parentId: {{ node.id }}
{{/node.children}}
` |
Afaik, Mustache philosophy has always been that you generate a view that is passed to the template – you don't pass the model directly. @osher Can you show us an example that you cannot easily work out with the tip/trick mentioned above? |
I'll try to provide snippets later, but basically - with 3 levels nesting it won't work because you cannot wrap the middle-level - you have to transmute the source to a processed view. Take for example a swagger document, where you have root level, path level, verb level (and there's more but lets stop here). Each level can specify a custom directive - Suppose you want to generate HTML docs from this swagger document. Next. Not classical HTML generation - yea. but who said that mustache is only for HTML? it's a templating engine, and code generation is commonly implemented using such template engines ;)
that should be a user's choice, not a limitation / restriction |
I'll give you one more example, and I'll try to do it without betraying secret sauce. Assume a tree data-structure describing assets owned by a player in a strategy game. Each level may provide modifier bonus - for example - or attack bonus, defense bonus, health bonus, etc. I'll add difficulty: Sometimes armies are allocated in Alliance-level task force. I solved it with what mustache will call partials, only that I did not use mustache... |
@osher said:
There's no doubt mustache has opinions. It's "logic less templates" philosophy puts lots of restriction on the templates, that fact often requires data/model preparation before giving it to the template for rendering. If this doesn't suite your needs, there are alternatives which may be better, such as handlebars or even lodash.template just to name a few |
Right. I completely forgot about handlebars. Lets lose users to handlebars. |
I'm pretty sure @osher was being sarcastic when he said "That's an acceptable design decision.", but this topic has been abandoned since 2016. What's going on? It seems like this question is being avoided in this JavaScript repository as well as in the main repository: I for one think that being able to reference the parent scope is logic-less and shouldn't interfere with the mustache ideals. I like the idea of always being able to access the root scope with a symbol, like a leading "../":
I would want this to render "x2x1x2" but it omits the last one because that's not how it works. Perhaps Mustache could just try to stay compatible with handlebars and use the |
AFAIK, handlebars is JS only, while mustache uses the same syntax across many environs, PHP for example. If you want to change mustache syntax, you would need to convince all other non-js implementations to do the same; a tall order. Furthermore, in modifying the JS code, I found it problematic to go up "one level", though I added a way to go back to root in my fork, which was pretty simple to implement... |
Anything on this? |
There also needs to be documentation and style recommendation for situations where dot notation is optional.
More details here: https://stackoverflow.com/q/62166467/5637701 |
Accessing parent scope
Considering :
And following template :
As it is, you sometimes have to access parent property (in a nested node model for exemple).
It can be easily implemented like using "../" to get parent scope
Ex :
To achieve that :
The text was updated successfully, but these errors were encountered: