You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I understand that fetch generally has fewer ways of getting http responses than something dealing with opening and reading files, this API -- with regards to reading files in particular -- is surprisingly divergent, IMO. I personally found the initial example to be a bit hard to follow, where I was bouncing around inside the code to figure out what was being read, what happens when it's read, and what's initializing the read.
I guess I would have expected something like fetch and how you read the body:
constresponse=awaitfetch('/some/image.png');if(!response.ok){thrownewError('Not good');}constreader=awaitresponse.body.getReader();forawait(constdataofreader){// do things with binary data here.}
Where a file read that aligns more with the existing API might look like:
constfiles=awaitshowOpenFilePicker(/* options */);for(constfileoffiles){console.log(`Reading ${file.name}`);// Get a readerconstfileReader=awaitfile.content.getReader();// Read the binary dataforawait(constdataoffileReader){// do something with binary data here}}
The text was updated successfully, but these errors were encountered:
One thing I'll mention before addressing your feedback...
I personally found the initial example to be a bit hard to follow, where I was bouncing around inside the code to figure out what was being read, what happens when it's read, and what's initializing the read.
if things are hard to follow.... yeah sorry about that. I wish things weren't split across two specs, too
if you have feedback about that method in particular, please consider filing an issue on that spec (and we can close this one)
While I understand that fetch generally has fewer ways of getting http responses than something dealing with opening and reading files, this API -- with regards to reading files in particular -- is surprisingly divergent, IMO.
The prior art this API builds on is FileSystemFileEntry.file() which returns (via a callback, since it predates promises) a File. File extends Blob, from which you can (among other things) get a ReadableStream (which is what response.body gets you)
While I understand that
fetch
generally has fewer ways of getting http responses than something dealing with opening and reading files, this API -- with regards to reading files in particular -- is surprisingly divergent, IMO. I personally found the initial example to be a bit hard to follow, where I was bouncing around inside the code to figure out what was being read, what happens when it's read, and what's initializing the read.I guess I would have expected something like
fetch
and how you read thebody
:Where a file read that aligns more with the existing API might look like:
The text was updated successfully, but these errors were encountered: