Exposing more detail about the navigation path

[gmedori]

I'm working on a project where I need to keep two separate navigation stacks in sync; the reason is that the stack hierarchy changes depending on the horizontal size class (in regular I show a single split view whereas in compact I show two separate views on the stack, a list and a detail view).

What do you think of exposing more details around the navigation path and publishing when changes happen to the path? This would enable a large degree of flexibility for manipulating the path as needed.

I believe this would require using something other than Swift.NavigationPath as the path provided to the navigation stack. In a rudimentary attempt to do this myself, I swapped the type of the path variable in Navigator from NavigationPath to [AnyNavigationDestination] and I ran into lots of trouble. In particular the type erasure broke all sorts of functionality, so I understand it's nontrivial.

If this approach seems too odd to be appropriate for the library, do you have any possible ideas for how I might achieve this changing of the navigation stack based on horizontal size class?

[hmlongco]

Is there a reason you're simply not using NavigationSplitView?

But yeah, I've been playing with ways to expose more of the navigation path.

Umm... if Navigator exposed it (It's internal at the moment, you could encode it to data and then decode to set the other path. (Presumes all destinations are Codable, of course.)

[gmedori]

tl;dr: Navigation.codable doesn't simply encode the path elements, but rather the type and the path element, making it difficult to work with if you want to manipulate the path.

---

There are some limitations of NavigationSplitView that we're trying to work around unfortunately. I actually don't know a ton of the details but some of my colleagues assure me that it's currently very problematic. I'll be following up with them about that.

That said, I noodled on what you said about encoding/decoding to sync up the paths but encoding NavigationPath.codable produces some interesting and difficult to work with results. So here's a premise and some code:

Suppose I have an enum representing my paths called PathElement:

enum PathElement: Codable {
	case home
	case itemList
	case itemDetail
}

I would like to be able to operate on a simple array of type [PathElement] in order to manipulate the path as I need. So I'd like to be able to encode NavigationPath.codable and then decode to [PathElement] like so:

// NavigationPath.codable encoding/decoding

var path = NavigationPath()
path.append(PathElement.home)
path.append(PathElement.itemList)
path.append(PathElement.itemDetail)
let encodedPath = try! jsonEncoder.encode(path.codable)
let stringifiedPath = "Encoded NavigationPath: \(String(data: encodedPath, encoding: .utf8) ?? "(nil)")"
print(stringifiedPath)

do {
	let decoded: [PathElement] = try jsonDecoder.decode([PathElement].self, from: encodedPath)
    print("Decoded NavigationPath: \(decoded)\n")
} catch {
	print("Error decoding NavigationPath: \(error)\n")
}

Unfortunately, this code produces the following:

Encoded NavigationPath: ["main.PathElement","{\"itemDetail\":{}}","main.PathElement","{\"itemList\":{}}","main.PathElement","{\"home\":{}}"]
Error decoding NavigationPath: typeMismatch(Swift.Dictionary<Swift.String, Any>, Swift.DecodingError.Context(codingPath: [_CodingKey(stringValue: "Index 0", intValue: 0)], debugDescription: "Expected to decode Dictionary<String, Any> but found a string instead.", underlyingError: nil))

If you observe the first line of the output which shows what actually got encoded, it's clear that it's not simply encoding each path element, but also it's type. Hence why decoding doesn't work. As a comparison, here's what you get when you decode a simple encoded array with the same PathElement values:

Code (very similar to the example above):

// Vanilla array encoding/decoding

let pathElementArray: [PathElement] = [.home, .itemList, .itemDetail]
let encodedArray = try! jsonEncoder.encode(pathElementArray)
let stringifiedArray = "Encoded Array: \(String(data: encodedArray, encoding: .utf8) ?? "(nil)")"
print(stringifiedArray)

do {
	let decoded: [PathElement] = try jsonDecoder.decode([PathElement].self, from: encodedArray)
    print("Decoded Array: \(decoded)\n")
} catch {
	print("Error decoding array: \(error)\n")
}

Output:

Encoded Array: [{"home":{}},{"itemList":{}},{"itemDetail":{}}]
Decoded Array: [main.PathElement.home, main.PathElement.itemList, main.PathElement.itemDetail]

So in order to be able to manipulate an array of PathElements, I need to write custom decoding logic to account for the type name that precedes each value in the encoding of NavigationPath.codable. I suppose this is an approach I could take, but that could break in the future since it's an implementation detail.

I'm not sure what the best solution is here, but NavigationPath does not seem to make it easy to introspect and manipulate its contents. I'd be curious to know your thoughts as you explore ways to expose more details around the NavigationPath to achieve greater flexibility.

[theedov]

Also interested in this since I in some parts of my app, I need to remove some destinations from the middle of the stack. I currently do it by assigning a new array of destinations to path based on whatever's inside the current path..

Or is there another way to do it with Navigator?

[hmlongco]

@theedov Not sure of the viability of this. If the path has view A and B and C on it and you were to reset the path to A and C, wouldn't SwiftUI completely regenerate view C? (view C loses it's current state)

[theedov]

@hmlongco Hmm, so basically I just get existing list of paths, and modify it using .removeFirst(at:) and then reassign. Isn't it the same as directly applying .removeFirst(at:) on the existing list of paths? Logically it shouldn't regenerate anything? But not 100% sure(will need to confirm) since I haven't experienced any issues with it so far.

[hmlongco]

It depends on how smart SwiftUI is and how it maps the destination values to the views in the UIHostingViewControllers. Unfortunately at the moment Navigator is using a NavigationPath and that limits the operations that can be performed on it.