ftlabs/fruitmachine

Special lifecycle callbacks separated from other properties

wilsonpage opened this issue · 5 comments

wilsonpage commented

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 commented

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 commented

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

matthew-andrews commented

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

matthew-andrews commented

(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)