NavigationLinks are now supported in SwiftUI!

[Tyler-Keith-Thompson]

Linked Issue:

Checklist:

• [x] Did you sign the Contributor License Agreement?
• [x] Is the linter reporting 0 errors?
• [x] Did you comply with our styleguide?
• [ ] Is there adequate test coverage for your new code?
• [x] Does the CI pipeline pass?
• [x] Did you update the documentation?
• [x] Did you update the sample app?
• [x] Did you change the public API?

---

If Applicable:

• [x] Did you test when the first item is skipped?
• [x] Did you test when the last item is skipped?
• [x] Did you test when middle items are skipped?
• [x] Did you test proceeding backwards?

[Tyler-Keith-Thompson]

As discussed I am deliberately working on just writing failing tests, that leaves the team to focus on production code. As of the time of writing there are more tests that need to be written but I am quite confident in the testing suite, I am also confident in our ability to get nav stacks working along with skipping one or more items, backing up, persistWhenSkipped persistence settings, and adding embedInNavigationView() to the API surface.

I suspect removedAfterProceeding will never animate the way we want it to, although I could be wrong. In UIKit this clearly means the next item slides in and the one you were just on gets removed from the back stack. While I am not at all confident in our ability to animate that the same way I do feel there's some middle ground where we just do it, and let SwiftUI animate that however it thinks is right. If that behavior is odd, or unlikely to be used that's fine, we're responding to a request from the consumer to remove the item after proceeding, and that is what we do.

NOTE: removedAfterProceeding may just outright work differently (see: very likely will) between Xcode 12.4, 12.5 and 13. SwiftUI changed a fair amount between all of those versions.

Alternative approaches for removedAfterProceeding:

• Don't support it by doing some complex nonsense to prevent that as a possibility at compile time (I hate this for maintenance reasons, and because I do not think we will get the compiler error messages we'd want to make this nice)
• Make setting the persistence a throwing function. On the surface this seems nice but in practice I suspect it will just make the consumer experience poor when trying to create views. Especially given that most of the time it won't fail.
• Create a runtime crash if you have a presentationType of navigationLink and a persistence of removedAfterProceeding. This is sub-optimal because it's a runtime issue. That said it's not an option I'm substantially opposed to. I had originally thought that data driven workflows might make this hard-to-spot but data driven workflows will already have linting, so we could dis-allow the data model setting that presentation type and that persistence.

[codecov-commenter]

Codecov Report

Merging #116 (f209260) into main (568758f) will increase coverage by 0.28%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #116      +/-   ##
==========================================
+ Coverage   93.98%   94.26%   +0.28%     
==========================================
  Files          75       76       +1     
  Lines        1813     1867      +54     
==========================================
+ Hits         1704     1760      +56     
+ Misses        109      107       -2     

Impacted Files	Coverage Δ
...ftUI/Extensions/AnyWorkflowElementExtensions.swift	100.00% <100.00%> (ø)
...wiftCurrent_SwiftUI/Models/WorkflowViewModel.swift	100.00% <100.00%> (ø)
...SwiftCurrent_SwiftUI/Views/NavigationWrapper.swift	100.00% <100.00%> (ø)
...rces/SwiftCurrent_SwiftUI/Views/WorkflowItem.swift	94.44% <100.00%> (+2.77%)	:arrow_up:
.../SwiftCurrent_SwiftUI/Views/WorkflowLauncher.swift	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 0adcfba...f209260. Read the comment docs.