Checklist

• [x] I've looked at the contribution guidelines.

Description

Been doing some experimentation on having SwiftUI views to depend on an abstract model. The model could then be injected and have mock representations for testing.

Pros to this approach

• Ability to control surface area of Bindable properties
• Extracts some responsibility away from SwiftUI view
• SwiftUI view can now depend on an abstract type rather than concrete

Cons

• Binding<Value> requires a backing property; You will need a separate variable to hold the state of the Binding:

var _email = ""
var email: Binding<String> { return .init(getValue: {  self._email }, setValue: { self._email = $0 }) }

• Unable to harness the power of property wrappers
• Compiler complains if you try to use a struct type that exposes a Binding (binding requires a way to mutate some backing property, which violates the value semantics of the struct)

Asking for opinions on whether this is a good idea or not. Relevant thread with some opinions from Joe Groff: https://forums.swift.org/t/state-messing-with-initializer-flow/25276/8

Checklist

• [x] I've looked at the contribution guidelines.

Description

Adds contents into NewRideView. Adds red placeholder for map view. Adds 'Where to?' button. Adds profile image (which will be a button) to the top right using an SF symbol.

Checklist

• [x] I've looked at the contribution guidelines.

Description

Adds indicator view to display when finding user's current geographic location.

Checklist

• [x] I've looked at the contribution guidelines.

Description

Views that exist within scopes that come and go (such as authenticated user scope) can capture their fixed scope as property values rather than reaching through the app's state. Reaching through the app's state requires dealing with optionals and leads to force unwrapping values. This PR adds constant value properties on views to capture scoped state values.

Checklist

• [x] I've looked at the contribution guidelines.

Description

Cleans up view hierarchies for onboarding screens. Decomposes components into individual views and improves visual layout.

Checklist

• [ ] I've looked at the contribution guidelines.

Description

Adds user and user auth models to thread information such as user profile and auth token information through the app. Adds user display name to new ride screen.

Checklist

• [ ] I've looked at the contribution guidelines.

Description

Adds root dependency container to remove dependency resolution from the Koober state store.

Brief

The app has non-optimal iPhone X layout, as depicted in the screenshot in #17

Just ran into a tip in the "Building Custom Views with SwiftUI" WWDC talk that should alleviate this:

.edgesIgnoringSafeArea(:)