UIScheduler SchedulerOptions type? about combine-schedulers

[stephencelis]

UIScheduler is probably most helpful in SwiftUI when you don't want to be too fussy about controlling the scheduler in your environment, but want to still retain some testability for non-delayed effects, since immediately scheduled work will be performed in the test without the usual thread hop of receive(on: DispatchQueue.main).

Otherwise it's probably mostly useful in UIKit, where certain lifecycle events happen on the main thread and a further tick will cause layout glitches, like when a UITableViewCell is configured. In the end it should generally be useful in the same places that the ReactiveSwift scheduler is useful, but it's been awhile since I've lived in that pre-SwiftUI land, day-to-day 😅

[stephencelis]

The main reason we omitted the options here was because they don't seem to apply to the immediacy of a UI Scheduler.

I think generally you'd want to use AnySchedulerOf<UIScheduler> in your application if you want to override it with a TestScheduler in your tests.

I'm not even sure if there is any use case to actually replace UIScheduler with plain DispatchQueue. I was just used to writing this kind of API 😅

I think if you want to avoid an async "tick" when you are already processing things on the main thread, UIScheduler can still be important. A .receive(on: UIScheduler.shared) will not incur the cost of a thread hop, but .receive(on: DispatchQueue.main) will.

[ollitapa]

On the TCA front, would you recommend to use .receive(on: UIScheduler.shared) directly inside the reducer?

Or store it in the environment? So that there would be

struct Env {
  var workScheduler: AnySchedulerOf<DispatchQueue>
  var mainScheduler: AnySchedulerOf<UIScheduler>
}

And use pipe those like .subscribe(on: env.workScheduler).receive(on: env.mainScheduler)