Swift Concurrency Lesson 2 - VOODO and Creating the UI

This is the second of 6 videos in the Swift Concurrency series.
In this video we will be introduced to VOODO, a modified MVVM design pattern so that we can create viewmodels and views to display the content that we fetch from our API endpoints.
We will also be seeing how we can use MockData so that we don't have to always make calls to the API when we design our apps and you will also be introduced to Git Source control using Xcode.

Links and Resources

Swift Concurrency Series Playlist:

Starter Code Completed Source code for Part 1:

Part 2 Completed Code:

Timestamps
0:00 Introduction
0:42 Introduction to VOODO
1:09 Renaming ContentView
2:06 Creating the UsersListViewModel
7:18 Creating and using Mock Data
15:28 PostsListViewModel and View
21:26 Suppressing Constraint Warnings
24:00 Source Control

🚨 SPECIAL CWC+ OFFER FOR YOUTUBE:

MY FREE ONLINE COURSE:

CWC+ PROGRAM:

WEEKLY UPDATES VIA EMAIL:

CONNECT:

ABOUT CODEWITHCHRIS:

DID THESE LESSONS HELP YOU?

ROADMAP:

[richardalbury]

Great video, thanks! However, I think there's a problem with the use of the mock/static data: you're still hitting the endpoint in the fetch calls. It's better to handle this at the target level, but my crude and simple workaround is to add code to the fetch calls that looks something like this:

#if DEBUG
if posts.count > 0 {
return
}
#endif

I also modified the mock data so the first item shown is clearly mock data, such as here in the posts data:

[
{
"userId": 1,
"id": 1,
"title": "Mock post title",
"body": "Mock post body"
},

[montyboyer]

Thanks to Stuart & Chris, this is great stuff. So many excellent tips for using Xcode as well as Swift. I did hear a reference @ about 9:50 for a link related to the extension bundle, but I don't see that one with the other links.

[DavidInga]

Fantastic video! I agree that writing a warning isn't ideal for your mock data. Couldn't you initialize a separate UsersListViewModel in your UsersListView_Previews? Perhaps you could accomplish this by not initializing your vm inside of UsersListView. Then you could pass an instance of UsersListViewModel when you create the instance of UsersListView, both inside your UsersListView_Previews and when your app first loads.

[ItsJustFil]

Instead of the warning, you can wrap the VM in an #if DEBUG compiler flag like this.

#if DEBUG
@StateObject private var viewModel = true)
#else
@StateObject private var viewModel = UsersListViewModel()
#endif

[FelipeRolvar]

could be even better if you can inject the APIService so you can replace with a mock version of it and that one is the one encouraged to grab the mocked data, also VM needs to be injectable so when you create the preview you inject the viewModel with the mock APIService implementation, it is best practice and also no warnings o code change for shippable version needs to be done