If that's a requirement, i would make thread confi...

# redux

[andreworobator]

If that's a requirement, i would make thread confinement enforced by the library, just like Android enforces not accessing UI on the main thread. The critical block is probably with subscribe and dispatch. If you have multi-threaded subscribes, that changes the list of listeners, not necessarily all of them got in the list. Then if you dispatched, the listeners.forEach could have listeners mutated right in the middle of the loop which would be weird

[Patrick Jackson]

Valid concerns and something to keep in mind. Any ideas for solutions? What I have explored is using a middleware that launches next() in a coroutine context, so the rest of the chain is in that context. The sequence needs to be guaranteed though, and I believe that is not the case when launching coroutines. Flowables/channels may be interesting. Also might be worth looking at the javascript world. There may be some inspiration here(https://dassur.ma/things/react-redux-comlink/), though the JS world has whole different set of restrictions.

[Patrick Jackson]

Enforcing main thread(or the same thread) may be an option too by forcing a crash similar to Android

[andreworobator]

Easiest thing to do would be runtime exceptions. Then you could use multiplatform to expect an implementation of MainThreadChecker

[Patrick Jackson]

yep. I would like to have the ability to use a different thread also though. It would be good not to force redux code on the main thread

[andreworobator]

How about whatever thread the first dispatch is called on is the confined thread? Then on subsequent calls you check if you're on that thread

[Patrick Jackson]

perfect. checking in the dispactch function in createStore? With middleware, that would put the check at the end of the chain, right before the reduction, which I think is what we want.