Supressing runtime warnings

[vladyslavsosiuk]

TCA generates various runtime warnings, which are often quite informative, but they can sometimes be false positives. For example, if we wish to send an action when the view disappears but is not actually dismissed, the onDisappear closure will always be invoked when the view is dismissed as well. There is no way to avoid these warnings other than to construct an ad hoc solution that would observe the view being disappeared based on some other data in the state (for example, when its destination becomes non-nil). But that approach is pretty non-solid. For example, if such a view is placed in a tab view and the tab is changed, it requires observing tab selection in the tab view parent reducer to observe disappearance, and there may be others. @mbrandonw noted implementing a 'withoutWarnings' function to ignore such warnings. We could wrap sending actions from the onDisappear closure in such function so we could suppress the warnings that we are aware of and don't want to have them in the issue navigator since they may jumble with true warnings that one can miss due to the large number of them.
Here is a link to the discussion in Slack:
https://pointfreecommunity.slack.com/archives/C04KQQ7NXHV/p1715628109148009
Here is a link to a PR that prototypes the function:
#3081

[mbrandonw]

Hi @vladyslavsosiuk, we discussed this today, and while we do think surpassing runtime warnings is probably a good thing to eventually add, it will take some time.

There is also the possibility of us exposing public information on the store about whether or not it is still "active". That would allow you to check if some parent or grandparent state has already been nil'd out, and then you could choose not to send the onDisappear action in that case.

No timeline on that, but it's something we would like to do.

[vladyslavsosiuk]

Sounds great! A public information on the store to check before sending an action in onDisappear sounds even better to me

[vladyslavsosiuk]

Hi @mbrandonw,

I wanted to follow up on this discussion. The IssueReporting library provides a way to suppress runtime warnings, but it suppresses all warnings within the same task context. Is there a way to make this more granular, so we can suppress only the TCA-related warnings while still allowing the reducer to report its own issues?

Consider the following example:

// In the child view
var body: some View {
    // ...
    .onDisappear {
        withKnownIssue(isIntermittent: true) { // Suppress runtime warnings when the view is popped from the navigation stack 
            store.send(.viewDisappeared)
        }
    }
}

// In the child reducer
switch action {
case .viewDisappeared:
    let isStateInvalid = true
    if isStateInvalid {
        Task.detached { // Detach from the `withKnownIssue` task context to report issues
            reportIssue("State is invalid")
        }
    }
    return .none
}

The only way I’ve found to achieve this is by reporting issues from a detached task, which ensures the issue is reported outside the withKnownIssue context. However, this approach feels a bit hacky, as it relies on remembering to detach tasks manually, without any compile-time guarantees or library support.

Is this the expected way to handle such cases, or is there a better approach to achieve more granular control over suppressed warnings?

Looking forward to your thoughts!

[mbrandonw]

We still don't have any updates on this. It seems like this would require some kind of tagging system so that TCA could tag the types of runtime issues it emits and you could then selectively decide which to turn off. That may be something we do eventually, but it would take a lot of brainstorming to get a final API for it.

[vladyslavsosiuk]

Thank you for the update!