@xuyanfeng/cc-ui
TypeScript icon, indicating that this package has built-in type declarations

0.2.21 • Public • Published

env

  • nodejs: v16.4.2

cc-ui

使用Vue3开发的组件库,方便在使用 cc-plugin 编写Cocos Creator插件的时候,快速编写UI面板,保证在各个Cocos Creator版本,UI表现统一。

UI组件参考了cocos creator,假装看起来更加协调。

参考:https://github.dev/IDuxFE/idux

为什么要重新造一个UI轮子

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编辑器自身没有发生这个问题,后来仔细思考了下原因:

  1. Creator的每个版本中,都完整包含了引擎、编辑器,并且两者是一一对应绑定的关系,至少当前引擎版本和当前编辑器版本是没有任何大问题的。

  2. 插件则不同,一款插件可能是要运行在N个Creator版本上的。如果插件使用了编辑器自带的UI控件,如果某个Creator版本没有这个UI控件,或者该UI控件的功能版本之间有差异,就会导致插件的运行异常。

  3. Creator自身是不会发生该问题,因为UI控件的迭代,是跟随Creator版本一起发布的。

经过上述思考,插件的UI控件如果使用了编辑器默认的,的确会踩中这个坑。

如何解决Creator多版本的问题

如果你的插件要尽可能的兼容尽可能多的Creator版本,那有什么解决办法呢?

当然是插件尽可能减少使用编辑器的功能(我的意思不是编辑器做的太垃圾)。

这就是这个仓库产生的原因,插件自身就携带了UI控件,这样就能在适配所有的版本。

当然,如果官方将UI组件开源,插件自己选择集成,也能解决这个问题。

那么我们为什么不使用第三方的UI库呢?

比如element-ui、iview等,原因是恶心的shadow-dom,主流的UI框架,并没有处理shadow-dom,而creator在处理插件之间样式隔离的时候,选择的方案就是shadow-dom,这就是很尴尬的地方。

说明

开发这个UI组件,目的还在要解决不同Creator版本UI组件写法差异的问题。

当然,这个UI组件库只是解决方案中的一个。

游戏开发者开发插件,使用的web前端的技能,我也发现部分游戏开发者在开发插件时,初次接触web前端比较吃力。

比如游戏也有Button组件,插件也有Button组件,但是两者使用习惯却非常不同,至少属性完全不同,开发这个组件库,也有意识的去向游戏引擎的对应组件属性靠拢,更符合游戏直觉。

Readme

Keywords

none

Package Sidebar

Install

npm i @xuyanfeng/cc-ui

Weekly Downloads

16

Version

0.2.21

License

none

Unpacked Size

4.13 MB

Total Files

98

Last publish

Collaborators

  • xuyanfeng