npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@xuyanfeng/cc-ui

v0.2.33

Published

- nodejs: v16.4.2

Downloads

13

Readme

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