Lam Tang
Hi, @dirslashls, it is the second time I commenting on this issue. I commented here 3 days ago but I found I was wrong, so I deleted those wrong info...
Hi @dirslashls, below is the snippet. You can run it in [online editor](https://echarts.apache.org/examples/en/editor.html?c=bar-drilldown) to have a try: ```javascript // level 1 (root) const data_1 = { dataGroupId: '1', data: [...
Actually this issue is linked to [one project](https://summer-ospp.ac.cn/#/org/prodetail/22ffc0289) for OSPP Summer2022. I would like to apply for this project, good luck to me! :smile:
# [8.6] A Possible Interface for This Feature Hi, guys! I have come up with an interface to allow users to implement multi-level drill-down/up easily and intuitively. The new interface...
老师们好~我有开发Chrome Extension的经验，目前运营着插件项目[Hypercrx](https://github.com/hypertrons/hypertrons-crx)，该插件着重于ContentScripts和Options的开发。但我对Background（service worker）和Devtools页面的开发也非常感兴趣！ 由于Google在逐步淘汰Manifest v2版本的插件，之前我对Hypercrx进行了升级，所以对Manifest v3有一定了解。也捣鼓出了支持ContentScripts“伪Hot-Reload”的插件[模板](https://github.com/tyn1998/chrome-extension-boilerplate-react/tree/background-contentScripts-auto-reload)。 之前OSPP活动晚了一步，这次ASOC希望能参与进来，和大家一起学习一起have fun！
一个~~可能行得通~~的思路： 将“可能行得通”划掉是因为Electron端的事情没想象中简单。
# 【6.20小记】外挂式通信消息捕获是否可行？ Hi, OpenSumi community! 这两天我在探索学习中，主要是想确定捕获通信消息的可行方案。标题中所谓的“外挂式通信消息捕获”指的就是诸如： - 用DevTools的Network查看WebSocket消息 - 用[DevTron](https://github.com/electron-userland/devtron)查看Electron的Main进程和renderer进程之间的IPC消息 因为宿主应用对它们是没有感知的，所以是“外挂式”的。就我目前的认知看来，这种比较理想的方式**似乎不大可行**。 ## DevTron捕获IPC消息的原理 DevTron是 @Yantze 老师推荐看看的，于是我首先学习了它的原理。与IPC消息捕获相关的代码在[这儿](https://github.com/electron-userland/devtron/blob/c2d06028bb75c5cc5567b272a866e6d6e75223df/lib/ipc-helpers.js#L43-L66)，可以用移花接木或偷梁换柱形容。具体是怎么做的呢？Electron的Main进程和renderer进程之间以IPC的方式进行通信，具体到代码就是用ipcMain和ipcRenderer这两个API通信。DevTron**对ipcRenderer做了手脚**，在其中加入捕获通信消息的逻辑，使得宿主应用执行ipcRenderer的方法时实际上**调用的是改造过后的ipcRenderer**，于是就达到了“外挂式通信消息捕获”的目的。 ## 为什么我觉得“外挂式”不大可行 我一度认为DevTron所采用的方法就是本课题的方案了，直到意识到此课题要求捕获的消息是前端进程和后端进程之间的消息，而不是Electron的Main进程和renderer进程之间的消息。前者在Electron端（isRemote为false时）是靠Nodejs的Socket来通信的，这意味着跟ipcRenderer没什么关系。这也解释了为什么当我在ide-electron中运行DevTron后，IPC消息列表几乎没什么消息——因为这个列表中的消息只包含ipcRenderer收发的消息。 我不想轻易放弃：既然Chrome能捕获websocket的消息，那**有没有方法可以直接捕获socket消息呢**？这样的话宿主应用照样是对此无感的。遗憾的是，目前我还没找到。 ## 其他 以上只是我目前的认知，如果有错误的地方请 @yantze 和其他maintainers一定要纠正我。
谢谢 @bytemain ，你提供的snippet非常具有启发性！ 之前和 @yantze 老师交流过，如果“外挂式”方案行不通的话，就改动connection模块的代码。WSChannel是针对websocket的，我刚刚发现RPCProtocol._protocol看起来是个更好的切入点： https://github.com/opensumi/core/blob/4df3b875d71f46e58c4684ec1eb25b09a4ed053f/packages/connection/src/common/rpcProtocol.ts#L201 因为this._protocol是一个connection，而connection是统一了websocekt和socket的，所以这个send和onMessage对websocket和socket的msg都适用。大家怎么看？ --- HELP WANTED： 以connection这个模块为例，我发现common/的一些模块只在web端用到；node/的一些模块是针对Electron的前端进程的，还有一些是针对OpenSumi的后端进程的。好吧，我也说不大清我的感受，也许我想问node/connect.ts为什么不放在common/里，因为我目前认为node/只放后端代码。 大家如果愿意分享一下“如何读懂connection”相关的经验的话，那就太好了！急需这方面的建议。
# 【6.28小记】修改ide-connection实现对MessageConnection消息的捕获 非常感谢 @bytemain 和 @yantze 的回复！前几天仔细阅读了回复内容后，我明确了一下目标，并进行了实验。 ## 明确目标 - 优先实现“侵入式”捕获消息，即通过改造ide-connection捕获前端这测的收/发消息。 - 其次（之后）再实现简单的“外挂式”捕获消息，对于浏览器可以基于CDP；对于Electron（非remote）可以直接基于socket？ （这里想确认一下：@yantze 老师说的ipc特指socket通信吗？） ## 实验：改造ide-connection ### 改造哪里？ > 因为this._protocol是一个connection，而connection是统一了websocekt和socket的，所以这个send和onMessage对websocket和socket的msg都适用。大家怎么看？ 首先，我放弃了将_protocol作为消息拦截对象，因为在查看了`class RPCProtocol`的所有引用后，我发现只有extension模块使用了它。但前后端的通信不只发生在extension模块。 通过阅读源码、调试后，我发现MessageConnection才是合适的消息拦截对象。下图是我在寻找websocket和socket的统一层的时候画的“connection建立过程”流程图： ### 怎么改造？ 目前的改动部分我已经提了一个[PR](https://github.com/tyn1998/opensumi-core/pull/2)到自己仓库里，大家可以直接前往看[changes](https://github.com/tyn1998/opensumi-core/pull/2/files)。代码改动的地方不多，一看就能明白（虽然我花了很久）。我在这里稍微描述一下我的改造旅程。 首先，我非常希望能改造得松耦合一点，尽量能不影响原来的代码逻辑，所以一开始我还是希望能像DevTron那样“偷梁换柱”，于是我计划用`Proxy`代理`createMessageConnection()`得到的`messageConnection`，并在handler中对`get`做手脚，使得`messageConnection`实例调用`sendRequest`、`sendNotification`、`onRequest`、`onNotification`这4个方法的时候会被拦截到，这样我就可以插入捕获消息的逻辑了。 这里有个细节，那就是`createWebSocketConnection`和`createSocketConnection`不仅在前端被调用，还会在后端进程启动的时候被调用，这是个公共的函数，所以要考虑`window`对象是否存在——使用`window`对象是因为我根据 @bytemain...