-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add WebWorker Support #3660
Comments
I’m not opposed if we see a clear proposal from someone about how they should work. |
I haven't written WebWorkers before, but I think this library is interesting to get support of web workers in CRA right now: https://github.com/developit/workerize it also has it's own webpack loader https://github.com/developit/workerize-loader (not required to use workerize) which in turn inspired by https://github.com/webpack-contrib/worker-loader I think adding the last one with test like |
I like the idea of using a different extension ( |
I'm curious about WebWorkers in general so I wouldn't mind giving this a try. |
In the past I had to eject and configure "worker-loader". I used it to process some routines on datasets and still allow users to interact with the main UI. |
I use Web Workers to implement a solver using genetic algorithms for a SPA. The solver can run for up to a minute or two, so it needs to be in a "background thread" -- i.e. Web Worker -- to not freeze the browser page while it's running. I should note that my app is currently implemented in Angular and plain old ES5-ish Javascript. I would like to migrate to React and Typescript but this has been a stumbling block so far. |
Is there anything that needs to be done before this pull request can be merged into the next branch (2.0 release)? I might have missed it, but I could not find Web Workers on the 2.0 Projects roadmap. I would love to be able to try it out in one of the alpha releases 🙂 |
I think there's still some debate about using |
I couldn't get |
@iansu I'm not sure about |
I realize there is a desire to make a 'simpler' API for web workers, but honestly, the basic subset is more than sufficient. I have a data intensive app, and want to use web workers to do the data fetches, parsing, and pass massaged data back to the main thread often. A 'run once - read once' methodology may work for some applications, but nothing that I am involved with. |
Ah, yeah, workerize will not work (heh) for me. I need to keep a web worker running and exchange messages back and forth. Progress bars is one of the uses as @Narvey mentioned. |
Granted a distinction between "physical" threads and "software" threads, such that creating many web workers may result in more software threads than available physical threads, a developer may wish to mind the user's hardware utilization and create fewer or no more than the available number of physical threads, e.g., https://github.com/josdejong/workerpool/blob/master/lib/Pool.js. So, here are two React pooling attempts:
|
Would love to also see some support for newly introduced AudioWorklet, which are basically web worker for audio processing 😃 |
Another use case: Desktop Chrome (~75% global market share) throttles |
@jasmith79 To be honest, that sounds like a hack to get around a legitimate browser restriction. What's the actual use case? |
@doxxx I wrote an app for work that has to be able to do background update, so I poll the backend for changes every so often on an interval timer. Got reports that it was wonky in Chrome (worked fine in FF/Safari) and discovered that (this was before serviceworker). Runs fine in a webworker. Now I'm porting the front end to react and discovered this problem. |
I'm wondering if we could write something like workerize, but with the following changes:
I think these changes would achieve the following goals:
How does that sound? |
That does sound useful but it also sounds like it's outside the scope of Create React App. Have you considered proposing these changes to Workerize? |
I was more thinking of building this as a separate library. But I'm quite interested if that proposed design would fit the needs that people have for webworkers and if something like that would fit into cra? |
All I really want is just for the existing WebWorker APIs to work and to be able to load a js/ts file as a web worker. Anything beyond that lies outside the scope of CRA as far as I’m concerned. That forms the basis on which everything else can be built. |
I know most of the conversation is around implementing support for Web Workers, but Web Worker usage is the gateway to then needing to use SharedWorkers, so it would be really amazing if there was a way to handle the ad-hoc solutions needed today if you want to utilize Web Workers, SharedWorkers, or AudioWorklets - or in my case, the combination of all three. Conventions for special treatment such as *.worker.js, *.sharedworker.js, *.worklet.js (or *.awn.js?) would work wonders for those of us using CRA for more advanced cases. |
Add ability to load WebWorkers (and SharedWorkers?) via the react-scripts. My use-case is for using latency (and debug) sensitive protocols over WebSocket which may get dumped by the server if no activity occurs.
There has been a lot of discussion regarding this on #1277 but no definitive answer and now closed. Also, I'm a server-side dev so JavaScript PR is not my forte, and neither is ejecting the scripts as that looks scary.
The text was updated successfully, but these errors were encountered: