Skip to content

Support both the console and browser equally #22

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.

Sign up for GitHub

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

Jump to bottom
Closed
DartBot opened this issue Jun 5, 2015 · 18 comments
Closed

Support both the console and browser equally #22

DartBot opened this issue Jun 5, 2015 · 18 comments
Assignees
@nex3
Labels
status-blocked Blocked from making progress by another (referenced) issue type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="96" height="96"hspace="10"> Issue by nex3
Originally opened as dart-lang/sdk#20068

The http package should support IOClient and BrowserClient on even footing. "new http.Client()" should dynamically choose between them based on which is supported.
@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3

Marked this as being blocked by dart-lang/sdk#6943.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

This comment was originally written by [email protected]

This would be awesome.

In my particular case I'm building a client library for a Rest service. My first priority is to build a CLI application using the Client and for that purpose I will need to use the dart:io's HttpRequest. But I want to reuse the Client lib for a Web Interface later on and will then need to use dart:html's HttpRequest.

In order to make that work I have to build wrappers for each HttpRequests.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3

It's worth noting that you can use the http package on both the browser and the console today; you just need to explicitly choose to instantiate either an IOClient or a BrowserClient and pass it in to the code in question.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

This comment was originally written by [email protected]

Huh. Why didn't I notice that until now? Please excuse a newbie. :)

Reading "http package" I was just thinking of some future http functionality - I didn't know it was a package that already existed. Thank you for guiding me.

@DartBot DartBot added type-enhancement A request for a change that isn't a bug Started labels Jun 5, 2015
@DartBot DartBot mentioned this issue Jun 5, 2015
Closed
@DartBot DartBot removed the Started label Jun 6, 2015
@bergwerf
Copy link

Is anything planned to resolve this? This blocks me from using http.get etc. functions. I would actually be ok with manually setting what Client is used by _withClient once in the top-level package (the application). Currently the only 'clean' alternative is passing clients around through all of my code so the top-level package can specify the right client for the environment.

@nex3
Copy link
Member

nex3 commented Apr 27, 2016

This is blocked on dart-lang/sdk#24581. Once full cross-platform imports are fully supported and stable, I'll fix this ASAP.

@nex3 nex3 added the status-blocked Blocked from making progress by another (referenced) issue label Apr 27, 2016
@isoos
Copy link

isoos commented Mar 7, 2017

Would it be possible to expose the Client, Request, and Response interfaces separately of the browser and the console environment? It would make writing cross-platform REST libraries much much better, because at least they could accept the Client as a parameter, and they won't be tied to a particular platform, while their initialization could be platform-specific.

@isoos
Copy link

isoos commented Mar 8, 2017

As a temporary measure, I've exposed the BaseClient interface in here: https://pub.dartlang.org/packages/http_client

I'd be happy to scrap the package as soon as http supports the same or similar interface.

@nex3
Copy link
Member

nex3 commented Mar 9, 2017 •
edited
Loading

Don't export private members from another package. You're going to break your users, and set a bad example for the ecosystem at large.

@isoos
Copy link

isoos commented Mar 9, 2017

I wish http would export these members in the same or very similar way. Any comment on whether or when we can expect that?

@nex3
Copy link
Member

nex3 commented Mar 9, 2017

It's still blocked on dart-lang/sdk#24581.

@isoos
Copy link

isoos commented Mar 9, 2017

I don't see why that issue is blocking my request. Why couldn't we introduce an interface that both BrowserClient and IOClient is implementing? It could be as simple as Future<StreamedResponse> send(BaseRequest request); and maybe a few helper wrapper methods for GET and POST requests without streaming.

@nex3
Copy link
Member

nex3 commented Mar 9, 2017

Both BrowserClient and IOClient implement the Client interface.

@isoos
Copy link

isoos commented Mar 9, 2017

But Client is not in a separate platform-neutral library, it does have references to IOClient and transitively to dart:io.

@nex3
Copy link
Member

nex3 commented Mar 9, 2017

...which is why this is blocked on dart-lang/sdk#24581 (although as of Dart 1.23 all platforms will be able to import dart:io without issue, so I'm not sure why that's a problem).

@isoos
Copy link

isoos commented Mar 9, 2017

If Client (or WhateverClient) would be separate, it wouldn't be blocked on dart-lang/sdk#24581. Not everyone is on an unreleased Dart version, and even it is released, it may take some time to switch.

@nex3
Copy link
Member

nex3 commented Mar 9, 2017

If Client (or WhateverClient) would be separate, it wouldn't be blocked on dart-lang/sdk#24581.

Yes, but the API would be substantially worse.

Not everyone is on an unreleased Dart version, and even it is released, it may take some time to switch.

Dart's release cycle is fast, so I'm not especially concerned about adoption time. It'll be a lot easier to adopt than an entirely new API.

@isoos
Copy link

isoos commented Mar 9, 2017

Yes, but the API would be substantially worse.

I disagree. It would allow a single interface to be used in platform-agnostic REST clients today, not at some point in the future.

@zoechi zoechi mentioned this issue Mar 15, 2017
Closed
@natebosch natebosch mentioned this issue Sep 12, 2018
Merged
jakemac53 added a commit that referenced this issue Sep 13, 2018
@jakemac53
Make package:http/http.dart support all platforms (#198)
0eb481b 
Fixes #22

Adds config specific imports to make `package:http/http.dart` support all platforms, and allow the `Client` factory constructor to return a valid `Client` for the web platform.

This should eliminate almost all need for the platform specific imports for consumers, although it does also add the `io_client.dart` public import.

Passes presubmit internally, with edits in only 3 files (they use the IoClient constructor directly, and pass in an HttpClient). Externally build_runner now supports config specific imports as well, I am currently working on validating everything works as expected there with this change.

### New Features

* The regular `Client` factory constructor is now usable anywhere that `dart:io`
  or `dart:html` are available, and will give you an `IoClient` or
  `BrowserClient` respectively.
* The `package:http/http.dart` import is now safe to use on the web (or
  anywhere that either `dart:io` or `dart:html` are available).

### Breaking Changes

* In order to use or reference the `IoClient` directly, you will need to import
  the new `package:http/io_client.dart` import. This is typically only necessary
  if you are passing a custom `HttpClient` instance to the constructor, in which
  case you are already giving up support for web.
@shtengel shtengel mentioned this issue Sep 28, 2018
Closed
@aliaafreen aliaafreen mentioned this issue Nov 24, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nex3 nex3

Labels
status-blocked Blocked from making progress by another (referenced) issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@nex3 @bergwerf @isoos @DartBot