Feature/project scaffold

[sebastian-nunez]

Feature/project scaffold

Description

Adds the basic project scaffold and folder structure.

For the project, we will heavily use dependency injection and the MVVM architecture to make our code more modular and reduce coupling.

Dependency Injection in Action

// Without dependency injection
class Foo {
    let bar: Bar = Bar()
}

// With dependency injection
class Foo {
    let bar: Bar

    init(bar: Bar) {
        self.bar = bar
    }
}

Essentially, in the 2nd example, you can see that Bar is a dependency and it's passed in through the constructor. This way, we could sub-in/swap out different implementations of Bar.

Model-View-ViewModel

1. Model: data layer which defines what the object looks like.
2. View: displays the actual SwiftUI component and data (should not have much business logic)
3. ViewModel: used to manipulate data. This piece interacts with services and models

View and ViewModel should be kept within the same folder. For a Login "page", we name the view and view-model like this LoginView and LoginViewModel (this applies to all pages or components)

- Login
  |- View
  |  |- LoginView.swift
  |  |- (Other view files)
  |
  |- ViewModel
  |  |- LoginViewModel.swift
  |  |- (Other ViewModel files)

Folder Notes

• Core: stores all major views or section of our application (ex. Login, Home, TabBar Search...)
  • RootView is the primary view. This is where we can control wether to display the login/auth screen or the home screen depending if we have a logged-in user
• Services: this is where we'll abstract complex business logic or operations. Read more about the service layer
  • For all services we make, we want to create Protocol definition for each
  • Services are implemented as a Singleton. Meaning the constructor is private and you can only access the methods/fields via a static field named shared. This allows us to create a single instance of the service to be used across the application.
  • Add at least 1 single top level swift-doc comment using ///.
  • Why? This allows us to create multiple services and swap them out as needed. Services should NOT be directly used inside of Views, instead we have to inject them into a ViewModel
• Models
  • For each model, add an Extension as a static var mock which will help us while generating previews.
  • Styles: any custom styles can go here. ex. PrimaryButtonStyles, or a CardStyles