Yeah, this is where I think we’re going to have the biggest disagreement. A lot of the applications I work with are financial, where it’s sort of, kind of considered to be somewhat important that the logic around data management and manipulation be correct.

In other words, that it exists somewhere it can be tested. Previews are handy, but can’t be automated to test logic that might be disturbed should should a change in a dependent service propagate all of the way back up to a given view.

I was waiting with interest to see how you were going to manage the “AccountList(data: mock)” trick, but you instead punted and showed how to implement a generic loader that ignored the simplified data you promised to pass into the view. Too bad.

You railed a bit against view controllers and I totally agree. Unfortunately, they exist in UIKit and since that’s how most views and outlets are wired together we were kind of stuck with them. Moving as much logic as possible to the VM was how we combated the massive view controller issue and, in SwiftUI, is ONE of the ways we combat the problem of massive-view-bodies.

A prime example is shown in your embedded task {} function which is now doing work (including not handling errors) that can’t be tested and proven correct under all scenarios. Add the needed error handling to that example, and again all you’ve done is increase the amount of non-testable, non-reachable code.

If you’ve read any of my other articles, you’ll tend to see that I’m a huge fan of view composition and that I want my views to be as small and lightweight as possible. In fact, I’ve been rather adamant about the fact that I don’t believe each and every view requires a view model. But if they do exist, they should be as small and lightweight as possible. Definitely not “dumpsters for anything and everything”.

Unfortunately, in the real world, requirements tend to be complicated, and the output of a given view may be a function of API data from several sources, app settings, user settings, a/b testing and feature flags, or require the use of data loging and analytics systems.

And in those cases, view models are where that work and the mediation between all of those different services occurs.

And again, that logic needs to be tested to ensure that errors and edge cases are properly handled. That may not be a consideration in the kind of applications you push out the door and that’s fine. But it is in mine, and it’s aa example that I tend to propagate in the articles I write.

But since you seem to consider dumping tests to be a benefit, I’m afraid we’re going to have to agree to disagree on that point. And I’m good with that.

Thanks for reading and the comments.