Platform: Run reducers inside web workers?

[Aaron-Sterling]

I'm submitting a...

[ x ] Documentation issue or request

What is the current behavior?

No discussion I've been able to find (either officially or unofficially) about combining ngrx with web workers.

Expected behavior:

Documentation do's and don'ts about ngrx and web workers.

Other information:

Some of my reducers sort arrays and/or make new copies of them. This seems like a natural(?) fit for a function that could take place in a web worker. Good idea/bad idea/makes no difference to long-term execution since store.dispatch might run in the background already?

Thanks very much.

:heartpulse: ngrx? Please consider supporting our collective: 👉 donate

[robwormald]

Theoretically, this is possible, but the cost of serializing/deserializing the state on every change (no memory shared with a worker, so you'd have to postMessage(JSON.stringify(state)) is likely to outweigh any gains. Communication with a worker is necessarily async, whereas store's API is all sync.

It makes more sense for Effects - there's already an open issue for that.

[phenomnomnominal]

Could SharedMemory alleviate some of the performance concerns?

[sandangel]

Hi everyone, I've found this great library from creator of Preact.js: https://github.com/developit/stockroom.

Is this feasible to offload entire ngrx store, effect, reducers.. to a web worker and angular can communicate with it by a service like this: web-worker.service.ts

If it could, it would be a huge performance boost for angular application. and you won't have to run entire angular in web worker which I guess will introduce more overheads (until now it's still an experimental feature)

[brandonroberts]

See https://twitter.com/MikeRyanDev/status/954151139968249857 😉

[sandangel]

Hi @brandonroberts, I'm investigating on this topic because I have trouble with large entities ( > 10000 object ). After get data from server and put it into store, my application totally lost interaction. I plan to wrap entire ngrx/store and effects into a service which has a same API with Store and run the store in Web Worker. As you has point out that could make everything around 350ms slower, but it can be acceptable when you have to handle a large entities without blocking the main thread. What do you think?

[developit]

FWIW, I don't think @sandangel's point was adequately investigated here, so allow me to expand: Stockroom mitigates the serialization issue by applying a simple recursive diff algorithm to state tree updates. It's not a naive "pass state to the main thread" approach, and worth reading its small source code to understand why.

It's quite likely ngrx could employ the same technique, and the result would be beneficial. Also, from what I understand ngrx allows scoped/reduced state observation (which is to say, observed paths are explicit and known in advance), which allows for even further reduction in postMessage traffic.

[MartinFreire]

I have the same problem as @sandangel
I have an internal app for a company that uses the app on remote places with low access to internet
So I used firebase to cache the results and try to provide a better user experience, turns out firebase doesn't handle low internet that well and the querys take way too long, so my next step was to setup a store but same problem, I have around 10k records and thought that moving that to a worker would be ideal, turns out that as it's not a common case, there is little progress with any library and my options are really limited

Having this working would help a lot in a lot of really specific cases, I'm working on a new project for an hybrid app that handles a lot of things at the same time, intervals for alarms, printing receipts, pulling from server, handle user interactions. Something like this will really make use of a good worker to split work across threads