Skip to content
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

Easily output normal node streams #129

Open
mpj opened this issue Sep 16, 2014 · 7 comments
Open

Easily output normal node streams #129

mpj opened this issue Sep 16, 2014 · 7 comments

Comments

@mpj
Copy link
Contributor

mpj commented Sep 16, 2014

When I'm writing modules, I'd like the API I expose to return normal node streams instead of highlands special ones. Some kind of .toNodeStream() would be nice. This would also be solved if highland streams subclassed node streams.

@greelgorke
Copy link
Collaborator

which part of the core API do you miss on the Highland stream? Or better, why do you need it really? :)

@mpj
Copy link
Contributor Author

mpj commented Sep 29, 2014

@greelgorke I don't miss anything, I just don't want to my modules that use highland to provide a predictable API. It's how when you use a DOM manipulation library that uses jQuery behind the scenes, you don't want it's API to return jQuery objects, you just want plain DOM elements.

@greelgorke
Copy link
Collaborator

@mpj i understand that. my question though targets to the fact, that all highland streams support some of core api already, most importantly the pipe protocol.

though there is no .read() on highland, which could be wrapper around pull. insofar this would make a nice pr :) if i only had time

@stephen-bartell
Copy link

return _()
  .pipe(new Stream.PassThrough({ objectMode:true }))

is what i do

@greelgorke
Copy link
Collaborator

this is also a way, sure, but it's then just a node.js stream. After reading @mpj's last post again, i have to say, that the comparison with jQuery isn't that good. jQuerys aim was always to handle and hide DOM, so there is this clear focus, and it legit to return DOM elements here.

Highland.js isn't a wrapper around Node.js Streams. If you look at the first paragraphs, Array is first class predecessor, and Node.js is the second, which you also can see in the api.

But with saying that i'm still convinced to have a full complient api with node streams.

@yangit
Copy link

yangit commented Jan 6, 2015

Here it the non compliant part:
Node streams can be consumed multiple times w\o extra effort.
If I'm passing my stream to other lib which later does
stream.pipe(a)
stream.pipe(b)
Then I have an exception.

One example would be GulpJS

@NathanRSmith
Copy link

Thanks for the tip @stephen-bartell. That solved a problem I was having. I was trying to pipe a highland stream into a REST PUT request using the request.js module but it was only sending the first ~15kb depending on some settings I could tweak. I'm not exactly sure what was wrong, but as soon as I put the intermediate .pipe(new Stream.PassThrough({ objectMode:true })) in it started sending the whole stream.

Even though this method works, it still feels like a hack and it would be nice if there was a more concise way to get back to regular node streams. Or at least info in the docs discussing how to send data to non- objectMode=true streams.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants