Special lifecycle callbacks separated from other properties

[wilsonpage]

As inspired by x-tags the clear separation of lifecycle callbacks and other custom properties.

var Apple = fm.define({
  name: 'apple',
  template: template,
  lifecycle: {
    initialize: function() {},
    setup: function() {},
    teardown: function() {},
    destroy: function() {}
  },
  myAppleMethod: function() {}
});

or possible reverting to old style:

var Apple = fm.define({
  name: 'apple',
  template: template,
  onInitialize: function() {},
  onSetup: function() {},
  onTeardown: function() {},
  onDestroy: function() {}
  myAppleMethod: function() {}
});

or titled callbacks:

var Apple = fm.define({
  name: 'apple',
  template: template,
  callbacks: {
    initialize: function() {},
    setup: function() {},
    teardown: function() {},
    destroy: function() {}
  },
  myAppleMethod: function() {}
});

[matthew-andrews]

I think you mean (JS object not function)

lifecycle: {
  initialize: function() {},
  setup: function() {},
  teardown: function() {},
  destroy: function() {}
}

Would it be worth considering renaming them to be x-tagsy too?
initialize => created
setup => inserted
teardown => removed
destroyed left as is

This would require some amendments deeper down in fruitmachine to make fruitmachine objects' lifecycles more in tune with the web component spec. I feel that could be a good thing.

[matthew-andrews]

(Basically leave it up to fruitmachine to intelligently call setup and teardown)

[matthew-andrews]

(In order to mitigate the migration pain we could provide an global fruitmachine option to switch auto-setup on and off)

[matthew-andrews]

(Or we could just implement it and make the setup() / teardown() methods on module API do nothing and remove them from the codebase as a second step)

[matthew-andrews]

Can we change tag to extends as well?
http://www.x-tags.org/#custom-tag-registration-extends