greenkeeper[bot] on core-js-3.4.7
chore(package): update core-js … (compare)
greenkeeper[bot] on core-js-3.4.6
chore(package): update core-js … (compare)
can.Map.define
. A compute takes a property on set… compute(newVal)
. So if you unknowingly attempted to set list
to something else, like.. map.attr(‘list’, someOtherList)
, you’ll actually be passing someOtherList
to the compute, like this.. map.list(someOtherList)
, as opposed to map.list = someOtherList
. Does that make sense?
get
is meant to describe a value that is made up of other values. And since that value is dependent on other values, the get
function will only be evaluated when one of those dependent values are changed. In other words, map.attr(‘list’)
won’t call get
because none of its dependent values have changed. However, when you pass a value to the can.compute
like this.. map.attr(‘computedProp’, anotherList)
the compute re-evaluates due to the new lastSetVal
.
this.scope.dimensionList()
. That’s the incorrect way to read the value. What you should do instead is this.scope.attr(‘dimensionList’)
.
searchTermChanged: function(el, ev){
var searchTerm = el.val();
this.scope.attr('searchTerm', searchTerm);
},
’el event’: ‘handler’
Any reason why binding to a list internally would be a bad idea?
var Person = can.Map.extend({
define: {
items: {
set: function(val) {
val.bind('change', console.log);
return val;
}
}
}
});
I believe we clean up those bindings when a new “items” list is set and when the instance of person is destroyed, but can’t recall offhand #lazyweb
also, should the can.List change event be adding nested properties to the index argument?
var list = new can.List();
list.bind(‘change’, function(ev, index) {});
var foo = new can.Map({ name: ‘foo’ });
list.push(foo); //index is 0, expected
foo.attr(‘name’, ‘bar’); //index is 0.name, I would expect 0
What’s everyone’s approach to abstracting out arbitrary data from a model?
For instance, suppose a user model:
{ id: 0, name: ‘Alexis’ }
However, in the template we would also want:
{ isEditing: false }
You wouldn’t want to add that attribute directly to the model as it has no benefit being sent back to the server(just view noise).
The elegant answer is inheritable defines(I think), but I’m curious what everyone’s approach has been thus far.