Differences from http-client about fetch-client HOT 22 CLOSED

There is some documentation here: https://github.com/aurelia/fetch-client/tree/master/doc
We'll be moving those docs to our main site soon.

from fetch-client.

+1

from fetch-client.

Most definitely. A quick explanation in the meantime:

http-client is the Aurelia project's official ajax library. It doesn't integrate with Aurelia in any significant way, but it does provide an API that's consistent with the rest of the framework, and it provides functionality like interceptors that are commonly needed in Aurelia applications.

fetch-client was created mostly because we got so many requests for http-client to be rewritten to use Fetch. Fetch already has a nice clean API, and it natively supports many of the features that libraries like http-client must implement on top of XHR, so we couldn't see much practical benefit to keeping http-client's API while using Fetch under the hood. Instead of abstracting Fetch behind our own API, we tried to just extend it with the features we wanted (like interceptors) in this new library. So, fetch-client's API is pretty much the same api as the native Fetch, just with a very thin wrapper that lets us add a little functionality. It's mostly just an alternative for those who would prefer to code against the standard Fetch API.

Both fetch-client and http-client will work just fine for most applications. fetch-client does have the same limitations as Fetch itself (e.g., Fetch requests can't yet be aborted), so that may be a factor for you. It's possible that we'll eventually try to retire http-client in favor of fetch-client as the official HTTP library, but for the time being we're maintaining both while we collect feedback.

from fetch-client.

That's great! Is the fetch-client API compatible with http-client's? I see it exports the same class name: HttpClient. Since I'm using http-client extensively I'd like to know if changing from

import {HttpClient} from "aurelia-http-client"

to

import {HttpClient} from "aurelia-fetch-client"

would break something or just do the magic.

from fetch-client.

In case I want in the aurelia-auth plugin to replace http-client with fetch-client, would it still be possible to keep in a way the functionality of adding automatically the JWT token on each authenticated request.
Currently in the http-client, it's done with following code:

RequestBuilder.addHelper('authTokenHandling', ()=>{
            return (client, processor, message)=>{
                if (this.auth.isAuthenticated() && this.config.httpInterceptor) {
                    var tokenName = this.config.tokenPrefix 
                    ? this.config.tokenPrefix + '_' + this.config.tokenName : this.config.tokenName;
                    var token = this.storage.get(tokenName);

                    if (this.config.authHeader && this.config.authToken) {
                        token = this.config.authToken + ' ' + token;
                    }

                    message.headers.add(this.config.authHeader, token);
                }
            }
        });

I presume the way to go is to use directly the interceptor:

httpClient.configure(config => {
    config
        .withInterceptor({
            request(request) {
                 //here we add the JWT token via more or less same logic as above

So, the base scenario (just adding the JWT token) can be probably ported easily to fetch client.
But I want to add a functionality, namely the ability to override on ad hoc base the addition of the JWT token. So, imagine for a particular request I want no JWT token to be added.
In the http-client, I believe that the mechanism of the helper methods could just do that, but what's the way to go with the fetch-client?

thanks.

from fetch-client.

@heruan Different APIs. https://gist.github.com/bryanrsmith/14caed2015b9c54e70c3

@paulvanbladel Yes, the interceptor will work. I suppose you could augment a Request before passing it to HttpClient.fetch, but the library has intentionally kept the signature of the Fetch API so there isn't a way to configure additional options. I'd suggest using a separate client if you want to make requests with a different configuration.

from fetch-client.

@bryanrsmith do I need to use https://github.com/athaeryn/farfetched to mock this for unit testing?

from fetch-client.

@onlywei You could use farfetched if you want to include aurelia-fetch-client in your unit test. It might be better to mock fetch-client instead, though, so you are only testing your own code.

from fetch-client.

We are making Aurelia-fetch-client our official http library for the beta and onward.

from fetch-client.

Does it support HTTP methods such as POST, PUT, DELETE?

from fetch-client.

yes

from fetch-client.

We are making Aurelia-fetch-client our official http library for the beta and onward.

Thanks for this feedback - it helps us choose. Perhaps worth adding as guidance to docs? (Unless I missed it)

from fetch-client.

I think it would be a good idea to answer the question "Why should I use this fetch-client instead of fetch directly?" in the README.md

from fetch-client.

@bryanrsmith Would you be able to expand the readme with some thoughts on this?

from fetch-client.

Also, does fetch-client support methods like POST, PUT, etc.? The old-style Aurelia docs.html page described how to do POST, PUT, and other HTTP request with http-client, I think it must be made clear how (if possible at all) make API calls with http-fetch.

from fetch-client.

And I would be very cautious on choosing fetch-client as the official Aurelia HTTP client implementation, since with it it's not possibile to use replacers and revivers (the JSON processing is hard-coded on the fetch implementation) and requests cannot be aborted (an essential feature IMHO, when working with remote APIs).

I think the advantages of http-fetch over http-client should be exposed very clearly.

from fetch-client.

Sure. The docs say this, but I will elaborate:

The project aims to embrace and expose the new Fetch API, while providing features important in web applications: default configuration of request parameters, interceptors, and centralized request tracking.

I'll also help move the docs into the docs website. They're currently at https://github.com/aurelia/fetch-client/tree/master/doc

@heruan:

Also, does fetch-client support methods like POST, PUT, etc.?

Yes. Again, I'll expand the docs. There is one example POST in there now. The method is specified in the same way as the native fetch API.

it's not possibile to use replacers and revivers (the JSON processing is hard-coded on the fetch implementation)

Sure it is. If you read the response body with the built-in .json() reader then you give up control of deserialization to the browser (the benefit being that it becomes async and nonblocking), but you can read the response as text and then do whatever you want with it.

let json = await response.text();
let content = JSON.parse(json, (k, v) => { if (k !== 'a') return v; });

requests cannot be aborted (an essential feature IMHO, when working with remote APIs).

Yes, this is unfortunate. We've chosen to leverage the new browser API before it's complete. This is a common criticism of the Fetch API, and the people developing it have stated that they're working on designing cancelation support. We will update our library as soon as a design is finalized. In the meantime if you need the ability to abort requests then it may be best to choose another library. We've provided this library for completeness, but just to clarify: it is completely optional. One of the primary design goals of Aurelia is modularity. If this library isn't meeting your needs then you can certainly use superagent, or axios, or any other HTTP client in your Aurelia project.

from fetch-client.

I'm don't quite have my head around the dependency versioning yet, but I noticed that the GitHub fetch polyfill / package now has a stable version of 1.0.0, yet the jspm dependencies has the following version specified for the latest Skeleton template projects:

"fetch": "github:github/fetch@^0.10.1"

So I'm trying to understand when I should / shouldn't update dependencies that have newer stable versions. If I have it correctly, if just the minor version changes (e.g. 0.10.1 --> 0.12.0) then it is generally considered compatible and should be safe (unless specific issues are known e.g. [email protected]).

What about the major version upgdates? For example:

• fetch@^0.10.1 (latest stable is ^1.0.0)

Same goes for the npm devDependencies that the Aurelia skeletons specify:

• del@^1.2.1 (latest stable is ^2.2.0)
• object.assign@^1.1.1 (latest stable is ^4.0.3)
• vinyl-paths@^1.0.0 (latest stable is ^2.1.0)
• yargs@^2.3.0 (latest stable is ^3.32.0)

Or is there some other reason Aurelia has older major versions specified ?

from fetch-client.

@Jaans Usually, you want to let the caret range take care of updating any dependency. Manually modifying caret ranges usually means breaking changes, thus resulting in more work (code changes for your library, checking if tests pass, fixing tests, etc.).

from fetch-client.

I early moved from 'http' to 'fetch' and all ist fine.
But now i found me digging around because IE and EDGE does not support fetch yet.
I didn't figure out how to use a polyfill for that :-(

from fetch-client.

FYI - If anyone is using fetch with webpack (as opposed to JSPM). The below is what we use to provide a fetch polyfill for browsers that don't yet have a native fetch implementation.

First reference the whatwg-fetch NPM package (this would be a dependency of your project).
Here's a snippet from our package.json file:

"private": true,
  "scripts": {
    "dev": "webpack-dev-server --config webpack.config.js --hot --inline --progress --devtool cheap-module-eval-source-map",
    "build": "webpack --config webpack.config.js --progress --profile",
    "prod": "webpack -p --config webpack.prod.config.js --progress --devtool source-map"
  },
  "dependencies": {
    "aurelia-animator-css": "^1.0.0-beta.1.2.0",
    "aurelia-bootstrapper-webpack": "^1.0.0-beta.1.0.0",
    "aurelia-dialog": "^0.5.10",
    "aurelia-event-aggregator": "^1.0.0-beta.1.2.0",
    "aurelia-fetch-client": "^1.0.0-beta.1.2.1",
    "aurelia-framework": "^1.0.0-beta.1.2.2",
    "aurelia-history-browser": "^1.0.0-beta.1.2.0",
    "aurelia-logging-console": "^1.0.0-beta.1.2.0",
    "aurelia-polyfills": "^1.0.0-beta.1.1.2",
    "aurelia-router": "^1.0.0-beta.1.2.1",
    "aurelia-templating-binding": "^1.0.0-beta.1.2.1",
    "aurelia-templating-resources": "^1.0.0-beta.1.2.2",
    "aurelia-templating-router": "^1.0.0-beta.1.2.0",
    "aurelia-validation": "^0.6.7",
    "bootstrap": "^3.3.6",
    "font-awesome": "^4.6.1",
    "jquery": "^2.2.3",
    "jquery-ui": "^1.10.5",
    "moment": "^2.12.0",
    "toastr": "^2.1.2",
    "whatwg-fetch": "^0.11.0"
  },
  "devDependencies": {
    "aurelia-tools": "^0.1.22",
    "aurelia-webpack-plugin": "^1.0.0-beta.1.0.2",
    "css-loader": "^0.23.1",
    "exports-loader": "^0.6.3",
    "file-loader": "^0.8.5",
    "html-loader": "^0.4.3",
    "html-webpack-plugin": "^2.15.0",
    "imports-loader": "^0.6.5",
    "raw-loader": "^0.5.1",
    "style-loader": "^0.13.1",
    "ts-loader": "^0.8.2",
    "tslint": "^3.7.4",
    "typescript": "^1.8.10",
    "typings": "^0.7.12",
    "url-loader": "^0.5.7",
    "webpack": "^1.12.15",
    "webpack-dev-server": "^1.14.1"
  }

Then in your webpack configuration file (typically webpack.config.js), provide a plugin entry for fetch. Below is an example from our configuration file that uses the built-in webpack ProvidePlugin to export the whatwg-fetch polyfill and globally expose it where your would normally find the native implementation of fetch (i.e. global.fetch ). This then allows aurelia-fetch-client to find and use the polyfill.

For those interested, also shown in the configuration is how to globally expose jQuery as $ (instead of referencing it everywhere) and also how to specify the AureliaWebpackPlugin when using aurelia-dialog and aurelia-validation so that they are correctly bundled by webpack.

     entry: {
        main: [
            './src/main'
        ]
    },
    output: {
        path: path.join(__dirname, 'dist'),
        filename: 'bundle.js'
    },
    plugins: [
        new webpack.ProvidePlugin({
            'fetch': 'imports?this=>global!exports?global.fetch!whatwg-fetch',
            $: "jquery",
            jQuery: "jquery"
        }),
        new AureliaWebpackPlugin({
            includeSubModules: [
                {
                    moduleId: 'aurelia-dialog'
                },
                {
                    moduleId: 'aurelia-validation'
                }
            ]
        })
    ],
    module: {
        loaders: [
            { test: /\.ts$/, loader: 'ts-loader', exclude: /node_modules/ },
            { test: /\.css?$/, loader: 'style-loader!css-loader', exclude: /(?:aurelia-dialog)|(?:src)/ },
            { test: /\.css?$/, loader: 'raw-loader', include: /(?:aurelia-dialog)|(?:src)/ },
            //{ test: /\.html$/, loader: 'raw-loader' },
            { test: /\.html$/, loader: 'html-loader' },
            { test: /\.(png|gif|jpg)$/, loader: 'url-loader?limit=8192' },
            { test: /\.woff2(\?v=[0-9]\.[0-9]\.[0-9])?$/, loader: 'url-loader?limit=10000&minetype=application/font-woff2' },
            { test: /\.woff(\?v=[0-9]\.[0-9]\.[0-9])?$/, loader: 'url-loader?limit=10000&minetype=application/font-woff' },
            { test: /\.(ttf|eot|svg)(\?v=[0-9]\.[0-9]\.[0-9])?$/, loader: 'file-loader' }
        ]
    }

from fetch-client.

Another limitation of the fetch api is that it does not yet support progress reports. So if you are uploading files, it may not be a good choice.

from fetch-client.