I had a quick browse through the cocos creator engine repo and noticed that component implementations provide _createSgNode and _initSgNode functions… This means for every component I add to a node in Creator a node is constructed to do the dirty work and the component simply acts as an interface.
CCSprite.js:
_createSgNode: function () {
return new cc.Scale9Sprite();
},
CCLabel.js:
_initSgNode: function () {
...
this._sgNode = new _ccsg.Label(this.string, fntRawUrl, textureUrl);
this._sgNode.retain();
...
This seems both counter intuitive and a rather large overhead when the whole point of a component system is to abstract the systems from each other allowing for a more data driven approach and reducing reliance on inheritance. This approach still allows definition and construction of entities by composition rather than inheritance but maintains the inheritance from node and hides it away. It’s not really much different than defining a Entity as a hierarchy of CCNode derivatives.
I’m probably missing something here though 
Could any of the devs explain why this approach was taken, over say the classic system/component/entity model?
Thanks
@slackmoehrle @zhangxm @ricardo
Let us ask @pandamicro to look at your questions.
@nantas2 can you take a look at this question, please.
Sorry for the delay, I was doing some blocking task for v3.11 release so haven’t got too much time for the forum.
good findings, basically you are right ! But the component is not just interfaces
And we are taking this approach because it’s the most economical way, we already have a complete rendering engine: the original cocos2d. Creator wants to bring data driven and entity component architecture to it, it’s pretty natural to build on top of the rendering engine instead of write a whole new one. This architecture has many benefits:
- It separate rendering from data, Entity Component layer not only act as a user interface, but also contains data, which will drive the rendering engine to render the correct result on screen.
- We don’t need to touch the original Cocos2d too much, which permit us to have multi-platform distribution very efficiently, otherwise it could take a long way to the same target.
- The rendering tree could be refactored later to contain pure rendering informations.
- At last, a correct implementation of Entity Component in C++ is not easy, we prefer to have pure script implementation to support EC
Thank you for taking the time to write a detailed reply.
I can definitely appreciate the desire to nail the EC layer first and get Cocos Creator into people hands as soon as possible, there’s no test like a field test 
And having EC in C++ would help portability of new features between cocos2d-js and cocos2d-x, seems a bit crazy not aiming for the same paradigm in both code bases.
@zhangxm have actually done some research on EC implementation in C++, finally we found it very difficult to make it clean. Plus, we have chosen Electron to make creator, so it’s natural to create EC level in Javascript based on Cocos2d-html5. If we do the same thing in C++ (suppose we found the perfect solution), it will double our work (actually even more, developing in C++ is much slower than in JS). Then we may never see Creator’s birth.
Instead of spending time on having EC in C++, we prefer to upgrade the current rendering pipeline for both native and web engine. Hope we don’t choose the wrong path
Makes sense, there’s always a balance to be struck between an ideal solution and a practical one. I would definitely be interested in reading the results of @zhangxm’s research if at all possible. I’ve written simple EC solutions in C++ in the past but nothing on the scale that cocos2d-x would require, so I am curious about the difficulties you guys could foresee.
These are hard decisions, and all you can do is your best and deal with fallout as it comes.
Thanks again
Could any of the devs explain why this approach was taken, over say the classic system/component/entity model?
good findings, basically you are right ! But the component is not just interfaces