v2 ideas about concat-stream HOT 4 OPEN

• cb(err, data) is annoying if there isn't ever an error. Why not just omit that parameter like it presently is?

I'm -1 on the .pipe(cat.string()) and .pipe(cat.buffer()) features but agree that getBody is too complex.

browserify v3 uses a typed array backed data structure for Buffer now, so you should just always get back a buffer or if the stream has been set to objectMode, you should get an array of objects. That would greatly simplify the getBody decoding.

Promises and generators would just add clutter to this relatively simple API.

from concat-stream.

should this library be able to concatenate streams - a bit like what https://github.com/felixge/node-combined-stream ?

if yes, I don't understand "concat-stream should never have any errors" because shouln't concat-stream handle the errors of the underlying streams to report via cb(err, data) ?

from concat-stream.

What about streams2 implementation??

from concat-stream.

@jeromew this library is able to concatenate all the data within a single stream into a single datum (string, buffer, etc).

For the record, regarding error-catching ... (since I had to test this to find out)

If you pipe a readable stream to this or any other writable stream (with Readable.protototype.pipe), errors will not be piped downstream along with the data.

When using this library, you must handle upstream errors yourself

function getSomething (cb) {
  var readable = getReadableStream();
  readable.on('error', end); // <--- handle upstream errors
  readable.pipe(concat(function(data){
    end(null, data);
  }));

  var ended = false;
  function end (error, data) {
    if (ended) return;
    ended = true; 
    cb(error, data); 
  }
}

Besides any upstream errors, there are no other errors to expect.

from concat-stream.