Effect cancellation via type name is being deprecated (.cancel(id: TimerID.self))

[stephencelis]

We wanted to announce an upcoming deprecation in TCA around effect cancellation coming in #2091. For a long time we have recommended and documented using static types as lightweight cancel IDs for effects. E.g.:

// Empty type used to identify a cancellable effect
enum RequestID {}

case .startButtonTapped:
  return .task { /* ... */ }
    // Mark effect cancellable by type
    .cancellable(id: RequestID.self)

case .cancelButtonTapped:
  // Cancel effect by type
  return .cancel(id: RequestID.self)

As much as we like this style, there is a bug in Swift that allows it to aggressively prune these symbols in release builds, which can even lead to breaking how cancellation works in your production TCA apps.

Because of this, we are deprecating support for this style, and will instead require simple hashable types, instead, which are not compiled out of release builds. Migration will require introducing a value to cancel with instead of relying on the type. E.g. you can add a case to the previously-empty enum:

-enum RequestID {}
+enum CancelID { case request }

 case .startButtonTapped:
   return .task { /* ... */ }
-    .cancellable(id: RequestID.self)
+    .cancellable(id: CancelID.request)

 case .cancelButtonTapped:
-  return .cancel(id: RequestID.self)
+  return .cancel(id: CancelID.request)

We hope it will be mostly painless, and that it will help you avoid introducing compiler-related bugs in your application.

[JacksonUtsch]

+1 Safety first 👷

[acosmicflamingo]

I saw in a diff that this was what you all did, so I've already updated my codebase to reflect it :) it's a lot cleaner, that's for sure!

[ZevEisenberg]

Is a case-ful enum your recommended way of doing this, as opposed to struct RequestCancelID: Hashable {}? If so, is it for any reason other than easier migration from the earlier style?

[mbrandonw]

There is no technical difference between those two styles, just some ergonomics. Can be a little less typing (simple enums are automatically Hashable) and it groups the IDs together. So whichever style works best for you, but we probably will use the enum style most in practice.

[bioche]

Kind of an old discussion but I tend to use generated UUIDs in the state for this, just in case I have multiple instances of the Core up at the same time in the app. In most cases, this is impossible but it would be quite hard to debug if it ever occurred in the wild ^^