Find a way to automatically send a path when a new screen appears

[winsmith]

• [ ] generate a path for this view (if possible). It would be cool if the path is "." separated
• [ ] Send the path as navigate(to:)

Ideas

• View Modifier
• Extend View Struct with a Protocol
• Create some kind of navigation library with helpful features (compare composable architecture library)
• Swift Macro @TelemetryScreen

[Jeehut]

@winsmith I played around with different approaches regarding simplifying navigation tracking in SwiftUI apps. My thoughts:

1. A SwiftUI view modifier that accepts the current path as a parameter definitely makes sense and should be provided as an alternative even if any of the other approaches are implemented, e.g. for edge cases like sheets that are presented within a view type where the developer didn't create an extra Swift file for. So I've implemented this in https://github.com/TelemetryDeck/SwiftSDK/pull/199.

2. A custom protocol like TelemetryView or TrackedView that extends View and requires something like navigationPath: String { get } seems cool at first. But after playing around I found many situations where I don't actually create an extra view type for a screen. Most commonly when I present something like a sheet / popover / error dialog etc., I consider this a screen I want to track (at least sometimes) and would like to track it. But a protocol like this doesn't cover those use cases and seem to provide no additional simplification over the SwiftUI modifier from point 1.

3. Creating a whole navigation library that simplifies navigation for developers in SwiftUI e.g. by providing built-in solutions for deep-linking seems reasonable because it could actually auto-track the path properly. But it's definitely the most complex approach, is hard to convince people to use (as people are often hesitant to adopt 3rd-party libraries in the core logic of their apps), and therefore I decided to leave this open for another "optional extra" kind of library that could be adopted by some, but definitely not by all people. SwiftUI also changes too fast and it could require more maintenance than we want to provide.

4. A @TelemetryScreen kind of macro could be attached to a SwiftUI view and automatically attach the above SwiftUI modifier (from point 1) to the body of a view. Unlike point 2 from above, a macro could actually auto-generate a sensible path based on the type name as we can read the whole code within the macro. But firstly, this is a "black-box" kind of magical approach where some users might run into unexpected situations (such as when they rename their type in code which breaks their insights). And secondly, it has the same disadvantage in terms of "not every scree/navigation destination has actually its own type" and falls short to track things like in-line sheets or dialogs.

So I've implemented point 1, but I'm hesitant to implement any of the others without yours consent. If you think the trade-offs I've described above are worth the extra work, I can tackle them, too. But I personally think we have other areas we should focus on improving first.

[Jeehut]

@winsmith With the merge of #199, do you think this is completed? I have a feeling that the other ideas are all out of scope since they're too inaccurate or require too much maintenance work.