2 comments

[ 3.6 ms ] story [ 14.7 ms ] thread
It's not oriented specifically at state-sync'ing, but Comlink[1] comes to mind.

> Comlink.wrap(endpoint) and Comlink.expose(value, endpoint?) Comlink’s goal is to make exposed values from one thread available in the other. 'expose' exposes 'value' on endpoint, where endpoint is a postMessage-like interface. 'wrap' wraps the other end of the message channel and returns a proxy. The proxy will have all properties and functions of the exposed value, but access and invocations are inherently asynchronous. This means that a function that returns a number will now return a promise for a number.

Creating & exposing an EventEmitter in the main thread then proxy'ing it on each other thread ought create a reasonably similar experience to this Tangle library. The docs themselves discuss some of the extra difficulties if one is trying to proxy DOM Events[2], talking about this as a common usage pattern, but which is complicated by DOM Events not being cloneable.

For another example of Comlink in action, there's this blog post on using Redux across threads[3].

[1] https://www.npmjs.com/package/comlink

[2] https://github.com/GoogleChromeLabs/comlink#transfer-handler...

[3] https://dassur.ma/things/react-redux-comlink/

Super interesting indeed. Thanks for sharing! It'd be nifty but also scary if one could just proxy away the sandbox's walls. Which is basically why Tangle embraced the idea of defining a Message-passing interface for shared application state. Will take a closer look at Comlink. Seems like a perfect solution for offloading expansive computations to a thread/worker where simplicity is desirable and modeling around user-interactions is absent or limited.