These are chat archives for canjs/canjs

8th
Jun 2015
Alexis Abril
@alexisabril
Jun 08 2015 17:26

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

Alexis Abril
@alexisabril
Jun 08 2015 19:18

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

http://jsbin.com/cuqato/1/edit?js,output

Chris Gomez
@akagomez
Jun 08 2015 19:22
@alexisabril For your second example (“0.name”), that seems right to me. Since the “name” property changed on the item in the “0” index position.
Isn’t that argument called “attr”, not “index”? Context matters.
Alexis Abril
@alexisabril
Jun 08 2015 19:24
@akagomez that’s true, we do document “index” as where the change took place. perhaps my issue is with calling it “index” in the docs: “0.name” isn’t the index
Chris Gomez
@akagomez
Jun 08 2015 19:25
Yeah. Understandable. In a simple list, “attr” would look like “index”.
Alexis Abril
@alexisabril
Jun 08 2015 22:58

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.