-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Client interface #56
Conversation
lib/http.dart
Outdated
@@ -32,7 +32,7 @@ export 'src/streamed_response.dart'; | |||
/// the same server, you should use a single [Client] for all of those requests. | |||
/// | |||
/// For more fine-grained control over the request, use [Request] instead. | |||
Future<Response> head(url, {Map<String, String> headers}) => | |||
FutureOr<Response> head(url, {Map<String, String> headers}) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh...these are always async, right?
Why the move to FutureOr
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kevmoo the intent is to move to middleware like shelf.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay...but do we imagine a future where these calls may be sync?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we just talking http.dart or throughout? With the http helpers no.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly. So this method should always return Future
. FutureOr
implies that it may synchronously return Response
.
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
0ef3052
to
0cd3d44
Compare
CLAs look good, thanks! |
0cd3d44
to
6cf06ea
Compare
@kevmoo fixed the interface. |
lib/http.dart
Outdated
@@ -161,7 +157,7 @@ Future<String> read(url, {Map<String, String> headers}) => | |||
Future<Uint8List> readBytes(url, {Map<String, String> headers}) => | |||
_withClient((client) => client.readBytes(url, headers: headers)); | |||
|
|||
Future/*<T>*/ _withClient/*<T>*/(Future/*<T>*/ fn(Client client)) async { | |||
Future<T> _withClient<T>(FutureOr<T> fn(Client client)) async { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this FutureOr
? I'm pretty sure all the functions return Future
s.
lib/src/base_client.dart
Outdated
@@ -23,15 +21,15 @@ abstract class BaseClient implements Client { | |||
/// can be a [Uri] or a [String]. | |||
/// | |||
/// For more fine-grained control over the request, use [send] instead. | |||
Future<Response> head(url, {Map<String, String> headers}) => | |||
_sendUnstreamed("HEAD", url, headers); | |||
FutureOr<Response> head(url, {Map<String, String> headers}) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question here: why FutureOr
? This is never going to return a Response
synchronously.
lib/src/base_client.dart
Outdated
Future<Response> head(url, {Map<String, String> headers}) => | ||
_sendUnstreamed("HEAD", url, headers); | ||
FutureOr<Response> head(url, {Map<String, String> headers}) => | ||
send(new Request.head(_uri(url), headers: headers)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The request constructors should take dynamic url
s, not Uri
s.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about the named constructors take dynamic but the default takes a Uri? If all of them take dynamic then there's a check on each call to change
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather have a cleaner public API and add a private constructor for change
to call, I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
K works for me 👍
@@ -4,7 +4,7 @@ author: "Dart Team <misc@dartlang.org>" | |||
homepage: https://github.com/dart-lang/http |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should make sure to update the pubspec version to make a major change, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to 0.12.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be 0.12.0-dev. We use the "-dev" suffix to clearly distinguish between released versions and those that are still in progress.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry it took me so long to get back to this!
lib/src/request.dart
Outdated
} | ||
} | ||
|
||
Uri _uri(url) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either make this a static method of Request
, or put it in utils
.
@@ -30,12 +30,12 @@ class Request extends Message { | |||
/// | |||
/// Extra [context] can be used to pass information between inner middleware | |||
/// and handlers. | |||
Request(this.method, this.url, | |||
Request(String method, url, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Document the acceptable types for url
. You can probably just copy the docs from the top-level methods.
@@ -4,7 +4,7 @@ author: "Dart Team <misc@dartlang.org>" | |||
homepage: https://github.com/dart-lang/http |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be 0.12.0-dev. We use the "-dev" suffix to clearly distinguish between released versions and those that are still in progress.
🎊 |
This updates the
Client
interface exposed and removes the extensions ofRequest
andResponse
that are no longer applicable.