Eager navigation and load handling of cancel

[johankool]

Describe the bug
When you navigate back before the loading has finished, the behavior of the app gets broken.

To Reproduce

1. In 03-Navigation-Lists-NavigateAndLoad.swift on line 46 set the delay a bit longer (e.g. 3 seconds)
2. Run the demo
3. Select "Load optional counter that starts from 1"
4. Navigate back from the screen before the counter appears
5. Now try to open the same counter again or any of the others

Observed behavior
Tapping same counter is unresponsive. Tapping other counter immediately navigates back.
Screen Recording 2020-05-24 at 11.36.09.zip
(Unfortunately GitHub won't let me upload screen recording unzipped.)

Expected behavior
Being able to use the demo as if you had waited until the counter had appeared.

Environment

• Xcode 11.5
• iOS 13.5
• Simulator for iPhone SE (2nd generation)

[pcolton]

@johankool I just happen to be playing in that code today and found that if you just move one line out of the if let block, it works fine, the reason is that since the counter isn't loaded yet, it fails the second let case but the selection still needs to get nil'd out:

At around line 50, I think it should look like this, note the state.selection = nil is moved out of the if block:

    case .setNavigation(selection: .none):
      if let selection = state.selection, let count = selection.value?.count {
        state.rows[id: selection.id]?.count = count
      }
      state.selection = nil // <-- this line moved out of if block above
      return .cancel(id: CancelId())

[johankool]

@pcolton That indeed fixes it. Thanks!

I noticed btw that also 03-Navigation-Lists-LoadThenNavigate has similar issues. There if you navigate away from the example before the delay the next time you come back you get a flash of a white screen.

[pcolton]

For 03-Navigation-Lists-LoadThenNavigate an easy fix eludes me. It's a similar problem, when you navigate away, the code after the delay still executes, so sets the selection even though it shouldn't. If I try to stop the timer, I get other issues, so I'll leave it up to the big guns to fix this one. ;-)

[stephencelis]

It was a trickier fix, but in #130 we did a workaround to force the root view to recreate fresh case studies each time it appears. In a real application you'd have to propagate that cancellation or niling out of state to when parent navigation is handled. Hopefully navigation becomes a lil less thorny in the next version of SwiftUI!