Skip to content
This repository was archived by the owner on Mar 16, 2019. It is now read-only.
This repository was archived by the owner on Mar 16, 2019. It is now read-only.

readStream and writeStream should not return a promise #497

Open
@lll000111

Description

@lll000111

Note: The issue is the creation of streams, not the streams themselves.

https://github.com/wkh237/react-native-fetch-blob/blob/master/fs.js#L89

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.

Stream generating functions in node: https://nodejs.org/dist/latest-v8.x/docs/api/fs.html#fs_fs_createreadstream_path_options

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) :-)

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions