List view
Understream's API should be refined to mirror Underscore's more closely. The idea will be to make Understream a library of utility functions of three types: 1. Functions to convert data to Readable streams and vice versa 2. Functions that take a Readable stream and transform its data 3. Functions that allow you to create chains of transformations The first category contains source functions like `fromArray` and `fromString`, which create Readable streams out of basic datatypes. It also contains sink functions like `toArray` and `toNull`, which behave like `run` currently behaves, piping a Readable stream to an Writable stream to start the flow of data and accumulate results and errors, passing them to a callback. The second category contains functions that are analogous to Underscore functions, such as `map`, `reduce`, and `filter`. They take a Readable stream and return a new Readable stream. They are static methods on the Understream object. We can aim for feature parity with Underscore where appropriate. The third category contains functions like `chain` and `value`, which behave almost exactly like their Underscore equivalents. `chain` takes a Readable stream and wraps it so that it has a method for each transformation (and so that those methods return a wrapped stream). `value` is a method on the wrapped stream that returns the underlying stream. The wrapped objects should also have the sink functions from the second category, so that instead of ending a chain in `value`, you can also end it by running the stream. This design will allow new mixins to be written as compositions of transformations from the second category. A mixin is just a function that takes a Readable stream and returns a Readable stream. Lastly, Understream will no longer be mixed into the Underscore object (`_`), but have its own dedicated variable.
No due date•0/4 issues closed