component should setup bindings only "afterPreviousEvents" ~8

[justinbmeyer]

From: canjs/canjs#1591

It's possible that events are dispatched that represent changes a component's init function already knows about.

Putting this another way, in the following code:

init: function(){ 
  // draw out DOM
},
"{scope} change": function(){
  // update DOM
}

It's possible that "{scope} change" will be fired after init, but it represents a change that init already knew about.

With 2.2.3, you can work around this like:

init: function(){ 
  can.batch.afterPreviousEvents(() => {
    // draw out DOM
    this.ready = true;
  })

},
"{scope} change": function(){
  if(this.ready = true) {
    // update DOM
  }
}

Instead, can.Component could only attach bindings "afterPreviousEvents" from the perspective of init.

[rjgotten]

@justinbmeyer
Would be nice if there was a way to bind against a Map property or a compute with a templated event binding that would signal Component and Control to also execute the handler at the moment of binding, in addition to the normal behavior of only executing it when a change occurs.

This would very cleanly allow you to set up logic to update the component's DOM that cannot be driven from its view template, without duplicating logic in both init as well individual templated event bindings.

For instance, rather than writing:

init : function() {
  this.element.attr( "aria-expanded", this.viewModel.attr( "expanded" ));
}
"{viewModel} expanded" : function( vm, event, value ) {
  this.element.attr( "aria-expanded", value );
}

write something with a specific marker such as !:

"{viewModel} expanded!" : function( vm, event, value ) {
  this.element.attr( "aria-expanded", value );
}

and have CanJS use the appropriate accessor method to grab the current value and do the change handler and initialization in one go. (Just have event == null for the initialization.)

This would also avoid a lot of overhead that can currently occur when init has to retrieve values of computes before they are bound. Non-bound computes do not cache the result of their getter, meaning potentially extremely expensive getters heavy on logic, and carrying other nested computes and binds inside, have to be run twice: first for init and then again when templated event binding are initialized and their computes do become bound.

Basically; bind becomes init and thus you can enforce the performance best-practice of bind-before-read.

[justinbmeyer]

component's DOM that cannot be driven from its view template

Do bindings with aria-expanded not work? Or are you talking about how to setup properties on the component's element from within the component's code?

[justinbmeyer]

Not saying it's pretty, but you could write it like:

init : function() {
  this["{viewModel} expanded"](this, {}, this.viewModel.attr( "expanded" ) );
}
"{viewModel} expanded" : function( vm, event, value ) {
  this.element.attr( "aria-expanded", value );
}

[justinbmeyer]

btw, can you create this in another issue? ... it's related but not the same as this issue. Thanks!