心得总结，也希望能给后人带来点帮助。原文链接 https://he19jkasmd.feishu.cn/docx/HTyUd2VK3ompefxmIo4crcYSnSf
发展历程
Learning
踩过的坑
-
尽早遵循标准，避免另起炉灶
-
使用类型系统（IDE）来帮助用户写出正确的代码，而不是在编辑态下动态校验，输出一大堆警告和报错
-
避免在一个 API（
@property）内塞入过于复杂的 JS options，运行时解析完整参数的性能开销太大 -
用户总是写不出对的类型声明，就应该修改 API，而不是持续警告
Highlight
-
拆分后的装饰器尽量原子化，隐式规则少，突出重要信息
-
使用一体化的类型系统，通过完善的脚本预编译编译为多个版本，而不是将类型拆分成组件 + Extra。官方的所有类型和用户类型采用同一套类型系统。
-
和序列化一起组成的对象模型，成为引擎强大的基建，功能对齐 Unity 并经过十年考验
-
平稳完成从
cc.Class到装饰器的 API 彻底升级
如果还有 Cocos Creator 4.0
- 移除 @property
Cocos 用户以中重度为主，后续可以在 4.0 统一升级为新的 API 和导入方式，同时将属性装饰器彻底拆分为两个类型，将组件装饰器单独放到组件上：
// 以下装饰器均为现有实现及命名，只是调整了导入方式
import { ccclass, Component } from 'cc';
// Related Decorators on Inspector Panel or Timeline
const { editable, disallowAnimation, displayName, tooltip, multiline,
min, max, step, range, slide, group } = ccclass.editor;
// Serialization & Building Related Decorators
const { serializable, editorOnly, formerlySerializedAs } = ccclass.serialization;
// Component Class Decorators, 上层实现和底层解耦
const { executeInEditMode, playOnFocus, executionOrder,
disallowMultiple, requireComponent, menu, help, icon } = Component;
-
预编译脚本，解析出类型的 schema，注入编译后的 JS
a. 直接从 TypeScript 类型系统获取类型，移除
@type（考虑使用 typedef 区分 Integer）
b. 使用 TSpublic/private关键字来判断属性默认是否可编辑（@editable）和可序列化（@serializable）
c. 使用 TSreadonly关键字判断是否只读，移除@readonly -
序列化
a. 在类型声明上显式区分深拷贝和浅拷贝，而不是通过
ValueType父类进行判断
b. 允许@serializable传参设置特定属性如何序列化，如是否深拷贝指向的TypedArray
