0216-modern-swiftui-pt3

[jjnino]

Hello, @stephencelis @mbrandonw this question is not necessarily about this code example, but y'all talk about it in this episode so I figured why not here. Also, really love the pointfree series so thanks and keep it up!

Question:

The ability to have the application in a particular destination is awesome and I think the way it is modeled works great. I was curious what y'all thought about the fact that a particular destination is tied to its parent screens and if there was a case for having destinations (especially those that are a couple levels deep) be presented as a single level destination?

For example at around 15:42 the app is setup to start in a meeting details screen. And that requires setting up the navigation to first have the standup details screen and then the meeting screen. Does it make sense to ever have the meeting details screen be the shown without having to show the standup details? If universal links are supported ,for example, and the user has a link to a particular meeting do y'all think it is appropriate to have the users navigation be Root Standup List > meeting details? Instead of Root Standup List > Standup details > meeting details? Mostly just curious here. I guess to me if feels like the meeting details will always be tied to a standup details, which might be true, but does that mean the screens need to be? Anyway, thanks for any opinions here!

[stephencelis]

@jjnino Sorry for the delay. Must have missed this 😄

We talk a bit about this kind of navigation in our previous series on stacks: https://www.pointfree.co/episodes/ep213-swiftui-navigation-stacks

We think it's all about the trade-offs we discussed over the course of the episode. There are applications where presenting an arbitrary screen from anywhere makes sense, like wiki-based apps. However in this case we think the more rigid, tree-based nav is appropriate, especially given the current design. The "meeting details" screen provides no context on which standup it belongs to, and the context is provided specifically by the navigation. A redesign could make stack-based navigation more appropriate, like if meeting details provided standup context directly inside, and if it linked to other recent/related meetings/standups. In the end of the day, it's up to the folks developing the app to decide which kind of navigation makes the most sense 😄

[jjnino]

Thanks @stephencelis sorry for the late reply. Makes sense. Love the episodes!