Component definition API

[tgvashworth]

The same patterns crop up over and over in Flight component definitions. We could standardize these into a compressed API.

var component = define(withSpec({
   attributes: {
     someSelector: '.something'
   },
   initialize: function () {
     // ...
   }
}));
// NB: totally haven't thought this through

I think there's a generic abstraction here but I can't see it yet; attributes is a function to be called, whereas initialize is actually an after hook. Special cases are bad because they hinder extensibility later on, so it'd be best to come up with something generic that works in all cases.

[mikkotikkanen]

I presume you are talking about "another way" (more compressed) to define components? 'cos the wonderful thing about flight as it is at the moment is the simplicity and how close it ends up being just pure jQuery, meaning that it has been really easy to integrate to the team know-how - "relax, it's just jQuery".

Having too much of a proprietary structure would in my mind hinder the ability to just jump in and start using it, which in our case was one of the main reasons to start using it.

[ahume]

@mikkotikkanen I didn't quite follow the jQuery point, but I think I agree with how this hides some of the simplicity, in particular of Flight just being function composition (that I think 2.0 clarifies?).

Having said that, I think exploring patterns of component definition is a good exercise, and there might be some more generic abstraction which looks a little like what @PhUU suggests. Not sure about focusing on it for a 2.0.0 milestone though.

[mikkotikkanen]

Sorry, I was bit vague on that :P
I meant that how it looks like, it's just a set functions, much like everything else is in jQuery and/or any other object construct, meaning it's easy to approach and thus fast to get new people on board. Which was something that attracted me into flight in the first place (lean is mean :).

[tgvashworth]

Hey @mikkotikkanen. The intention is that this is just a mixin/utility that helps you with component definition and is therefore totally optional. The general thing here is just to start thinking about hiding some of the API intuition bugs in Flight.

[mikkotikkanen]

Yeah, that sounds good to me :)

[giuseppeg]

Would it make more sense to try es6 classes first (and mixins) and see how goes?

Either ways I would like to add the sugar! Let's just agree on which one we like the most.

[tgvashworth]

Threw together a quick POC of an ES6 class-based API. Main thing is that we can do mixins (tho the value of them is questionable) and static attribute definition (static analysis anyone?).

class Component {
  constructor(node, attr={}) {
    this.attr = Object.assign(Object.create(this.constructor.attributes || {}), attr);
    this.constructor.mixins.forEach(Mixin => Mixin.call(this));
  }
}

function BooperMixin() {
  this.booper = true;
}

class Button extends Component {
  static attributes = {
    onClick: () => {}
  };
  static mixins = [BooperMixin];

  /* ... */
}

new Button(document.body, {
  onClick: () => { console.log('sup!') }
})