How can I "forward" the entire SwiftUI environment to another view? - swiftui

It seems that certain SwiftUI views create new environment contexts, such as NavigationLink. None of the environment is available in the new view.
As a workaround, I've been just manually forwarding through environment variables, like this:
struct ExampleView: View {
#EnvironmentObject var foo: UserStore
#EnvironmentObject var bar: UserStore
var body: some View {
NavigationLink(destination:
SomeOtherView()
.environmentObject(self.foo)
.environmentObject(self.bar)
) {
Text("Open View")
}
}
}
However this seems broken, as it violates the purpose of the environment. Also, it's confusing because it's not clear (or documented?) where these boundaries are and it causes a runtime error when a view depends on a missing EnvironmentObject.
Is there a better way to do this?
Similarly, I want to create a wrapper UIViewControllerRepresentable that can contain SwiftUI children (via UIHostingController) and I would like those children to have access to the environment as well.

Related

Updating a Class property with a GeometryProxy in SwiftUI before calling the PreviewProvider

I'm working in SwiftUI and have a GeometryProxy as a property of class used on a view & subview. My code is working fine, but I'd like the subview to render in Preview properly, but to do this, the PreviewProvider needs to have valid GeometryProxy data in a property (geo) of the class I've created (LayoutData). SwiftUI doesn't let me update an object's property as indicated in the comments in the code below. Is there some other way I might be able to get a valid GeometryProxy & use this to update a property in my LayoutData class when using the PreviewProvider? Code otherwise works great & I can run my Live Preview from the parent View, but it would be nice to see things rendered properly on my subview - which I could do if I could pass in my LayoutData object with a valid GeometryProxy property.
Really, all I need from the GeometryProxy is the screen width, so I could use just that in my LayoutData class, but I don't want to use UIScreen.main.width since this will be deprecated & I don't know of another way to get a valid width other than GeometryReader. Here is the code I've attempted, but of course, the comment line trying to update a variable property inside a View, as I've shown, can't be done in SwiftUI.
struct ButtonLayout_Previews: PreviewProvider {
static var previews: some View {
var layoutData = LayoutData()
GeometryReader { previewGeo in
layoutData.geo = previewGeo // You can't do this in SwiftUI
ButtonLayoutView(resultMessage: .constant(""), layoutData: layoutData)
}
}
}
I also know that I can introduce an additional, separate GeometryProxy property for the subview & pass that in as an extra property, using the GeometryReader setup, above, but I don't want to add an extra variable to my code if it's not needed & if I can use the Preview with the GeometryProxy property of my LayoutData class. Thanks for any ideas!
I was able to make the assignment using an empty let statement, and including the assignment after the equal, like below. Any concerns with this? It seems like I'm tricking SwiftUI into accepting an assignment where it normally wouldn't, but this works:
struct ButtonLayout_Previews: PreviewProvider {
static var previews: some View {
let layoutData = LayoutData()
GeometryReader { previewGeo in
let _ = layoutData.geo = previewGeo
ButtonLayoutView(resultMessage: .constant(""), layoutData: layoutData)
}
}
}

SwiftUI view updates even if it does not depend on a dynamic property

I created an ObservableObject that gathers data and a view that depends on this object. More specifically some parts of the UI depend on one property of it and other parts depend on other properties.
The way ObservableObject works is that if any of its Published property gets updated (event if it does not change) it sends an objectWillChange notification that triggers updates for subscribed views.
However, I did expect that only the parts of the views that depends on an ObservableObject property that actually changed would be updated, not the entire view because body computations are expensive.
Unfortunately this it not the behavior I observed during my experiments. For instance in the following code the List view depends only on the color dynamic property of the ObservedObject "preferences" and the TextField updates only the text property of the observed object. I observed with the debugPrint's that when I type text the List and its rows gets updated each time even if it does not depend on text.
struct ContentView: View {
#State private var list = ["foo", "bar", "baz"]
#StateObject private var preferences = Preferences()
var body: some View {
VStack {
List(list, id: \.self) { element in
Text(element)
.foregroundColor(preferences.color)
.debugPrint("Row view updated")
}
Spacer()
HStack {
TextField("Text", text: $preferences.text)
.debugPrint("Text field view updated")
Button("Toogle Color", action: toggleColor)
.debugPrint("Button view updated")
}
}
.padding()
.debugPrint("Content view updated")
}
func toggleColor() {
preferences.color = [.blue, .green, .orange, .red].randomElement()!
}
}
final class Preferences: ObservableObject {
#Published var color: Color = .blue
#Published var text: String = ""
}
extension View {
func debugPrint(_ elements: Any...) -> Self {
#if DEBUG
print(elements)
return self
#else
return self
#endif
}
}
Is this the correct and intended behavior? How the optimal behavior I described above could be obtained, i.e. not calling body when the ObservedObject changes but only the components that depends on specific properties?
I observed in bigger SwiftUI projects that this behavior can greatly slow down the application and is not easily debuggable because unique state is often enforced through heavy ObservedObjects (or StateObject) injected at the root view and used in many places. I Observed this behavior even with small lists of components with heavy UI layout.
Note 1: I was bugged by the StateObject definition which suggests that only the views that depend on those properties are updated (and not when the StateObject changes).
SwiftUI creates a new instance of the object only once for each
instance of the structure that declares the object. When published
properties of the observable object change, SwiftUI updates the parts
of any view that depend on those properties [...]
Note 2: The issue totally disappear if I define the List in its own component, the rendering is fast:
struct ListView: View {
let list: [String] // Also works with a #Binding
let color: Color // Also works if it would be `preferences`
var body: some View {
List {
ForEach(list, id: \.self) { element in
Row(text: element, color: color)
}
}
}
}
Why in this case the view updates are fast?

Observe Collection Results in Realm with Combine and SwiftUI

I am trying out this quick start for SwiftUI and Combine in order to try and understand how to connect my Realm database to Combine.
The example observes a RealmSwift.List and keeps a table populated with its data. This is is a linked list to a child class. I'm wondering how to observe a Results collection so I can keep track of any changes to an entire Realm class.
For example, let's say I have a Workspace class:
class Workspace: Object, ObjectKeyIdentifiable{
#objc dynamic var id = UUID().uuidString
#objc dynamic var name = ""
#objc dynamic var archived = false
}
In the state object, I can set up a Results<Workspace> variable like this:
class AppState: ObservableObject {
#Published var workspaces: Results<Workspace>?
var cancellables = Set<AnyCancellable>()
init(){
let realmPublisher = PassthroughSubject<Realm, Error>()
realmPublisher
.sink(receiveCompletion: { _ in }, receiveValue: { realm in
//Get the Results
self.workspaces = realm.objects(Workspace.self)
})
.store(in: &cancellables)
realmPublisher.send(try! Realm())
return
}
}
But when it comes time to observe the object, I can't because Results isn't an object (I assume).
struct ContentView: App {
#ObservedObject var state = AppState()
var view: some View {
ItemsView(workspaces: state.workspaces!)
}
var body: some Scene {
WindowGroup {
view.environmentObject(state)
}
}
}
struct ItemsView: View {
#ObservedObject var workspaces: Results<Workspace> //<!-- Error
var body: some View {
//...
}
}
Xcode gives a syntax error on the workspaces property:
Property type 'Results' does not match that of the 'wrappedValue' property of its wrapper type 'ObservedObject'
Is it possible to observe a set of Results just like we can have a notification listener on a collection of Results?
Technically, you could hook up a sink to state.workspaces (state.$workspaces.sink()), but in this case, I think you're overcomplicating the problem.
You already have an #ObservableObject in your ContentView (AppState) that is managing the results for you. So, change ItemsView to just take this as a parameter:
var workspaces: Results<Workspace>?
It doesn't need to be an #ObservedObject -- either way, whether it's getting observed in that view or it's parent view, it's going to get re-rendered. It does have to be optional here, since it's an optional value on your AppState, unless you want to keep passing it with the force unwrap (!), but that's generally a bad idea, since it'll crash if it ever is in fact nil.
Also, above, in your Realm code, make sure it's matching the tutorial that you were following. For example, you have Publisher.sink which should really be realmPublisher.sink
You are correct, Results is a struct, and therefore cannot be covered by #StateObject or #ObservedObject. Your workaround is suitable for now.
Once https://github.com/realm/realm-cocoa/pull/7045 is released, you will be able to use one of the new Realm property wrappers to embed your Results into the view directly. At the time of this posting, that would be #FetchRealmResults, but that is subject to change.

NavigationLink hides the Destination View, or causes infinite view updates

Let us consider the situation when you have ContentView and DestinationView. Both of them depend on some shared data, that typically lies inside the #ObservedObject var viewModel, that you pass from parent to child either via #EnvironmentObject or directly inside init().
The DestinationView in this case wants to enrich the viewModel by fetching some additional content inside .onAppear.
In this case, when using NavigationLink you might encounter the situation when the DestinationView gets into an update loop when you fetching content, as it also updates the parent view and the whole structure is redrawn.
When using the List you explicitly set the row's ids and thus view is not changed, but if the NavigationLink is not in the list, it would update the whole view, resetting its state, and hiding the DestinationView.
The question is: how to make NavigationLink update/redraw only when needed?
In SwiftUI the update mechanism compares View structs to find out whether they need to be updated, or not. I've tried many options, like making ViewModel Hashable, Equatable, and Identifiable, forcing it to only update when needed, but neither worked.
The only working solution, in this case, is making a NavigationLink wrapper, providing it with id for equality checks and using it instead.
struct NavigationLinkWrapper<DestinationView: View, LabelView: View>: View, Identifiable, Equatable {
static func == (lhs: NavigationLinkWrapper, rhs: NavigationLinkWrapper) -> Bool {
lhs.id == rhs.id
}
let id: Int
let label: LabelView
let destination: DestinationView // or LazyView<DestinationView>
var body: some View {
NavigationLink(destination: destination) {
label
}
}
}
Then in ContentView use it with .equatable()
NavigationLinkWrapper(id: self.viewModel.hashValue,
label: myOrdersLabel,
destination: DestinationView(viewModel: self.viewModel)
).equatable()
Helpful tip:
If your ContentView also does some updates that would impact the DestinationView it's suitable to use LazyView to prevent Destination from re-initializing before it's even on the screen.
struct LazyView<Content: View>: View {
let build: () -> Content
init(_ build: #autoclosure #escaping () -> Content) {
self.build = build
}
var body: Content {
build()
}
}
P.S: Apple seems to have fixed this issue in iOS14, so this is only iOS13 related issue.

onReceive in SwiftUI view causes infinite loop

In a SwiftUI app, I have an ObservableObject that keeps track of user settings:
class UserSettings: ObservableObject {
#Published var setting: String?
}
I have a view model to control the state for my view:
class TestViewModel: ObservableObject {
#Published var state: String = ""
}
And I have my view. When the user setting changes, I want to get the view model to update the state of the view:
struct HomeView: View {
#EnvironmentObject var userSettings: UserSettings
#ObservedObject var viewModel = TestViewModel()
var body: some View {
Text(viewModel.state)
.onReceive(userSettings.$setting) { setting in
self.viewModel.state = setting
}
}
}
When the UserSettings.setting is changed in another view it causes onReceive on my view to get called in an infinite loop, and I don't understand why. I saw this question, and that loop makes sense to me because the state of the ObservableObject being observed is being changed on observation.
However, in my case I'm not changing the observed object (environment object) state. I'm observing the environment object and changing the view model state which redraws the view.
Is the view redrawing what's causing the issue here? Does onReceive get called everytime the view is redrawn?
Is there a better way of accomplishing what I'm trying to do?
EDIT: this is a greatly simplified version of my problem. In my app, the view model takes care of executing a network request based on the user's settings and updating the view's state such as displaying an error message or loading indicator.
Whenever you have an onReceive with an #ObservedObject that sets another (or the same) published value of the #ObservedObject you risk creating an infinite loop if those published attributes are being displayed somehow.
Make your onReceive verify that the received value is actually updating a value, and not merely setting the same value, otherwise it will be setting/redrawing infinitely. In this case, e.g.,:
.onReceive(userSettings.$setting) { setting in
if setting != self.viewModel.state {
self.viewModel.state = setting
}
}
From described scenario I don't see the reason to duplicate setting in view model. You can show the value directly from userSettings, as in
struct HomeView: View {
#EnvironmentObject var userSettings: UserSettings
#ObservedObject var viewModel = TestViewModel()
var body: some View {
Text(userSettings.setting)
}
}
You might be able to prevent infinite re-rendering of the view body by switching your #ObservedObject to #StateObject.