A NavigationLink in VPNProviderContentModifier raised a few questions
about the navigation approach in module views. It turned out that having
a Binding to a local ObservedObject (ProfileEditor) is a recipe for
disaster.
Therefore:
- We don't need a binding to the editor module (the draft), because by
doing so we end up _observing_ the same changes from two properties, the
binding and the editor. This seems to drive SwiftUI crazy and freezes
the app once we navigate from the module to another view (e.g. in
OpenVPN the credentials or the provider server). Use the module binding
as a shortcut, but do not assign the binding to the view to avoid
unnecessary observation.
- Keep .navigationDestination() in the module view, and pass a known
destination to VPNProviderContentModifier. This will save the modifier
from creating a nested NavigationLink destination. The
VPNProviderServerView is now openly instantiated by the module view when
such destination is triggered by the NavigationLink in the modifier.
- Do not implicitly dismiss VPNProviderServerView on selection, let the
presenter take care. In order to do so, we add a .navigationPath
environment key through which the module view can modify the current
navigation stack.
- Move disclosable menu from installed profile view to
ThemeDisclosableMenu
- Drop unnecessary configurationType modifier parameter
- Reorg view-related module extensions to separate files
- Reuse .flow fields instead of single blocks
- Show specific error on missing provider server selection
Initial integration of providers via API:
- Generic views and modifiers for provider/server selection
- Add in OpenVPNView
- Prepare in WireGuardView
Also:
- Introduce ProfileProcessor, move IAP processing there
- Move .asModuleView() to ModuleViewModifier for proper animation
- Use .themeModal() rather than .sheet()
