feat: implement FileReader #1690
Conversation
Codecov ReportBase: 94.25% // Head: 89.55% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1690 +/- ##
==========================================
- Coverage 94.25% 89.55% -4.71%
==========================================
Files 53 58 +5
Lines 4965 5257 +292
==========================================
+ Hits 4680 4708 +28
- Misses 285 549 +264
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
There was a problem hiding this comment.
Amazing work!
@KhafraDev I see you don't have any public email address. Would you mind sending me an email?
|
Not objecting to it landing here, but I feel like it would be nice to have it in Node.js core independently of |
|
It would require a lot of work to port it to node core because it uses parts from the webidl and mime specs. Undici also implements
|
|
think PR should rather be made to WPT to change the test to using the blobs new read methods instead... |
|
The Blob class in NodeJS core is kind of B imo, specially when it comes to streaming the content of the blob. (see nodejs/node#42264) + it also lacks all those webidl stuff. I think I also saw some changes/fixes you did to the Blob/File class that I think should rather be reflected onto the NodeJS Core Blob.... So I somewhat agree with @targos on this. either we have all the Blob/File stuff in NodeJS core, or everything is moved to from Core into Undici. But then we would have to move a bunch of things such as object URL and copy/postMessage stuff. I also wish to see some form of "create a file backed up by the filesystem" to be implemented by NodeJS also. That would require the blob to keep track of certain file metadata. This is I also can't extend the NodeJS core As long as Blobs can only be constructed by some stuff in the memory, then they are pretty useless IMO. And you might just as well just use a ArrayBuffer/uint8array instead. Blob main purpose is kind of helping you to offload some of the data and have them being backed up by some file handle and offload some of the memory to a temporary location on the disc. |
The problem with missing webidl is that it would be a pain to convert it to the node equivalent - it's simply easier to implement it in undici. Regarding URL and Blob, I believe both of them interface with c++ at some point. It's not feasible to re-write both in js. Both File and FileReader are implemented in js (same with Deno). If anything, File and FileReader could be implemented in node core directly eventually, however, considering that this FileReader implementation passes 95% of the WPTs already, it will incur very little maintenance burden (1 test with event ordering and 1 due to differences between a microtask and a html task queue). |
|
@KhafraDev this has quite a bit of conflicts. |
| @@ -116,7 +116,8 @@ | |||
| "compilerOptions": { | |||
| "esModuleInterop": true, | |||
| "lib": [ | |||
| "esnext" | |||
| "esnext", | |||
| "DOM" | |||
There was a problem hiding this comment.
this means the types of undici only works if dependent project also adds the dom types. That shouldn't be necessary for a module which explicitly doesn't work in the browser
There was a problem hiding this comment.
Whether it works in the browser or not is not the relevant part. The types are and fetch is based on DOM types per the spec. So it's not weird that we also need to import DOM types as well...
There was a problem hiding this comment.
this PR uses DOMException (and possibly more) from DOM types
Whether it works in the browser or not is not the relevant part.
It's relevant for consumers that undici doesn't work in a typescript environment that isn't configured to be run in the browser. But I can agree it's more of a symptom than a cause 🙂
There was a problem hiding this comment.
unfortunately @types/node doesn't seem to include quite a bit. If you remove that line and run npm run test:typescript we get errors about missing DOMException and EventInit types.
There was a problem hiding this comment.
DOMException doesn't exist in Node, so that makes sense. EventInit seems to be an interface? Not something in MDN at least
There was a problem hiding this comment.
Ah. I tried to run typeof DOMException and got undefined, but I see I wrote typeof DOMEXception 🙈
Regardless, I'm sure definitelytyped would welcome a PR adding DOMException, EventInit and any other missing interfaces. But they shouldn't be pulled from dom.
EDIT: I do see EventInit there already: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/488ef79fe14ea591166813a01ba7f34dfd955b68/types/node/dom-events.d.ts#L78
There was a problem hiding this comment.
EventInit doesn't seem like a problem regardless, we can create our own and it won't overlap with the existing type (although I'm not sure why I can't access it). If we could "feature detect" DOMException, and only use our own type when it doesn't exist, that would be good. That way, the types won't overlap when/if DOMException gets added to node types.
There was a problem hiding this comment.
I tried adding /// <reference types="node/dom-events" /> but the type still couldn't be used. I'll play around a little when I get home.
There was a problem hiding this comment.
I opened a PR to fix this #1762
There was a problem hiding this comment.
I do think this is kind of a TypeScript issue: microsoft/TypeScript#43972
* feat: implement FileReader * fix: implement correct text decoding * fix: make readOperation sync * feat: implement abort * test: event order fails * fix: readAsArrayBuffer incorrect byteLength * fix: base64 data url & default mime type * test: add most remaining tests * fix: update index-fetch.js * fix: correct types
* feat: implement FileReader * fix: implement correct text decoding * fix: make readOperation sync * feat: implement abort * test: event order fails * fix: readAsArrayBuffer incorrect byteLength * fix: base64 data url & default mime type * test: add most remaining tests * fix: update index-fetch.js * fix: correct types
Implements FileReader
Benefits:
Also see:
#1687 (comment)
The API, although outdated, is still perfectly usable in modern environments. Unlike XMLHttpRequest, does not come with any foot guns (synchronous requests).