ReSwift VS kotlin-result

Check this out: https://github.com/ReSwift/ReSwift

There are some great examples linked to the ReSwift GitHub page: https://github.com/ReSwift/ReSwift

ReSwift is also pretty good!

ReduxKotlin There are a few ports of Redux for KMM. This one might be the best because it is thread safe, which is very nice. The only drawback that I don't love about it is that it doesn't have types for sevral aspacts that feel like they should have types. On the other-hand ReKotlin (which is a port of ReSwift) has a lot of the typing that ReduxKotlin is missing, but is missing the thread safety. It just depends on your use-case.

Great article OP! Im sure you've seen it in your travels, but Ive been using ReSwift and ReSwift-Thunk for async actions and I've had great success - Gonna look into your navigation solution as that was the one part I'm still missing!

I recommend you checkout the code base of ReSwift

Author here. I have no idea what you could possibly mean with this comment. The coroutineBinding implementation correctly uses the coroutines API for parallel decomposition of Result bindings, exactly how the Kotlin Corotines guide tells you to (backed by a [Mutex](https://github.com/michaelbull/kotlin-result/blob/master/kot...)). The coroutineBinding isn't even the main selling point of the library, you can use it without using this feature entirely.

Please could you elaborate on what "looking thread safe" means to you? The only portion of the library that supports concurrency *is* thread safe - the unit tests prove it and the use of concurrency primitives such as Kotlin's Mutex are indicative of this. I truly have no idea how you've judged the entirely of the lbirary on whether it's "thread safe" when there is a single function that's related to concurrency and it is very clearly using concurrency primitives.

Sealed classes in combination with a library like https://github.com/michaelbull/kotlin-result will get you what you need. Essentially at that point you'll be doing error handling the way you would in Rust, where a 1-level deep sealed class containing data classes as children act as the root error type and each of its variants. If you have errors coming from two different domains you just create a wrapper error type for each domain.

This is a great result lib: https://github.com/michaelbull/kotlin-result

Lastly I do not like kotlin's Result and we use the kotlin-result library which is more expressive and not tied to Throwable (similar to Arrow's Either).

In my own code, I started to use explicit error handling. I'm currently experimenting with Result (from https://github.com/michaelbull/kotlin-result) and Raise (from https://arrow-kt.io/).

un-related to multiplatform i've found it extremely helpful to wrap things in a Result type. If something can throw an error, it get's a Result return type. It sounds like that would help your use case too. The built in Result may be useful too

This is a better impl.

Using a result type can help to differentiate quite nicely. https://github.com/michaelbull/kotlin-result

kotlin-result