关于 SharedWorker 踩的坑

开发方面console.log不方便必须到 去点 inspect 才能看到它的console.log所以基本靠不了这个来 debug 了相比之下 worker 就没问题port不好拿在 onconnect 时似乎有一个event.port...

开发方面

console.log不方便

必须到 chrome://inspect/#workers 去点 inspect 才能看到它的console.log所以基本靠不了这个来 debug 了

相比之下 worker 就没问题

port不好拿

  1. 在 onconnect 时似乎有一个event.ports，但是往往只有一个 port，而且理论上就应该只有一个，搞不懂为什么是 ports 而不是 port
  2. 在 message event 中，也有个 ports 的属性，但是永远是空的，得通过event.currentTarget来拿，真够奇怪的

部署方面

不知道是不是我的情况不太一样，反正我就是没法用非 module 的方式打包，所以new SharedWorker()的时候，必须指定 { type: "module" }。另外，在vite.config.ts中也得改：

export default defineConfig({
  worker: {
    format: "es",
    plugins() {
      return [sveltekit(), dir2json({ include: ["**/*.py", "**/*.j2"] })];
    },
  },
});

一是得指定 format 为 "es"，二是得重新指定一遍 plugins，搞得我 debug 了好久

这个项目源于我想把 pyodide 运行在 SharedWorker 中，这样一是启动时不会 block UI 了，二是多个标签页中可以共享一个 python 实例：

我的想法是，以后允许三种方式启动 pyodide：

主线程 Worker SharedWorker
加载 会阻塞 只用等待 甚至可能不用等待
隔离性 共享 可以隔离 可以隔离但更蛮烦
可以打断 不可以 可以 可以但更麻烦
生命周期 页面 页面 不好控制
作用域 window DedicatedWorkerGlobalScope SharedWorkerGlobalScope

这么看来主要是生命周期不好管理，而且如果要隔离的话就很麻烦。以后再在这个分支上写吧

不过目前看来，除了麻烦，用 Worker 其实没什么优势 哈哈哈