Open williamhjcho opened 6 years ago
I really like the promises approach, I'm just afraid that it might complicate Frisbee users when it comes to creating their tests. What do you think?
Not sure, haven't defined the API yet, just the draft above It does involve a little bit of stretching to other patterns, which newcomers could not be familiar with
But I think it's a worthwhile implementation just for the capability of encapsulating and chaining workloads and operations
If needed, there could be a separate target for testing/mocking
I was thinking about this issue. And I guess that should be an extension of Frisbee. The reason is with that, we will increase the code dependency to Frisbee. For example:
// Is OK to require Frisbee here
import Frisbee
class MoviesRepository {
let getRequest: GetRequestable
init(getRequest: GetRequestable) {
self.getRequest = getRequest
}
func allMovies() -> Promise<[Movie]> {
return getRequest.get(url: "")
}
}
// Here, the UIViewController must to import Frisbee. But could be avoided.
// It is necessary because MoviesRepository are returning a Promise.
import Frisbee
class MoviesViewController: UIViewController {
func viewDidLoad() {
moviesRepository.allMovies().then({
// ...
})
}
}
Maybe my knowledge about Promises is to poor. But I think this could spread the Frisbee library in places where the user don't need. And with callbacks, although it is simpler, the user does not need to import the Frisbee.
As in RxSwift
and RxCocoa
?
Where RxCocoa
creates extensions on top for RxSwift
mostly on UI?
This isn't an issue about Promises
but more on maybe unnecessary imports
But either way, the Promise
function overload can still coexist with the closure one, so this import
would not be needed
The main idea is to allow more fine-tuning of the request's response, in more concise operations
Why implement Promise/Future
Promise<Value>
enables more functionalities for chaining and perpetuating operations than a simple(Result<Value>) -> Void
callback by allowingmap
,flatMap
Error
catching and treatingBasic snippet
Inspired by
RxSwift
,Future
(from fp paradigms) andPromise
(from js):Use examples
Simple async dispatching
Other ways of creating
Promises
Similarities
Using
RxSwift
as a reference, aPromise
is aSingle Cold Observable
. It contains some work which will only be executed when someone subscribes to it There should be ways of making themhot Observables
, share subscriptions, combine with others (eg:zip
) etcBut differently from
RxSwift
,Promises
do not send a stream of multiple objects, just zero or one (Value
orError
) And it should be noted that it also doesn't have to deal withdisposables
and whatnotReferences
RxSwift
khanlou/Promise