开发流派，到底哪种才是正途？

Creator 3.x
#223

说明这是个普遍但是没法只用一个方案解决的问题。
咳咳，所以假设你们呢，会怎么优雅地处理 :smirk:

#224

单独写个 bind 组件，刷新的时候把节点自动 bind 到脚本上，索引就以你们的特殊的属性名就行。
运行时只需要把 bind 的组件打包成动态 object 注入到 view 里面就行了。
生成的代码只需要导出个 type class 就行了，其实就只是拿来做提示啦。
这样就完全避免运行时查找组件了。

#225

一般小模块比较多UI用a 编辑器模式 方便实现和测试 集成。 游戏战斗重表现的一般用b 代码控制 。 多用预制件组合的模式。

1赞
#226

当然是B，多人协作时，技美，程序，同时操作预制件或场景有冲突时，才知道拖控件是多么痛苦。来试试这个mvvm吧，基于typescript修饰器的mvvm数据绑定方案

#227

我选择A，有以下原因。

  1. 我个人觉得选择B的更多是以前的程序员原有的代码方式不想轻易改变，而可视化编程是未来的趋势
  2. 选择A也可以有很好的代码设计方案
  3. 对我来说，这是强行和引擎解耦。没啥必要（打个比方，我用nodejs写代码，却又不想和nodejs有太多的关联）
1赞
#228

以前 2dx 也是这么想的

#229

A 也可以各人搞各人的啊

#230

A是可以各人搞各人的，但是如果有人撂挑子了，那个收拾烂摊子的会骂死那个撂挑子的，A方法出问题，维护性比B差的不是一点半点

#231

可以做一个脚本，就是一个键值对设置器，专门用来让做界面的人来拖节点到这个脚本上，写代码的人和做界面的人约定好名字，代码里以后总是通过约定的名字访问节点，这样，界面随便怎么改。代码都不用动。

#232

这个跟直接在编辑器里拖的区别是？

#233

给A流派补充个优点：就是封装ui组件时，可以拥有代码逻辑功能。B流派的ui组件封装都在代码里，你在ui层面复用比较麻烦，多层嵌套更麻烦。

#234

能不能在creator的层级管理器上面，给每个节点做个标志，直观的看出有脚本绑定。而不是等点击节点后再到属性检查器里查看是否有脚本绑定。这样可以提升新人对项目的阅读效率。

#235

直接写个插件，一键生成所有的配置文件，用管理类去调用节点就完了，代码应该吃不了多少内存吧

#236

一般来说 A模块 自己搞自己的 接手的人实在看不下去 熟手一个模块要不了多久的

#237

个人看法：可视化的东西，别人接手才快；纯代码的东西，别人接手才要命

1赞
#238

脚本全部手动拖到节点上，随着项目越来越大节点树越来越深，接手的人找个东西简直会崩溃，代码至少还有脉络可以跳转 :face_with_monocle:

#239

节点深度是看组织者怎么组织，

#240

就像拆分代码一样，预制节点也是可以拆分 的
，分别挂上脚本

#241

有些节点它就是很复杂，即使你划分的很好，划分的粒度越小文件也越多找东西点来点去也是头皮发麻。

#242

其实总的代码量拆分出来是差不多的，拆分才便于阅读，如果是非可视化的代码量比这种可视化的代码量更多，