Difference between constructor and create
What's the difference between:
constructor: function () {
console.log(this.$);
}
create: function(){
console.log(this.$);
}
I found that, sometimes, not all components of a control could be initialized in constructor. Which means, console.log(this.$); of constructor is empty sometimes. Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
constructoris supported by any Enyo kind and is called first when the kind is created (either bynewdirectly or implicitly when using features like thecomponentsblock).createis introduced by enyo.Component and is called fromconstructedwhich is called immediately afterconstructor. The base implementation ofcreatecallsinitComponentswhich creates the components declared in thecomponentsblock of your kind.create, when overridden in subkinds, is usually responsible for any setup of controls after they are created but before they are rendered.Here's some pseudo-code that simplifies it all:
// defined by the framework in Oop.js function enyoConstructor () { constructor(); constructed(); } // not often used by subkinds but can be // used to do pre-component setup function constructor () {} // more frequently seen for setup function constructed () { create(); } // Component setup function create () { initComponents(); } // Creates the child controls defined in components: [] function initComponents () {}It seems it is not in the new developer guide though. I will see where we want to put this information or if it got inserted somewhere and I missed it.
http://enyojs.com/docs/latest/developer-guide/key-concepts/components.html
I still kinda like ryans' pseudo-code walkthrough though. It's compact and informative.
By the way, considering the constructor is sometimes deferred, are there any other side-effects to executing things using the constructor or using the create method?
new, that's when the constructor method is called if the prototype was deferred or not.An example case is a UI where a user can cycle through a list of images and each new image animates into view. The user could rapidly push a 'next' button many times triggering many simultaneous animations, causing slow frame-rates in the process.
What you could do instead is manipulate the currently selected index for each tap, but debounce the method that triggers new animations. This way, if a user taps 10 times in quick succession, they might only start 2 or 3 animations rather than 10, yet the final animation still brings them to the 10th next image.
Currently, I simply create the all my methods the usual way, then pass it through a throttle method at construction time:
enyo.kind({ /** * Debounces myAction */ create: enyo.inherit(function(sup) { return function() { sup.apply(this, arguments); this.myAction = _.throttle(this.myAction, 300); } // do stuff }), /** * Will be throttled at construction-time */ myAction: function() { // do stuff } });This way, thanks to underscore's spiffy throttle function the method is throttled and I don't have to worry about handling context or anything like that. However, the original method does get replaced with a throttle version at instantiation time. It'd be cooler if I could get an already debounced method on the prototype.Which, by the way, if it sounds useful, I could try and create a mixin for that and make a pull-request.
http://jsfiddle.net/3x8pugmd/