The DispatchWorkItem class is an encapsulation of the concept of work item. There are few benefits.
A dispatch work item has a cancel flag. If it is cancelled before
running, the dispatch queue won’t execute it and will skip it. If it
is cancelled during its execution, the cancel property return True. In
that case, we can abort the execution
By encapsulating our request code in a work item, we can very easily cancel it whenever it's replaced by a new one, like this:
class SearchViewController: UIViewController, UISearchBarDelegate {
// We keep track of the pending work item as a property
private var pendingRequestWorkItem: DispatchWorkItem?
func searchBar(_ searchBar: UISearchBar, textDidChange searchText: String) {
// Cancel the currently pending item
pendingRequestWorkItem?.cancel()
// Wrap our request in a work item
let requestWorkItem = DispatchWorkItem { [weak self] in
self?.resultsLoader.loadResults(forQuery: searchText)
}
// Save the new work item and execute it after 250 ms
pendingRequestWorkItem = requestWorkItem
DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(250),
execute: requestWorkItem)
}
}
In general, Dispatch functions can take a block or a DispatchWorkItem as a parameter. So there won't any performance hit as we use blocks in both cases. Use the one that suits you the most.