A modern programming language that makes developers happier.

kotlinlang

Trying to upgrade orbit from `4.2.0` to `6.1.0`. Not able to find how we provide custom `CoroutineDispatcher` for intents. Earlier, there used to be one parameter `intentDispatcher` in the `Container.Settings` class constructor

<@UPWE6PJCE> have raised a <https://github.com/orbit-mvi/orbit-mvi/pull/203|PR> for adding these. Let me know your thoughts on same

<@U012XUA5E79> We removed it because it was not needed for testing (you can set the dispatcher in test options), and having the option to set it for production code seemed unnecessary and dangerous.

As far as testing goes, I personally find there is limited value in overriding the dispatcher. I've literally never done this for the ViewModels I wrote and tested in a large code base. This is even more true if you're using the new testing framework, there should be no need to set the dispatcher in 99% of cases.

*In the 1% case, you can still set the dispatcher in the test settings:*

```// Old test framework
MyContainerHost().liveTest(
    buildSettings = {
        dispatcher = myCustomDispatcher
    }
)

// New test framework
MyContainerHost().test(this,
    settings = TestSettings(
        dispatcherOverride = myCustomDispatcher
    )
)```


IMG_8176.png

<@UPWE6PJCE> But I noticed by default you use `Dispatchers.Default` for intent. What if I want to change this to `<http://Dispatchers.IO|Dispatchers.IO>` or some custom dispatcher of dedicated thread pool. 

Also, when we try to run this with `runTest { }` from kotlinx-coroutines-test, it should get replaced with `UnconfiedTestDispatcher` to avoid any unexpected issues in the test

I remember this slide from Dev Summit’19 on Testing coroutines in Android. Not able to understand how things have changed lately

&gt; But I noticed by default you use `Dispatchers.Default` for intent. What if I want to change this to `<http://Dispatchers.IO|Dispatchers.IO>` or some custom dispatcher of dedicated thread pool.
Can you give a specific example of why you would need to do that? You can always switch the coroutine context on a case by case basis within your intents or use cases.

&gt; Also, when we try to run this with `runTest { }` from kotlinx-coroutines-test, it should get replaced with `UnconfiedTestDispatcher` to avoid any unexpected issues in the test
This is a pretty large topic to discuss :sweat_smile: Here is my take on it:
1. 99% of code in mobile apps is not truly concurrent and can be tested without any special ordering requirements, so injecting dispatchers is in most cases unnecessary.
2. Orbit should be treated as a black box - just as the caller doesn't have to know what context a suspending function is running in.
3. By changing orbit's dispatchers you are artificially changing how the code behaves under test - in a way you are departing from testing actual production code
4. Only inject dispatchers where it's necessary. For example, we inject the dispatchers only for our network layer.
5. Coroutines testing has changed a lot since 2019 - these days I find that largely I don't have to change the code under test so much, as `runTest` ensures safe testing of coroutines
6. Orbit's new testing framework is designed to work with `runTest` to ensure you don't need to mess around with dispatchers in the 99% case.
