resCfg - SmallAiTT/cocos-utils GitHub Wiki
This is the main config for the dependencies of the project.
It is the core to load js and resources, just like what resources.js
and appFiles
of ccConfig
do in the develop branch.
cc.js
takes place of jsLoader.js
, so jsLoader
do not work in this npm branch.
Simply like this:
resCfg[key] = {
res : [],
ref : [],
sprite : "",
layer : "",
scene : "",
args : {},
...//your custom config
}
Each property is optional.
All paths of resources are generated in res.js
, and all paths of js are generated in jsRes.js
.
Use these to configure resCfg
.
The key
should be a string. Simply you can use moduleName
,
js.moduleName.aJsSrc_js
configured in the jsRes.js of modules,
or just a simple string.
ref
is short for reference
, which contains the references for this part.
res
is short for resource
, whiche means the resources to be loaded for the part.
Base config part of module
The resCfg["moduleName"]...
part is the base config of the module. e.g. a module named m1
:
var resCfg = cc.resCfg || {};
var jsRes = js.m1;
resCfg["m1"] = {
ref : [jsRes.code01_js, jsRes.code02_js],
res : [jsRes.a_png, jsRes.b_png]
};
It means that the base config of the module references code01.js
and code02.js
, and preloads a.png
and b.png
.
So resCfg["m1"]
will be loaded when the project boots by default,
which means config for code01.js
and code02.js
will been loaded, and so as a.png
and b.png
.
Config for a js
Pay attention to this, if none config should be set for a js, you do not need to write the config followed.
resCfg[jsRes.code03_js] = {
res : [res.c_png],
sprite : "MySprite",
args : {a : "AAA"}
};
You can see that, code03.js
has no references, but one resource named c.png
.
The content of code03.js
is simply like this:
var MySprite = cc.Sprite.extend({...});
MySprite.create = function(args){
var sprite = new MySprite();
...
return sprite;
};
The sprite
is used to test code03.js
.
Be sure the there is a class name named MySprite
in code03.js
,
and the MySprite
has a function called create
.
args
of the config will be passed to the MySprite.create
function.
If the create
function has no arguments, just keep args
null.
Then, test mode is opened while the config.test
is configured in main.js
, such as:
config.test = js.m1.code03_js;//config which js you want to test
Otherwise, the project will be ran as normal mode.
e.g. set config.test = js.m1.code03_js
, visit index.html, then you will see the test case of code03.js
.
Same as layer
, scene
and so on.
Custom interface of test unit will be provided in the future.
You can also write your test code in the test
folder, such as a test js file named code03Test.js
:
var MySpriteTest = cc.Layer.extend({
//TODO write code to test code03.js
...
});
MySpriteTest.create = function(args){
var layer = new MySpriteTest();
...
return layer;
};
Run cocos genJsRes
or cocos build
to generate the path config of code03Test.js into jsRes.js.
Then configure:
resCfg[jsRes.code03Test_js] = {
ref : [jsRes.code03_js],
layer : "MySpriteTest",
args : {...}
}
Set config.test = js.m1.code03Test_js
, visit index.html
, then test case of MySpriteTest would be run.
Test codes will not be complied by running cocos publish
.
By this way, you can test your js file easily, without editing any code of source of your project, and see the effort immediately. You do not need to boot the whole game, and do a lot of "click" actions to reach the page which will be tested.
Reference
resCfg[jsRes.code04_js] = {
ref : [jsRes.code03_js]
};
resCfg[jsRes.code05_js] = {
ref : [jsRes.code04_js]
};
In the above, code03.js
is referenced by code04.js
and code04.js
is referenced by code05.js
.
Not matter what has been changed in code04.js
, nothing will be changed, while the interface of code03.js
is not changed.
This will be good for team work, that everyone just care about the interfaces provided by others.
code04.js
do not need to care about what resources are used in code03.js
, or what scripts are referenced in code03.js
.
Game Modules
cc.gameModules = [jsRes.code05_js, ...];
This is for modules of game, such as home page, fighting and so on.
The engine will load resources and js for the modules by this config.
e.g. code05.js
is the entry of fighting module, you press fight button to enter it (onClick function bellow):
cc.loadGameModule(js.m1.code05_js, function(resArr){
cc.LoaderScene.preload(resArr, function(){
cc.Director.getInstance().replaceScene(...);
});
});
And this config tells cocos publish
which scripts should be compiled.
The base config part of resCfg will be compiled by default.
Last But Not Least
resCfg.js
looks so complex, but it is easy to be used step by step to improve the efficiency of coding,
for you know which resources and js are required in this current js.
It is the core for uncoupling.
resCfg.js
tells the dependencies of modules and scripts, so that cocos publish
can get all the scripts to be compiled.
resCfg.js
is the core that we hope developers can give advices to help us to make cocos-utils
better and better to improve efficiency of development.