react-native-blob-courier
react-native-blob-courier copied to clipboard
Add onBlock processor to all requests
Originally suggested by @pke in #136
The library is missing the support for processing data that is being transferred.
Proposed solution
- Add
.onBlock(fn: (block) => void, settings?: { blockSize: number })
, similar toonProgress
- Add
.onFinishStream(fn: (block) => void)
which will be called instead of.onBlock
when the last block of the stream arrives
Progress
- [ ] Add
.onBlock
method to TypeScript code base - [ ] Add
.onFinishStream
method to TypeScript code base - [ ] Intercept data and send it in chunks to
.onBlock
and.onFinishStream
over the bridge on Android - [ ] Intercept data and send it in chunks to
.onBlock
and.onFinishStream
over the bridge on iOS - [ ] Allow transformation of intercepted data in
.onBlock
and.onFinishStream
-callbacks - [ ] Write transformed data to the target
- [ ] Add TypeScript tests
- [ ] Add Android tests
- [ ] Add iOS tests
Way to go!
The callback could/should(?) return a promise and get handed in if the given block is the last one. To know its the last block is crucial for some transforms, like crypto or checksum calculation.
What do you mean by that?
Add target toggle that to fetch that sends data not to a file but to /dev/null
The callback could/should(?) return a promise and get handed in if the given block is the last one. To know its the last block is crucial for some transforms, like crypto or checksum calculation.
Whoops, I looked at your use-case and I figured you could just call aes.decrypt
on each received block, and then when the request finishes call aes.finish
. That is too late though and it wouldn't let you transform the last block of data correctly.
How about I also add an .onFinishStream(fn:(block) => void)
-method, which will be called instead of onBlock
when the last block is received, like this?
Add target toggle that to fetch that sends data not to a file but to /dev/null
Scratch that, I rushed jotting down this ticket a little. I removed this requirement.
An additional argument to onBlock could indicate it's the last block. Why would it be too late to call aes.finish then? I know node has a stream API that also uses onEnd alongside onData but I've never understood why it was not comb into one callback with argument indicating the stream is at its end.
Either way, conform to known node patterns or a single callback function is fine with me.
An additional argument to onBlock could indicate it's the last block. Why would it be too late to call aes.finish then?
Your solution with the last
parameter was absolutely fine. I was trying to explain why I thought before we could do without that parameter and why I was wrong. I hope my comment makes more sense now?
Either way, conform to known node patterns or a single callback function is fine with me.
Alright, thank you for your confirmation; the .onFinishStream
-way will be my approach then!