Mustache binding doesn't work when starting with an underscore

[Poplar-hills]

It seems that Vue.js cannot properly parse mustache bindings start with an underscore like: {{_type}}. It works fine with Handlebars.js

Could you please add support to this kind of binding?

demo: http://jsfiddle.net/maxjiang23326/oc0y33Lx/

[multimeric]

That isn't a bug with Vue, it's an intentional feature. From the guide (at the bottom of that section):

Under the hood, Vue.js attaches a hidden property ob and recursively converts the object’s enumerable properties into getters and setters to enable dependency collection. Properties with keys that starts with $ or _ are skipped.

What this means is that your _type wasn't proxied onto hits[0], but it's still attached to the $data field, so can be accessed as hits[0].$data._type. Here's a fiddle.

This is however just a workaround. The idea is that if you've started your variable with an underscore, it's probably a private variable, and so you probably shouldn't be binding the DOM to it. if you're stuck with that data structure, the workaround is fine, but if you can change it, why not remove the underscore since type isn't private anyway?

[Poplar-hills]

Thanks a lot!

[Poplar-hills]

Here's another case in which I cannot access '$index', '$key' and '$value' when adding of deleting a property whoes key starts with an underscore. Is there any workaround for this case?

Here's a fiddle: http://jsfiddle.net/maxjiang23326/ysd6Laco/1/

Thanks in advance.

[multimeric]

Hmm I'm not sure why that behaviour is happening. It might actually be a bug. But I think you're making things difficult for yourself in using underscores for properties you're trying to bind to.

[Poplar-hills]

Actually, using underscores is really not my choice. The data structure is not defined by me and I've found no easy way to change it.

In addition, I've found another wired behaviour - if I add another normal property along with adding the property with underscore, it works!

Here's the fiddle: http://jsfiddle.net/ysd6Laco/2/

[agonbina]

Properties with _ or $ is are not observed for changes and you should use them to store static data that does not change over time. If you need to change the data structure you can do so on the create or beforeCompile hook:

var data = { _id: 123 }

new Vue({
  created: function() {
    this.$set('id', data._id)
  }
})

Also you should probably keep a reference to the view model instance after it is created and then $set or $add properties to it instead of manipulating the data object like in the jsfiddle you provided above.

[davidkhess]

@yyx990803 – I'm running into an issue with nested data that contains attributes beginning with _. Preventing observation of properties beginning with _ and $ makes a lot of sense on View Models but when it applies to nested data that could come from any number of different REST APIs, it starts to be a bit restrictive.

Would it be possible to relax this restriction to where the existing rule applies to View Models but for simple nested data only properties beginning with $ and the ob property itself are ignored?

[yyx990803]

@davidkhess They are skipped for observation and proxying, but you can still access them in templates as $data._property.

[davidkhess]

@yyx990803, yes, but if they are skipped for observation then you can't bind to them and expect the UI to update when they are mutated.

For instance, let's say I GET a resource via a REST api and store the result in $data.response. Let's also assume that this REST api response happens to contain something like a _related property which is a list of topics and I bind that to a select that allows multiple selection and I render it to the page as a bullet list. If I change the value of _related using the select, the bullet list will never update.

This seems to be a bit of a landmine for people working with APIs that happen to use "_" in property names of REST resources.

It seems a reasonable rule on Vue objects but less reasonable to apply it to all nested data below it – the naming of which the developer may have no control over.

[yyx990803]

@davidkhess fair enough, sounds like it'd be a good idea to observe them while just skip proxying them at root level.

[davidkhess]

@yyx990803 That sounds like a great solution.

[akralj]

+1. I run into the same problem when binding to images which come from couchdb and are stored under _attachements in couchdb. So it would be great if i could just observe them under say objekt._attachments. Right now I copy them into an extra $data.attachments property.
Thanks a lot, if you can change the behaviour :)