floschu / reaktor Goto Github PK

While writing a reactor that would cause a resource load to occur, I wanted to guard against loading the same resource… so naturally I would consult currentState in my mutate function… but then I started to think about threading. I had previously assumed that Reactor might provide some threading guarantees as other similar libraries do, but as far as I can tell DefaultReactor will emit Actions on whatever thread the ActionRelay is used from. Because of this, I believe a stale read of currentState could be possible. Do you agree?

Currently I am mitigating this (disclaimer: I haven't attempted to create a pathological scenario to test this out, so it's still conjecture) by using transformAction() to observeOn(Schedulers.single()). I'd love to hear your thoughts about this!

Also: thanks for writing such a clear & concise state management library for Android! It fits like a glove with our existing patterns, and we see ourselves standardizing on its usage across the app.

The flag crashInDebug which can be set with the Reaktor.handleErrorsWith() method is coupled to only escalate errors as app crashes if the library module is compiled in debug, as this flag is coupled with the libraries BuildConfig.DEBUG flag:

I would propose to either consider using another way to check whether the app is in debug (as for example ApplicationInfo.FLAG_DEBUGGABLE, which would add an android dependency into the core-reaktor), or decoupling the flag from a debug state and make it the developers choice / control, when the errors should be escalated as fatal crashes.

(Originally found here: diamirio/AndroidAppTemplate#11 (comment))