New deprecation warnings in prerelease/1.0

[oliverfoggin]

I know I'm early. Just eager to get stuck in 🤣

I'm getting a few deprecation warnings and I'm not entirely sure what some of them want us to change in the code.

.fireAndForget

'fireAndForget' is deprecated: Use the async version, instead.

But the async version has the same signature.

Our code:

return .fireAndForget {
  analyticsClient.sendAnalytics(analyticsData)
}

The async version also specifies an optional parameter of priority: TaskPriority but if you exclude it the compiler thinks you're using the deprecated version instead.

.debounce

'debounce(id:for:scheduler:options:)' is deprecated: Use 'withTaskCancellation(id: _, cancelInFlight: true)' in 'Effect.run', instead.

Our code:

return Effect(value: .actionNameHere)
  .debounce(
    id: TimerID.self,
    for: .milliseconds(600),
    scheduler: queue
)

I tried to use the withTaskCancellation which would allow for the task to be retried each time but it doesn't allow for a debounce like timer. So it would run each time the action is hit rather than waiting the 600ms as it would with the debounce above.

.deferred

'deferred(for:scheduler:options:)' is deprecated: Use 'clock.sleep' in 'Effect.task' or 'Effect.run', instead.

We're running iOS15. Is there a solution for this with iOS15 support? I don't believe Clock is available pre iOS16.

Thanks

[lukeredpath]

Regarding the .fireAndForget overload: the compiler is probably thinking you're using the synchronous version as you're not performing any async work in the closure. Consider modelling all of your dependencies, including fire and forget clients like analytics calls as async as this provides some compile-time assurance that you aren't mistakenly using them in the reducer directly.

To perform a debounce using async, you just need to combine a cancellable in flight effect (using withTaskCancellation) with an explicit sleep using a clock or scheduler before performing the side effect that you want debounced. If the effect is triggered again while it is sleeping, the whole thing will be cancelled and it will trigger a new delayed effect.

For .deferred, whilst clocks are only available in iOS 16, you can still use schedulers in the same way. Use the built-in mainQueue dependency (also deprecated but I would hope its going to stick around post-1.0).

[oliverfoggin]

Ah great, thanks.

I managed to model the debounce with a await sleep and then a withCancellableTask. 👍🏻

[mbrandonw]

Glad you found workarounds to your problems, and we probably should also apply @_disfavoredOverload to the sync version of fireAndForget to help out too. Also synchronous effects in general need some consideration for 1.0.

[stephencelis]

@oliverfoggin Thanks for the feedback! Some good discussion here already, but here are our thoughts for each one:

.fireAndForget

We could maybe mark the synchronous version as @_disfavoredOverload in the preview branch. The only issue is the behavioral change could make existing synchronous tests fail. These tests will be deprecated on the branch, so that could be an OK trade-off, but for now we've decided to avoid it. Let us know what you think!

.debounce

@lukeredpath answered this one. Thanks, Luke!

.deferred

While we push folks towards to newest APIs like Clock, you can always use other APIs if your platform requirements require it! So in this case, you could use the built-in Combine or Timer APIs inside an Effect.run instead, and bridge with Swift concurrency as required.

[andwrobs]

@oliverfoggin

case .someActionCase:
  print("one-liner print debugging rules")
  return .none

how does this work? this was my "workaround" (although maybe the message is helpful in that you don't need to wrap synchronous work in a Task?)

---

@mbrandonw @stephencelis would also be curious to hear your thoughts on this. i see...

Also synchronous effects in general need some consideration for 1.0.

are you chewing on whether there'd be some sort of SynchronousEffect type for synchronous work that feeds back into the system?