Cancel Effect when View disappears

[BastianKusserow]

Hey there,

I'd have a question in regards to cancelling an action when a child view disappears.
Suppose we have a parent view that can show a child view when the parents child state is non nil. When pressing a button in the child view, the child views reducer kicks off a long running effect that should be cancelled when the child view disappears.
Other than that, the user also has the option to close the sheet via a button.
If the user taps the close button, the parent reducer sets its child state to nil, so that the sheet will disappear, which works fine.
The problem now is that the child views onDisappear is called after the state is already nil, causing an optional reducer warning. Is there a way how this can be handeled in a way that there are no such warnings emitted?

I'll also attach the corresponding sample code that demonstrates the problem.

Code

struct ParentState: Equatable {
  var child: ChildState?
}

struct ChildState: Equatable { }

enum ParentAction {
  case next
  case dismissChild
  case child(ChildAction)
}

enum ChildAction {
  case startEffect
  case onDisappear
  case dismiss
}

let parentReducer = Reducer<ParentState, ParentAction, Void> { state, action, _ in
  switch action {
  case .next:
    state.child = .init()
    return .none
  case .child(.dismiss), .dismissChild:
    state.child = nil
    return .none
  case .child:
    return .none
  }
}

let childReducer = Reducer<ChildState, ChildAction, Void> { state, action, _ in
  switch action {
  case .startEffect:
    return .none // Suppose we'd kick off a long running effect here
  case .onDisappear:
    return .cancel(id: "SomeId")
  case .dismiss:
    return .none
  }
}

let appReducer = Reducer.combine(
  childReducer
    .optional()
    .pullback(state: \.child, action: /ParentAction.child, environment: { () }),
  parentReducer
)
  .debug()


struct ParentView: View {
  let store: Store<ParentState, ParentAction>
  
  var body: some View {
    WithViewStore(store) { viewStore in
      Button("Open Sheet") {
        viewStore.send(ParentAction.next)
      }
      .sheet(isPresented: viewStore.binding(get: { $0.child != nil }, send: ParentAction.dismissChild)) {
        IfLetStore(store.scope(state: \.child, action: ParentAction.child)) { store in
          ChildView(store: store)
        }
      }
    }
  }
}

struct ChildView: View {
  let store: Store<ChildState, ChildAction>
  
  var body: some View {
    WithViewStore(store) { viewStore in
      Button("Close Sheet") {
        viewStore.send(ChildAction.dismiss)
      }
      .onDisappear {
        viewStore.send(.onDisappear)
      }
    }
  }
}

[Alex293]

Either also cancel the effect on dismiss in parent reducer or use the .task modifier on view instead of on appear/on disappear with binds the view lifecycle and the effect run. I’m pretty sure there are examples of this as this already been asked.

[BastianKusserow]

I am aware of the task modifier when the effect is started when the view appears, but in this specific scenario the long running effect explicitly has to be kicked off when a button is tapped, not when the view appears, so I guess .task is not an option here?

It might be an option to cancel the task in the parent reducer when .dismiss is called but that would on the one side mean that the parent would be responsible of cancelling a task that the child started (which I do feel like that shouldn't be the parents responsibility) and on the other hand, when not using .onDisappear, what happens if the user dismisses the sheet by swiping it away? I have to somehow react on view dismissal.

[tgrapperon]

mean that the parent would be responsible of cancelling a task that the child started (which I do feel like that shouldn't be the parents responsibility)

It ultimately is the parent responsibility if you think about it, as the fact that it can be presented or not is foreign to the child domain.

One possible alternative using task is to set some internal optional @State value and use this value as the task's id. When this value is non-nil, you can send and await what you would have sent from the button, like we usually do when using task without id. In other words, you use the optional id to defer the task to a later time, when it becomes non-nil. You'll need to handle what happens when you press the Button again.

Please also note that the upcoming navigation update will likely handle cancellation automatically.

[BastianKusserow]

Thanks for the response.

It ultimately is the parent responsibility if you think about it, as the fact that it can be presented or not is foreign to the child domain.

Ok, agree, but if it's presented, pushed or embedded wouldn't make a difference in that case so it would be best if the parent would not have to know about internal effects/cancellation identifiers.

The task alternative seems interesting, I just hoped that there are more straightforward ways to do so. Hopefully the navigation update then makes all of this easier :)

[tgrapperon]

I agree that having to acknowledge internals of a child feature is sub-optimal. The upcoming navigation update will likely cancel all child effects on dismissal.

[mbrandonw]

Using the view's onDisappear to send an action and then do cancellation inside there can be a good way to cancel effects in the child without the parent needing to do anything, but it's only workable if you are not using optional state to drive navigation. If the sheet presents/dismisses based on optional state, then there is a bit of a chicken-and-egg problem.

For example, the state can be nil'd out to represent the sheet should go away, which then a moment later causes onDisappear to fire, but at that point the child reducer can't receive that action because there is no state to reduce on, and hence it can't actually do any cancellation.

So, if you want to go that route you either need to drive navigation with a boolean, or wrap the optional child feature in an additional non-optional feature so that you can react to it. We do have a case study for this. It's a little experimental because we abstracted it as a higher-order reducer, but you might find something useful in there.

And as @tgrapperon mentioned, the navigation tools we are working on will solve all of this at once. You will be able to present a screen, and when the screen goes away it will tear down all effects regardless of when they were started.

[BastianKusserow]

Thanks @mbrandonw & @tgrapperon for all the suggestions. I'll definitely try out some of them and look how it works out!

Until then, looking forward to the navigation tools ❤️

[derekc00]

I'm also looking forward to this feature!

[jaroslavas]

@mbrandonw The second beta of new navigation tools is already out. Is this problem fixed in it? :)