MuseumShuffle, 16 days ago

I can somewhat recreate it with a sample project.

1/3 split view and 1/2 split view show the message, cancel button, and action button. 2/3 split view and full screen do not show cancel button.

An alert instead of a confirmationDialog works fine in all scenarios.

I'll file feedback later.

#SwiftUI

teissler, 15 days ago

8. Now that we know what view-destination links and value-destination links are, we can explore the data modeling behind NavigationStack. Today we look at another form of view-destination navigation: navigationDestination(item:destination:). It takes a bound item and presents a view when the item is non-nil. Despite taking a binding to an item, this is not a value-destination link. In today's code example, a few different types of links are composed together.
   #SwiftUI

Xcode Previews with an iPhone showing a NavigationStack and various kinds of navigation. First, a value destination link is pushed appending the value “Hello” to the stack. The newly pushed view has another value-destination link in it that appends the value “World” to the stack when pushed. The preview is popped back to the root view. Then, the button is pushed, populating the item binding and pushing the declared bound-item navigation destination. From that view, the value-based part of the stack is terminated — no further values can be appended until that view is popped off the stack. However, any number of additional view-destination views can still be pushed onto the stack. The first view-destination view then uses a view-destination fire-and-forget link to push a mint view-destination view. Code: https://gist.github.com/nteissler/0634aeafe5eae385d2b147459e8f7b6c

teissler, 15 days ago

8 cont) There are two important concepts this demo shows: 1️⃣ A NavigationStack's path is a run of 0 or more values, followed by a run of 0 or more views. The video calls out "You can not push more value-destinations." once the first view-destination view has been pushed. This is why it's helpful to know the difference between view- and value-destination links. It's fun (IMO) to reason out why this is:
#SwiftUI

teissler, 15 days ago

8 cont) Imagine a path that allowed pushing values after pushing views, so a path was [1, 2, 3] ViewA, ViewB, [4]. In NavigationStack's API, the path would be [1, 2, 3, 4] with two Views somewhere along the path. Given just that state, it's not possible to construct the state of the app. We can't know when the view-destination views were pushed, and which view should be on top of the stack.
#SwiftUI

teissler, 15 days ago

8 cont) It takes more than a few toots to fully explore this concept, but it is problematic if app state depends on how we got there + the state itself. 2️⃣ The second concept we see here is the first example of picking the right navigation tool for the job. navigationDestination(item:destination) is often overlooked in favor of the deprecated NavigationLink(isActive:destination:). A get/set binding is used for the isActive binding that maps an item to the Boolean value under the hood. #SwiftUI

teissler, 15 days ago

8 cont) When possible, it is advisable to use the item-bound navigationDestination, rather than the deprecated API. When using NavigationLink(isActive:destination), especially in a List, that makes your app state a function of the path AND whether or not that link is in existence (e.g. scrolled on screen). The best way to model this instead, is whether or not the item binding is populated, which is the contract of the modifier.#SwiftUI

teissler, 15 days ago

8 almost done) Another reason the NavigationLink(isActive:destination:) is deprecated is that it leads to mini update cycles when used in this way. the cycle looks like this: (a) user taps link (b) link view updates attempting to set it's isActive binding to true (c) the get/set binding kicks in its side effect of setting some item binding elsewhere (d) link view updates again because the isActive binding depends on the item binding. The loop terminates there and is sometimes harmless #SwiftUI

teissler, 15 days ago

8 last one) These mini update cycles are sometimes harmless, but the more complex and app gets, the more work is being done, bindings updating, environment propagating, the higher the chance that the mini-update cycle causes some state change to not propagate correctly. SwiftUI is robust against this and will cut off cycles when it detects them. But it is best avoided, thus, pick the right tool for the job #SwiftUI

teissler, 15 days ago

9. Today we look at navigationDestination(isActive:destination:), the boolean form of yesterday's modifier. The same guidelines apply, and here is one more: don't use them in lazy containers. Tying the existence of navigationDestination to whether or not contents of a List have been lazily loaded commits the error again (see Day8) of making navigation state a function of scroll state, AX/dynamic type size (larger type -> fewer rows scrolled on screen), size class, etc. #SwiftUI

teissler, 15 days ago

9 cont) I've seen some code bases substantiate this construction with modularity. For example, the app's root view may be a List, each team that works on the app adds their feature like:

List {
Feature1()
Feature2()
}

And within those features exist .navigationDestination modifiers. Swift gives facilities for staying modular, and still moving those destinations outside the List. That's how to get robust deep linking, not subject to difficult to debug conditions like device size #SwiftUI

teissler, 13 days ago

10. onAppear and onDisappear are not your friends when it comes to tracking navigation state — is it technically possible to track state like this? Yes, but brittle because you've made two sources of truth. If you've ever wondered why onDisappear isn't called when a view in a stack has one pushed atop it, imagine ViewA has @State or some timer that updates a dependency of ViewB. (ViewB is pushed on top of ViewA). ViewA can't be removed from the graph – it is still a dependency of ViewB #SwiftUI

teissler, 13 days ago

10 cont) by the way, the system takes care to forward these dependencies efficiently. If ViewA has some observable property that updates over time, and ViewB captures that property in a navigationDestination, ViewB will update when the property of ViewA changes. Try putting an Observable at the root of a NavigationStack and updating the observable on a timer. Capture it in a NavigationDestination and watch the pushed view update too. #SwiftUI

teissler, 12 days ago

11. We dive deeper into navigationDestination. We learned yesterday the closure passed to navigationDestination is reevaluated when its dependencies change. This keeps the destination presented by a navigationDestination up to date with the values captured by the closure. Be aware of how much you are capturing inside this navigationDestination closure! When you build up a stack of views with a NavigationStack, you might be building up a complex dependency graph — thus, cycles. #SwiftUI