You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that our rpcWorker does not provide a 'fetchCJS' callback, and the fetchCJS callback in place uses window.require so just adding it with a copy of the current one may not work. But, if fetchCJS is helpful/needed in jbrowse-desktop on a webworker, we may want to remedy this?
The text was updated successfully, but these errors were encountered:
The existing fetchCJS won't work in the webworker since there is no window, but with a small adjustment to replace window with globalThis, I think it will work.
One concern that I just learned about, though, is that native Node.js modules are not thread-safe, and electron strongly recommends not using them in web workers. We already use native node modules in the workers, though, e.g. when we use fs in LocalFile from generic-filehandle when doing openLocation on a worker thread. So this wouldn't be a new risk, but still could be something to consider.
We already use native node modules in the workers, though, e.g. when we use fs in LocalFile from generic-filehandle when doing openLocation on a worker thread. So this wouldn't be a new risk, but still could be something to consider.
Above that, however, it does at least say that "All built-in modules of Node.js are supported in Web Workers", so I think our use of fs is probably ok.
I noticed that our rpcWorker does not provide a 'fetchCJS' callback, and the fetchCJS callback in place uses window.require so just adding it with a copy of the current one may not work. But, if fetchCJS is helpful/needed in jbrowse-desktop on a webworker, we may want to remedy this?
The text was updated successfully, but these errors were encountered: