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
{{ message }}
This repository was archived by the owner on Mar 16, 2019. It is now read-only.
First, it is not necessary. The read/write stream objects (RNFetchBlobReadStream and RNFetchBlobWriteStream, respectively) are available right away, synchronously.
What everybody does is create a stream object and return it, and ALL events, from "open", "data", to "error", "close", "end" can then be subscribed to.
I do see possible value for making a stream a promise if it resolves at the "end" event - BUT I would not do that in a library (they are supposed to be more generic and this is way too special for a given programming situation), and I don't see any value in making the mere creation of the stream object asynchronous (since the stream object creation itself should always be - and in the RNFB case is - synchronous to begin with).
Removing the surrounding and unnecessary Promise in fs.js would be a breaking API change, but I would still propose to do it, it is tiny, makes code easier (no then(...) or await necessary to wait for the stream object) and makes the use consistent with how streams are supposed to be generated.
PS: This bugs me because we are writing a lib that runs on node, react-native and the browser - and RNFB had me make stream-object-creation wrap into a promise for all platforms for no reason (we have 95% identical code and a very small platform-independent layer that hides platform specifics, so if one platform does this asynchronously I have to do it that way for all) :-)