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

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.

Easiest thing to do would be runtime exceptions. Then you could use multiplatform to

expect

an implementation of

MainThreadChecker

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

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

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.