Comments (11)
To be clear, the problem with XMLHttpRequest
is that it does not support "no-cors", does not deal with Request
and Response
objects, etc. All of those are essential in a service worker world.
from fetch.
So point is what fetch
is needed only for ServiceWorkers?
To be clear too, we (maybe only me) do not think what XHR is best API ever. We just saying fetch
cannot replace XHR, but it's promoted as it can. Also, XHR can easily have most of fetch
parts, such as Streams, no-cors
mode and so on.
So, by no doubts, it's very good to have separate from XHR low-level API with Stream and other cool things which will allow 100% implement XHR over it. In the mean time, fetch
with all its Promise-like-style-way is more suitable for simple interactions, just fetch and use data, like JSON. Fast. Simple. Strong.
Streams and other low-level stuff seems cumbersome over fetch
.
from fetch.
Can you show (with code) how streams are cumbersome with fetch, in comarrison to an XHR-based API?
With fetch:
fetch(url).then(response => {
var reader = response.body.getReader();
var decoder = new TextDecoder();
function drain(valueSoFar) {
return reader.read().then(function(result) {
valueSoFar += decoder.decode(result.value || new Uint8Array, { stream: !result.done });
if (result.done) return valueSoFar;
return drain(valueSoFar);
});
}
return drain();
}).then(function(fullText) {
console.log(fullText);
});
With async/await:
fetch(url).then(async response => {
var reader = response.body.getReader();
var decoder = new TextDecoder();
var fullText = '';
var result;
do {
result = await reader.read();
fullText += decoder.decode(result.value || new Uint8Array, { stream: !result.done });
} while (!result.done);
console.log(fullText);
});
from fetch.
Closing this as none of this is very actionable.
from fetch.
Why closing it? I have not enough time to argue with you all the time because full-time job, family, other things. There was enough arguments in "Aborting fetch" thread and still are. There was enough arguments in the Internet itself too. All this seems like you are blind. If you not planning to consider this issue at all and will ship fetch
anyway regardless any feedback, then just say it -- "we do not case, we will ship it anyway". This will be perfect Open Web.
from fetch.
Particularly you may see this comment: #27 (comment)
from fetch.
fetch()
has already shipped, as far as I know. (And has been specified in this way for over ten months, and agreed upon much longer than that.) In any event, there's many platform APIs that return promises where we might want to cancel the underlying activity. This is not novel.
from fetch.
It's shipped only to ServiceWorkers and behind the flag in the stable releases, according to this page: http://caniuse.com/#search=fetch
Here is for example my first filled issue about aborting problem with fetch
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27841 it's dated by 2015-01-16, almost 3 months from now. I believe there was not much promotion about it in those 10 months and not enough now. So I do not see here or in #27 web-devs arguing what fetch
is very good.
In any event, there's many platform APIs that return promises where we might want to cancel the underlying activity. This is not novel.
This only means what not only fetch
has problems and what not all should be built around Promises, at least while there is not good solution for canceling them. And best solution of course is to not use Promises.
As you may notice, we all who are against fetch
with Promises trying to solve cancellation problem. There are few good proposals by @WebReflection and even one by myself. We can live with fetch
and cancelable Promises, as far as they will be cancelable. But this all seems what you are planning to ignore all things proposed by different people and again decide all off-line.
One more thing -- Promises nature is not about cancelation in general and by shipping more-and-more API with Promises which should be cancellable you are doing same mistake again-and-again. It's not too late for ES7 to not use Promises as a basis for async
/await
since Promies does not fill all the requirements.
from fetch.
But this all seems what you are planning to ignore all things proposed by different people and again decide all off-line.
As far as I can tell @jakearchibald is doing a great job at making progress. You don't make progress with lots of repeated arguments though, you need to experiment, talk to the wider community, etc. Which is why he's probably not always updating that thread, which has over a 100 posts now and does not seem any closer to a solution.
from fetch.
which has over a 100 posts now and does not seem any closer to a solution.
This is exactly a point why same arguments are pops up again and again :-)
from fetch.
who would have thought that fetch has now taken over the good old xhr in modern code standards, deno and node now ship with fetch built in.
still wish to see fetch deprecated? :P
from fetch.
Related Issues (20)
- Automatic decompression should sanitize `Content-Encoding` and `Content-Length` headers from the response HOT 1
- When there is an issue with the URL parameter, fetch does not have any errors
- add a method to get a Uint8Array to Body HOT 4
- Fetch with Flask or Microdot HOT 1
- Service worker "handle fetch" seems to assume it's called in parallel HOT 2
- Redirect loop handling not discussed
- Add compression dictionary negotiation and decoding to the fetch processing model HOT 4
- Reconsider default Accept values for images
- Fetch support for explicit resource management
- Consider renaming or replacing http3only? HOT 1
- [render-blocking] The links of "render-blocking" in fetch are vague HOT 2
- Define what consequences NULL bytes (0x00) or other invalid values in header names have HOT 1
- 0x00 byte (%00) in a data: URL
- fetch does not allow caching requests with a null client HOT 1
- Question about stream handling around fetch requests with integrity metadata HOT 3
- Allow `new Response` with 101 status code HOT 6
- Question regarding preflight requests using the original request destination HOT 1
- Expected behavior of Response.redirect(null)? HOT 1
- Spec unexpectedly requires caching 30x responses themselves — rather than caching the result of running HTTP-redirect fetch to follow the 30x redirects HOT 9
- Spec WWW-Authenticate and Proxy-Authenticate handling in HTTP-network-or-cache fetch
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.