#combine
> A publisher that eventually produces a single value and then finishes or fails.
In [[Combine]] there many kinds of publishers each specialized for a specific use-case, one extremely useful ones is a [[Future]].
Often, it's useful to be able to convert a closure based or a blocking function to a publisher. One common scenario where this is useful is when building functional chains with [[Combine]].
Assume we have this publisher chain that is triggered when a user taps a button:
```swift
let result = onTapPublisher
.map {
client.getUsers() // -> AnyPublisher<[User], Never>
}
.switchToLatest()
```
One requirement we have been given is to ensure we save the users from the `client` response into a database so we can have faster loads the next time we see this view.
The API for saving a user is not written with [[Combine]] in mind and as such uses simple closures to callback once an asynchronous task is completed (such as saving to the DB).
```swift
func saveUsers(_ users: [User], completion: @escaping (Result) -> Void) {
...
}
```
We could use `sink` on the above publisher chain and then use the closure to set the result. However, what if we instead wanted to use the result in another chain? By using `sink` we have completed the chain and as such we can no longer use it elsewhere.
Instead it would be ideal if we could simply wait for the `client` and then transform that response into the `saveUsers` `Result`. We can't do this by using `map` since that function expects a return value and we're dealing with an async closure.
Enter [[Future]]:
```swift
func saveUsersPub(_ users: [User]) -> Future<[User], Never> {
Future { promise in
saveUsers(users: users) { result in
promise(result)
}
}
}
```
Perfect! This pretty much encapsulates what we need to do. It now returns a publisher of type [[Future]] which will emit a value when `saveUsers` completion is called.
So we can now create the following chain:
```swift
let result = onTapPublisher
.map {
client.getUsers() // -> AnyPublisher<[User], Never>
}
.switchToLatest()
.map(saveUsersPub)
```
The neat part is how readable this makes the code. If we had done this in `sink` it would be pretty nested within the code and not isolated, making it less friendly to testing.
One important note about [[Future]] is that it will execute the code in the block **regardless** of if it has received a subscription or not. For example, you could imagine using a [[Future]] as way to perform a heavy data task that should only happen when something will actively handle it. If you used a [[Future]] for this then the task would happen regardless of anything is ready to listen to the result. Instead, if you need to wait for subscription before executing the block you should checkout [[Deferred]].