Pure functions? What about Pure view models?
In my last article, I wrote about pure functions, what they are, and why they are awesome. This is the second part of a three-article series I am writing that goes into the concept of pure code.
In this article, I will be converting an impure viewModel into a pure one. I will show you how it's difficult to write unit tests for impure viewModels and how it becomes super easy once they are pure.
Below is a very common viewModel setup you might find in many codebases.
(Wondering what ImpureNameViewModelTypeis? Read this article)
Right off the bat, we can see that this viewModel is not Pure. It makes a request to the server, thus changing the state of the server you are consuming, meaning this viewModelis not pure. Secondly, we should ask ourselves what the input of the viewModel is. I guess you could say that the server response is the input, but this is not passed in. The viewModelalso suffers from having multiple responsibilities. It makes a request and it handles the response. How would we unit test this? You can mock the request and have full control of the server response. To do this, I could point you to "request mocking libraries", but now we need to also provide a mock value, that will probably be in JSON format meaning probably want to add JSON files to the project. All this can get very ugly very quickly (I'm not going to show this example).
So how do we solve all these issues? Let’s think about or decide what the responsibility of this viewModel actually is. I would argue that the responsibility of theviewModel is to update the values/state of its view given the server response. With that in mind, how can we redesign this viewModel to make it pure?
So is this pure? Absolutely, Given the input (response) we will always get the same output (name). We also fixed the single responsibility principle. This viewModel now is only responsible for one thing and one thing only, converting the response to the name value.
Look at how easy we can test out theviewModel now.
I know what you are probably thinking: who makes the request? The loading state is gone, you are just moving code around and pushing the logic elsewhere. The variable name is mutable, so anyone can change it. All are very valid observations, but to answer these questions we need to talk about an even bigger architectural picture.
In my next article, I will be making this viewModel reactive using Combine. This will clear up some of the observations above and will make this viewModel look a lot nicer. In future articles, I will be addressing all of the points above by taking a wider view of code architecture and patterns that you can use to have pure code.
If you liked this article please follow me and show your support with a clap. If you want to read my other articles, below is a list.
Example Code:
https://github.com/TerrickMansur/ArticlesCode
My articles:
1. The missing piece of MVVM
Get in touch:
