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
universal-ify the pre processing of workerize-loader? #13
Comments
Module import doesn't give access to the original code - sadly, there's no way to do that. workerMap(`export * from './actual-module'`) |
Would this be processed by the bundler or dynamically resolved by I'm also thinking in the end if one is using such a module to increase performance it does not make sense to add a lot of string manipulation on top of every call to spawn the actual worker |
Nope, that'd be leaving the browser to resolve the import. Regarding performance - spawning a worker is an up-front cost, whereas calls to worker methods increase with usage. In the general case, very few workers are spawned but many methods are called. |
Okay then sounds like a good workaround to me! |
Had to deal with arbitrary multi-worker stuff for a project, and I ended up with this: https://gist.github.com/janbaykara/b9e8b50b00b705c58600c067eeca8cdd |
Nice thanks for sharing! |
This is more a discussion than an issue.
I'm building a worker-map library that takes a loop and splits it into several workers (following the map/reduce pattern). The downside right now is that all the worker code has to be passed as a string (because as @developit already said in a tweet
export
isn't valid syntax in a closure)Here's the API at the moment.
What do you think would be doable/a good idea to do? Is it even possible to extract the code from a module import?
Quentin
The text was updated successfully, but these errors were encountered: