老哥这个不错，我也搞一个
同，不过我写的是函数接口，里面有监听，绑定，禁用 / 启用绑定…
大佬能讲解一下么。。。？不是很懂你这种写法，想学习一下
我看错了，我还以为你说的是绑定组件到数据，原来是添加组件
关注这个话题这么久，看到大佬这个装饰器实现，跟我现在的用法简直是异曲同工啊！
view 里用装饰器自动获取节点/组件
写了个插件，根据节点规则自动生成类属性到脚本，为了方便查看结构添加了路径注释
属性不需要序列化到场景文件，但仍可以在编辑里定位到该属性关联的节点
controller 里仿vue双向绑定数据
界面与数据模型相互操作
9赞
结合的用。框架上肯定是代码控制的。各部分功能也是代码控制，到了具体的功能上再挂架本做预制体。
如果是中度或者大型游戏的，对公司而言是B更好一点，这个是别人的观点，我个人是看不出来有什么好处的。
如果是小游戏级别或者轻度游戏的，a绝对是首选。
我个人认为a肯定要比b更好，也更加符合开发creator引擎的初衷，
既然都不需要可视化了，那为什么不回去用2dx呢？
我们用creator开发的目的就是为了可视化快速开发啊。
用代码绑定节点读取速度慢，性能较低啊，代码阅读性也不好吧，我写的组件开发代码有时候都未必能第一时间找到需要修改的代码，更何况全程用代码操作一切呢？当然也可能是我水平有限的原因。
3赞
有那味儿了~
同九义，汝何秀。。。
各方都提到了一个关键问题：光看代码，无法弄懂实际运行逻辑，因为有大量的字段是在编辑器中设置的，特别是关联的对象。
针对这个问题本身，我的个人立场：
- 组件化 + 编辑器，实现了一定程度的解耦和复用，越极致的组件化模块会越碎，必然带来全局逻辑的松散
- 任何开发框架都会有一套规范，同样会在模块化的同时导致全局行为较难预测，甚至一点点配置的变更最终结果都会完全不同，Creator 也不例外。灵活性和规范性之间难以两全。
- 传统 IDE 如 VSCode 对代码的引用关系能做到很好的搜索和跳转，也能快速切换编辑各类配置文件。因此开发者还算能比较方便的弄懂最终整体的业务逻辑
- Creator 由于一个组件可能在多个资源文件中使用，甚至可能运行时动态创建，就抬高了开发者检索上的成本，导致不少人干脆就用 B
针对这个问题本身，解决方式除了各位说的 A + B，我还建议各开发团队制定自己的开发规范的。 例如逻辑和引擎表现相关逻辑的分离、数据的分离、管理类的实现方式、参数声明方式、配置的声明规范……
以上只想解决这个问题，流派之争门道当然不局限于此，大家可以继续。
而作为官方，我觉得可以给 VSCode 做个智能提示插件，提示某个变量在编辑器中的实际使用情况。例如关联到哪个节点？参数被设置成了什么值？ 方便接手别人的代码。这么一个插件你愿意花 100 块钱拥有吗？
- Shut up and take my money
- 愿意
- 再考虑考虑
- 不愿意
- 老子不愿意
0 投票者
2赞
我自身使用和教授下面开发的规范是
能使用A的时候一定使用A
编辑器实现资源与界面的一系列绑定实际是代码实现不了的
比如资源移动/更名，用B的话就多了非常多维护成本 等问题
在中小项目，特别是有很多渠道开发的时候B的维护成本是巨大了
从2dx过度到creator的团队很容易保留B的习惯，我觉得可以换个角度想下
既然选择了creator，就尊重creator的设计理念，尝试用A来处理项目能够处理的问题
4赞
赞同，没有规矩不成方圆，其实很多的问题都是团队没有统一规范和文档手册导致的沟通和交流困难。
只要按照统一规范来 a会比b更加有效。
但是a有个致命的缺点，就如同大家所说的一样，越大的项目，跟编辑器的关联肯定越弱，不是什么版本升降或者换其他引擎快一点这种。根本问题所在就是cocos的fire文件是个json文件，通过这个文件去反序列化生成节点，耗费的时间太多了。
所以现在单场景+预制体拼接用的人才多。纯代码处理能在一定的程度上减少引擎依赖，更加自由化，利用好碎片时间去做更多的事情。
归根结底说道最后，我估计很多人选择cocos是因为cocos全平台适配，往哪里都能上游戏所以才选择的，不然大家如果对引擎满意也没有那么多魔改党了，也不会自己纯代码控制就像cocos2d-x那样，那多浪费时间。
shut up and take my money
如果我是主程或者架构，我愿意。。。。但是。。。我拿来总觉得没什么用
B不就回到了以前2DX+CocosStudio的开发方式
是的呀。但是经过我初步的推断。现在中国游戏公司里至少还有 50%的项目组还在用 cocos-lua 来开发游戏。
你这个节点获取是遍历所有子节点吗？这样可能会有性能问题
前端界面真心没有什么性能好担心的。除了做道具列表那种list注意下。其他的随便折腾