- nodejs: v16.4.2
使用Vue3开发的组件库，方便在使用 cc-plugin 编写Cocos Creator插件的时候，快速编写UI面板，保证在各个Cocos Creator版本，UI表现统一。
UI组件参考了cocos creator，假装看起来更加协调。
参考：https://github.dev/IDuxFE/idux
Cocos Creator插件，官方也提供了内置的UI空间，比如ui-button，ui-input等等。
但是随着开发插件的深入，我发现默认的ui控件在所有的Creator版本上表现并不是太一致。
在实际开发过程中，我也发现了这个问题，偶尔会有小伙伴给我反馈一些插件的界面bug，最终发现都是因为UI没有适配好某个版本导致的。
比如控件的disable属性在部分版本上无法生效、写法发生变化等等各种糟心事。
就目前来说，Creator2.x的用户基数还是非常庞大的，而且插件在Creator3.x上，书写方式发生了比较大的变化，实际适配的时候，还是很头疼的，并不是很容易的就能将已有的2.x插件迁徙到3.x，而且在后续的插件开发工作中，还要同时维护2.x，3.x这2个版本的插件，想想都心累，当然，3.x肯定是后起之秀，但是目前来说，2.x仍旧是主站版本。
但是为啥Creator编辑器自身没有发生这个问题，后来仔细思考了下原因：
-
Creator的每个版本中，都完整包含了引擎、编辑器，并且两者是一一对应绑定的关系，至少当前引擎版本和当前编辑器版本是没有任何大问题的。
-
插件则不同，一款插件可能是要运行在N个Creator版本上的。如果插件使用了编辑器自带的UI控件，如果某个Creator版本没有这个UI控件，或者该UI控件的功能版本之间有差异，就会导致插件的运行异常。
-
Creator自身是不会发生该问题，因为UI控件的迭代，是跟随Creator版本一起发布的。
经过上述思考，插件的UI控件如果使用了编辑器默认的，的确会踩中这个坑。
如果你的插件要尽可能的兼容尽可能多的Creator版本，那有什么解决办法呢？
当然是插件尽可能减少使用编辑器的功能（我的意思不是编辑器做的太垃圾）。
这就是这个仓库产生的原因，插件自身就携带了UI控件，这样就能在适配所有的版本。
当然，如果官方将UI组件开源，插件自己选择集成，也能解决这个问题。
那么我们为什么不使用第三方的UI库呢？
比如element-ui、iview等，原因是恶心的shadow-dom，主流的UI框架，并没有处理shadow-dom，而creator在处理插件之间样式隔离的时候，选择的方案就是shadow-dom，这就是很尴尬的地方。
开发这个UI组件，目的还在要解决不同Creator版本UI组件写法差异的问题。
当然，这个UI组件库只是解决方案中的一个。
游戏开发者开发插件，使用的web前端的技能，我也发现部分游戏开发者在开发插件时，初次接触web前端比较吃力。
比如游戏也有Button组件，插件也有Button组件，但是两者使用习惯却非常不同，至少属性完全不同，开发这个组件库，也有意识的去向游戏引擎的对应组件属性靠拢，更符合游戏直觉。
