Comments (22)
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 replacer
s and reviver
s (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
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.
Related Issues (20)
- Add support for AbortSignal HOT 2
- unable to modify request header using an interceptor HOT 6
- ReadableStream uploading is not supported (Safari 11.1.1) HOT 7
- Cannot find name 'AbortSignal' HOT 5
- Converting repo to typescript HOT 5
- HTTP methods must be upper case HOT 2
- call trackRequestEnd when fetch fails HOT 8
- invalid type definition for RetryInterceptor HOT 3
- Version 1.8.0 does not work in Android Cordova App HOT 7
- version 1.8.0 generates infinite loop with retry configured to 0 HOT 2
- Version 1.8.1 "cannot find module 'aurelia-fetch-client'" HOT 3
- Is this package version number following semver? HOT 5
- config.rejectErrorResponses - lots of console warnings HOT 6
- Fetch attempts fail with TypeError on Safari 10.1 HOT 1
- Broken typings? HOT 1
- Question - json()'s benefit of converting to Blob HOT 17
- setting no-cors mode affecting content-type header behaviour
- Interceptor.responseError question HOT 5
- Fetch client doesn't like array assignment of JSON data HOT 1
- Feature request: Add aurelia-fetch-client-requests-drained event. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fetch-client.