Skip to content
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

Merged
merged 13 commits into from
Mar 6, 2017
Merged

Conversation

donny-dont
Copy link

This updates the Client interface exposed and removes the extensions of Request and Response that are no longer applicable.

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}) =>
Copy link
Member

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?

Copy link
Author

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.

Copy link
Member

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?

Copy link
Author

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.

Copy link
Member

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.

@googlebot
Copy link

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.

@donny-dont donny-dont force-pushed the feature/client-interface branch from 0ef3052 to 0cd3d44 Compare February 17, 2017 18:00
@googlebot
Copy link

CLAs look good, thanks!

@donny-dont donny-dont force-pushed the feature/client-interface branch from 0cd3d44 to 6cf06ea Compare February 17, 2017 18:04
@donny-dont
Copy link
Author

@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 {
Copy link
Member

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 Futures.

@@ -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}) =>
Copy link
Member

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.

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));
Copy link
Member

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 urls, not Uris.

Copy link
Author

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.

Copy link
Member

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

K works for me 👍

@donny-dont
Copy link
Author

@nex3 @kevmoo think we're ready to go know.

@@ -4,7 +4,7 @@ author: "Dart Team <misc@dartlang.org>"
homepage: https://github.com/dart-lang/http
Copy link
Member

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.

Copy link
Author

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Member

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.

Copy link
Member

@nex3 nex3 left a 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!

}
}

Uri _uri(url) {
Copy link
Member

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,
Copy link
Member

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
Copy link
Member

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.

@nex3 nex3 merged commit e9dbebd into dart-lang:master Mar 6, 2017
@donny-dont donny-dont deleted the feature/client-interface branch March 6, 2017 22:55
@donny-dont
Copy link
Author

🎊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants