Our main goal with the Reader has been to implicitly pass down our dependencies along the whole execution tree. We talked about the possibility to use that as a way to mock dependencies at testing time. This lesson is showcasing it with a very clear example. Learn:
- The Reasons and benefits of using the Reader from the perspective of end to end tests.
- Recap on the dependencies we abstracted and the reason for it.
- How to test your system passing in a Reader context providing mocks.
- How to disable threading for tests by passing in a stub for the background runner collaborator.
- How to disable real view rendering, navigation or API queries by passing mocks for those that we can keep control over for later configuration.
- How to test a couple of key scenarios for our example that cover the whole execution tree almost end to end in a black box scenario.
Great course, perfect blend of theory and practicality. Am interested will you make course about Functional Clean Architecture with Kotlin and Arrow? You left sample code and its great just there are many examples. Should we still use classes or go only functions? In tagless-final example you use classes everywhere, probably that could be made into interfaces or something (tell me if am wrong am still new to this and I haven't tried to refactor), and in IO, monad stack examples there are only functions. Is this just for diversity or not? I really love the idea of functional programming and I have started to go deep into Arrow and functional programming in general and I think that course like that could help not just me but many other people.
Thanks! I'm glad you found it useful. Definitely agree about doing a FP course architecture oriented. Arrow still needs to evolve a bit to do that in a good way for Android though (we need Arrow streams to handle lifecycle properly which is a module that will come during next year) so I'm waiting a bit to build up those examples. I'll do it at some point during next year.
For now I'd recommend watching the FP course here in Caster and taking a look at these examples https://github.com/JorgeCastilloPrz/ArrowAndroidSamples which are a bit outdated but could bring some light meanwhile.
About using classes or not, I'd not say using classes is an error, but is probably more error prone. Many times you can encode all your operations based on pure functions that do not necessarily need to live under an enclosing class, since the class state remains irrelevant (if the functions are pure, they just operate with their inputs and provide a result, not accessing any external state). Having a class is opening the door to putting some state on it which is something we want to avoid.
Said that, some styles like Tagless Final rely on using type classes (which are interfaces) and instances for those, which are actual classes implementing those behaviors for a given data type, so you'll end up using classes there for sure in the runtime for your implementation details.
Also FP in FP you operate over immutable value objects which are your domain models for example, which are most likely gonna be data classes.
So to me there's not a strong need to remove classes but mostly be coherent on how to use those to achieve a proper pure typed FP style.
Am glad to hear that:D. I have looked into those samples and they have helped me a lot. Currently I use implementation with ViewModel basically doing what is done in Activityies in those samples. I have some problems with DeferredK and how async works, am not sure am I not getting it right or its a bit involved to start async process in CoroutineScope and CoroutineContext you want to work in but I think I have got it right:D (basically every function used to start coroutines is running in GlobalScope and it can be a bit of work to pass your own context so you are being resource friendly and cleaning everything that is not needed so its not tied to whole application even if you don't use it any more). Am looking forward to that course. Take care!