-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: streams in browser #116
feat: streams in browser #116
Conversation
bac02e1
to
a808810
Compare
Since there is Btw. not sure why the second build of Travis is failing. Local tests are working for me. Do you might have some pointers about what is wrong? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your PR!
I restarted the macOS build but it's taking forever, might be an issue with Travis. It passes on Linux anyways so I don't think it's caused by your changes.
Do you have more details about the issue using rollup please? Is this a known bug?
If it can't be worked around I think it's better to use webpack for the timeline package as well but I'd rather avoid changing tooling to accommodate individual features.
Regarding adding downloadReadableStream()
, what would be the use case please?
Great! Well there are several pointers for discussion about
Also regarding the But it only will bring compability with streams, yet it won't bring their actual advantage. Should I add it anyhow in order to unify the browser/Node API more? Regarding the |
Thanks for the insights, the rollup/readable-streams seems like a real can of worms so better switch to webpack as you did. Could you also switch to webpack in the Regarding Adding Thanks! |
Will do! Most probably during tomorrow or on Monday.
…On Thu, Nov 14, 2019, 15:18 Paul Le Cam ***@***.***> wrote:
Thanks for the insights, the rollup/readable-streams seems like a real can
of worms so better switch to webpack as you did. Could you also switch to
webpack in the timeline package please so it's more consistent?
Regarding uploadFileStream() makes sense, can you remove the change in
docs/api-bzz.md then please?
Adding downloadReadableStream() sounds like a good idea, maybe it could
simply be named downloadStream() as it can only be readable anyways?
Could you please add tests to cover the behaviour both for raw files and
manifests if you add this method?
Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#116>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABOKPOVZIOD2KUKVKW4X2JLQTVMZXANCNFSM4JM74RXQ>
.
|
Thanks! |
8c2f42a
to
3207ef0
Compare
So here I present you another version :-D I added the stream support as discussed. Tests are passing, webpack integrated, docs written. Let me know your thoughts! |
@vujevits if you have the chance could you please review this PR? |
@PaulLeCam seems like |
@vujevits OK perfect, thanks for the feedback! |
So here is hopefully last version :-) |
@AuHau CI is failing because of ESLint issues, could you run |
e3e6658
to
73dad00
Compare
Fixed (MacOS still runs as always) |
73dad00
to
08c6d77
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the changes!
I present you patch that allows usage of
downloadDirectory
anddownloadObservable
in browsers.I was fighting a lot with
readable-streams
in browsers as there was some problem of proto-chain in Duplex streams. It seems thatrollup
is to blame for bad bundling. I switched it to webpack and it works as expected. Is that a problem?I switched it only in the
swarm-browser
bundle and keptrollup
in thetimeline
build. Should I unify it to webpack? From bundle size there was around 10kb increase in the production build to 242kB.