Using `init` on `DefineMap`

CanJS
1

I’m trying to make use of the init function on a DefineMap:

The output seems to do something weird with the input to the new Map(). You’ll see that the input argument is split into the individual characters in the console.

What am I missing/doing wrong here?

2

so setup is called before init on any can.Construct.

Something like this should work:

var Map = can.DefineMap.extend(  {
  name: {
    type: 'string'
  },
  setup: function(name){
    console.log("name",name);
    return can.DefineMap.prototype.setup.call(this,{name: name})
  },
  init: function(){
    debugger;
  }
});


var map = new Map('test');

console.log(map.name)

But DefineMap is overwriting setup during extend for performance reasons. It should be handling a user provided setup.

Is there a reason you’re not calling new Map({name: "test"})?

3

In my scenario I have an options type of structure that would be called using an object such as new Map({arg1: 'value-1'}). Was just trying to use a string as a shorthand for one of the options.

But not much of a worry always sending in the object.

By the looks of it then passing in a string is going to handle that string as an object which is why the characters are teased out.

4

To make this possible, DefineMap’s static setup (which gets called during .extend) would need to make sure that when it overwrites the prototype setup here:

https://github.com/canjs/can-define/blob/master/map/map.js#L78

this.prototype.setup = function(props){

That this calls any setup function the prototype was extended with.

5

I guess it might be worth the effort if you get more requests to do something like this; else maybe a warning when not passing in an object?

Anyway, I’ll go with the object for now so no worries from my end. Somehow I thought that the DefineMap worked that way and perhaps an older version did :slight_smile:

6

An older one might have. Changing setup the way it works now improves performance.