Closed andrefmsilva closed 5 years ago
I understand the idea and possible benefits regarding these changes.
However I would like to argue against this change due to the following reasons. This only reflects my personal opinion, so feel free to provide counter-arguments that may change my mind.
It is common for UI-related frameworks to not handle threading issues on their own, except if really necessary. Example: UIKit
XCoordinator is built to only be used on the Main Thread and has never been intended to provide thread-safety on its own. Allowing concurrent calls to certain methods and not providing a thread-safe API as a whole might confuse users, since this change would not be consistent.
Changing threads is not hard at all (especially with GCD, RxSwift or Combine) and should not be a problem, even for beginner users. If one seems to often forget to switch dispatch queues before triggering routes, one can write extensions (without the need to change the framework), such as the following:
extension Router {
func threadSafeTrigger(_ route: RouteType, with options: TransitionOptions = .init(animated: true), completion: (() -> Void)?) {
if Thread.isMainThread {
trigger(route, with: options, completion: completion)
} else {
DispatchQueue.main.sync {
trigger(route, with: options, completion: completion)
}
}
}
}
or even more reusable:
public func onMainThread<T>(_ block: () throws -> T) rethrows -> T {
return try Thread.isMainThread
? block()
: DispatchQueue.main.sync(execute: block)
}
I agree. I was already using an extension to trigger on main thread
I think the current TransitionPerformer should check and switch to main thread if needed... It handles UI transitions and it should always be called on main thread.
When we use the route in some ViewModel is easy to forget that we need to trigger it on main thread, so it should be handled inside this framework.