循环引用这个报错太恶心了

ts问题吧

明智了,哈哈 fgui 项目移植起来肯定简单

循环引用不是脚本之间耦合度过高导致的问题吗,还是说不是我理解中的循环引用

对的,基本就是父子这种,还有mgr的互相引用,乱得一批……

多人协作的时候 ,每个人引用的模块之间相互又有关联了,

是的。感觉ccc是在强制提高编码水平啊,比起egret不够野,科班出身的感觉。。

是不是也可以理解成 ccc不够老道,,,,, 好的引擎还是会考虑到这些边边角角,让开发者少操心才是真的,,这点不管科班不科班,,,能抓到老鼠就是好猫

嗯。之所以转ccc还是一直看好它。引擎好不好,落到实处还是带来的项目赚钱与否。

我已经不管循环引用了,在类A的方法里写个typeof B,然后在类B的方法里写个typeof A,这样都算循环引用 :joy:

1赞

抱歉,关于循环引用的问题,现阶段没有比较好的解决方案

出现循环依赖的时候,确实是需要报警告的,否则会出现一些不确定的运行时问题,最典型的就是在模块顶层直接使用导入的变量

// a.js
import { b } from './b.js'
console.log(b);
export const a = 'a';

// b.js
import { a } from './a.js'
console.log(a);
export const b = 'b';

// main.js
import './a.js'

此时执行 main.js 就会报错

Uncaught ReferenceError: Cannot access 'a' before initialization

这是因为 a.js b.js 都互相依赖彼此的初始化操作,执行的顺序是这样的:

  • main.js 导入 a.js
  • a.js 第一行导入 b.js,a.js 会先被阻塞,先执行 b.js
  • b.js 第一行导入 a.js,发现已经导入过了,会先持有一个 a 变量的引用,继续往下执行
  • b.js 第二行直接打印 console.log(a);,此时会由于 a 变量还没执行初始化操作而报错

这种情况下 js 是没有办法处理的,只能在编码的过程中规避这种情况

但是实际研发的过程中往往很难避免循环引用的情况
需要强调的是循环引用不一定会引发运行时问题,如果出现上述在模块顶层直接使用导入对象,而且也存在循环引用的情况,就会有问题, 所以编辑器会需要给出警告,让开发者能够关注到这块的潜在问题

我们后续会考虑优化这块的报错体验,如果有任何建议也欢迎给我们反馈哈

5赞

这个摄像机预览窗口报错的bug 从2.x开始我就遇到过,,,知道现在还会报错,哈哈哈哈

1赞

这个我们内部反馈下哈

谢谢官方。目前确实通过改结构在解决。不过项目大,一时半会搞不完。感谢lixionglue同学的“源码循环引用查找”插件,帮助不小。

1赞

把摄像机面板从界面里弹出,这个功能依赖场景先启动,我们后续会修复。

请问下官方,能不能提供接口,实现类似 Unity自定义资源导入器类似的功能啊,动态界面资源导入几万个,这一个个目录去批量搞,这太费了……

为啥默认texture类型,而不是spriteFrame,ccc又不是做主机单机的,界面资源远远多于texture吧……

算了我投降,还是去改fgui的源码加载texture…… :joy:

我用全局环境解决了的。 把引用集中的几个类放到全局中,制定合理架构和编写规范。 然后用api提示不报错。 最后全局开发不受影响。

厉害,我这类太多了

主要是项目结构.把中间链接的类给全局化就行了吧. 比如什么manager. 本身全局化的含义在这