我都没看完
如果一个新的技术方案不成熟，或者不如原来的版本好用，就不要替换原来的技术方案，希望官方能做到这一点。，或者标上实验性功能，原来的方案保留，否则新版本的bug会越来越多。
哈哈我们也是d
有一说一，unity转微信，转H5没有cocos这么香，轻量级开发还是首选cocos，够用就好。
项目大了，不仅对引擎要求高了，对开发团队本身也是有更高的要求的
我曹，你不说我还没发现没标点符号，而且我居然读完了。。。难受
我一直不大明白为什么这个世界上存在很多说话打字不喜欢加标点符号的。。。尤其是我的客户。。我非常难受跟他们沟通起来，
因为代码不需要加标点 只需要空格和分号
你绝对不是南方人，因为南方人从小到大都需要写作文，因为我没去过西北，所以我高度怀疑那边的人存在不写标点符号的为多？
跟南北方没关系 我一年写的最多的文字就在这里了 还是为了给cocos提bug
我认为cocos的潜力很大
cocos的文档真的对新人小白越来越不友好了。再加上一些版本更新，就更加容易踩坑。
确实是，文档写的太简陋了，基本上看文档解决不了问题。 3.x的 API更是难以理解
你好, 请问目前是需要什么效果以及遇到什么问题? 可以先参照一下该demo的用法 cocos-example-open-data-context/3d_mainProject at master · cocos/cocos-example-open-data-context · GitHub
有问题可以再联系我
开放数据域最好是简单的渲染排行榜数据，邀请好友相关按钮 UI 有办法放在主域吗，直接绑定 Button 控件
文档链接确实需要更新了，估计链接过期了，我们同步下文档组
这块我来替广大用户解释一下，感觉你们可能没有想到这个普遍的情况。
- 子域排行榜，也是作为一个弹窗存在的
- 优秀的游戏的弹窗都有缩放动画（low一点的游戏只用 active=true, active=false）
- 一旦使用动画（比如缩放）那么窗口大小一定是可变的，一般从 scale(0, 0)开始缩放
- engine viewport 消息调用次数没跟上 scale 变化，导致子域仍然是 scale(0, 0)
- 2.x 通过在动画结束手动调用
updateSubContextViewport进行 hack，功能能用 - 3.x 不知道为啥，删除了
updateSubContextViewport然后我们sb了就
ps: cocos 有一个不好的习惯：删除 api 后没有给替代方案，或者说我没在 docs 里找到，如果用户找不到，我认为也是另一个问题。
@_PP
另外补充一点，无论哪个版本的 cocos 子域。每次写都需要学习成本，这点不是很友好，希望 3.8 长期支持版本，能降低新人在这方面的投入。
按照 cocos 你们的设计，应该是拿来就用的。
但实际上，开发者一调，最低2天时间。遇到什么需要 hack 才能解决的问题，找问题还得 2 天，然后你就还能顺便写一篇毕业论文（踩坑指南）跟楼主一样。。。
弹窗不是子域本身的逻辑吗？大部分公司的子域都是复用的。主域的 viewport 尺寸足够大的话，子域想要怎么做效果是子域的事情。
不是主域弹出弹窗显示加载中，然后刷新子域的内容嘛？弹窗效果也要子域做，主域代码都复用不了啊
这里应该考虑开发者使用和理解过程的一般情况，来降低新人的开发成本，减少弯路（直觉是第一老师）：
- 主域有弹窗功能（可能包含动效）那么顺理成章的开发者会先复用这个弹窗（如果你没动效果，那就没这个坑）
- 子域的第一个学习成本是将子域理解成是一张图片（无论cocos和微信都是这么解释的）
- 将一张图片（子域），放在我的带动画的弹窗中（这个是合理的，不需要理解成本）
- 剩下的就是渲染正确（包括显示和触摸，这个应该引擎解决）
按照 jare 你的这个解释，那就变成了这个过程：
- 主域只支持 active = true 这种情况，不能将子域这个“图片”放在任何动画node中，否则会出现触摸区域异常（无法点击和拖动）
- 你认为动画缩放的效果都应该放在子域中，但是子域推荐减小模块体积和功能，甚至新版推荐使用 doTjs xml 这种方式开发。但使用这个方式做一个弹窗缩放动画，无疑是高成本。而且这些效果需要和主域的效果统一。
- 子域想做的事儿，应该只有一个：渲染和主域对应节点尺寸始终保持一致的图片（包括显示区域和触摸区域）
