https://kotlinlang.org logo
#redux
Title
# redux
a

andreworobator

08/28/2019, 7:40 PM
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
p

Patrick Jackson

08/29/2019, 12:44 AM
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.
Enforcing main thread(or the same thread) may be an option too by forcing a crash similar to Android
a

andreworobator

08/29/2019, 1:18 AM
Easiest thing to do would be runtime exceptions. Then you could use multiplatform to
expect
an implementation of
MainThreadChecker
p

Patrick Jackson

08/29/2019, 12:51 PM
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
a

andreworobator

08/29/2019, 1:19 PM
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
p

Patrick Jackson

08/29/2019, 1:54 PM
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.