Conversation
b3bc776 to
bef0125
Compare
martijnwalraven
left a comment
There was a problem hiding this comment.
Glad to get rid of the publicly exposed Promise implementation! It's a breaking change, but I think it's worth it and it shouldn't impact too many people.
I think the code could be simplified with generic wrapper methods to convert methods from/to the use of promises, but that's probably not worth the trouble.
| } | ||
| } | ||
|
|
||
| internal extension NormalizedCache { |
There was a problem hiding this comment.
It's probably not worth the trouble, but I wonder if we could use something like Node's promisify to avoid writing these wrapper methods manually.
There was a problem hiding this comment.
Since I'd eventually like to remove our promises system I'm not entirely convinced making them easier to create is worth it. 😆
| }.andThen { | ||
| fulfill(()) | ||
| } | ||
| guard let completion = completion else { |
There was a problem hiding this comment.
Maybe apollo_performAsyncIfNeeded could be extended with a guard for an optional callback?
| public func withinReadTransaction<T>(_ body: @escaping (ReadTransaction) throws -> T, | ||
| callbackQueue: DispatchQueue? = nil, | ||
| completion: ((Result<T, Error>) -> Void)? = nil) { | ||
| _ = self.withinReadTransactionPromise { |
There was a problem hiding this comment.
This may not be worth it, but maybe a generic wrapper method like Node's callbackify could be used to abstract this conversion.
bef0125 to
eaac434
Compare
|
|
||
| import Foundation | ||
|
|
||
| public extension DispatchQueue { |
There was a problem hiding this comment.
Does this extension need to be public?
There was a problem hiding this comment.
Yes, in order for it to be usable in the ApolloSQLite framework.
3b8b444 to
9f914e1
Compare
…dle optional completion blocks
9f914e1 to
8f24739
Compare
|
may [deity or lack thereof of choice] have mercy on us all |
NOTE: Leaving this as a draft because I'd like @martijnwalraven to take a look at this when he's back from vacation, and I'd love to hear any other feedback in the meantime.
This PR addresses #382. The promises Martijn created were originally intended to only be for framework-internal consumption, not for use by outside apps or SDKs. This is why we're using a custom
Promisetype rather than existingPromiselibraries.However, our
Promisetype conflicts with those existing libraries and can cause all sorts of weirdness and confusion when it's exposed publicly, and it also somewhat hamstrings future implementation choices (including removing Promises under the hood entirely).For this PR, we're only removing the "public" aspect of promises and continuing to use them under the hood. This should give us more flexibility in the future, and make it easier to wrap these methods in their preferred promise library.
Note that this is going to be a BREAKING CHANGE!