习惯了ts的类型检查和代码提示 再也回不到js了
CocosCreator3.0依然保留了一个导出d.ts的功能,位于菜单栏中“开发者 -> Export d.ts”,然后在导出目录会看到一个@types目录,请问这些类型声明文件应该放在哪里,应该怎么利用,这些类型声明文件和cc.d.ts有什么区别。
@property(Node)
moreBg : Node = null!
this.moreBg!.active = false
这种非空断言运行没有赋值属性时会报错.为啥呢.
非空断言只是在类型检查时允许他为空,运行时还是会报错的
TypeScript真香+1 by 一个从golang过来的人
namespace的支持不行。
循环引用很容易不行。
扩展用的,主要作用就是为了代码约束和提示,不参与编译
看完这段,结论就是,声明属性时就这样就最好了:
material!: Material;
真香+10086
MARK!!!
很多事情只有在回首往事的时候才能知道当初的决定是否值得,当我现在看到这个帖子,用着cocoscreator 3.7做3d游戏,然后nestjs做服务器,只能说官方ts的选择非常极其之正确!!!
只能说是各有优劣,对于成熟且有长远打算的中大型项目来说,ts是最优解
但是,ts和js的切换在技术上应该不是难点,还是希望给用户一个选择的机会,js的生态短期看比ts丰富太多了,因为有前端的大盘在,未来ts能不能翻盘还不好说,限制死了不一定是好事,多条路嘛,毕竟只是一个脚本语言,不是游戏开发的核心
只能说是各有优劣,对于成熟且有长远打算的中大型项目来说,ts是最优解
但是,ts和js的切换在技术上应该不是难点,还是希望给用户一个选择的机会,js的生态短期看比ts丰富太多了,因为有前端的大盘在,未来ts能不能翻盘还不好说,限制死了不一定是好事,多条路嘛,毕竟只是一个脚本语言,不是游戏开发的核心
unity和unreal这么多年用又臭又长的lua做脚本,开发者捏着鼻子吃,它们的傲慢来自于市场的基本盘,它们可以画个圈子在自己造的生态里自己玩,个人觉得cocos不能效仿,走开放包容路线才是适合的
至于脚本的生态如何发展,是圈里的开发者自发形成的,谁能保证javascript的ES7,ES8,ES9出了之后是什么样,到时js倒逼ts…,路堵死了可不是好事