staltz / xstream

An extremely intuitive, small, and fast functional reactive stream library for JavaScript
http://staltz.github.io/xstream/
MIT License
2.38k stars 137 forks source link

Better debug in javascript #325

Open ftaiolivista opened 3 years ago

ftaiolivista commented 3 years ago

When working in Js without Typescript help the lib don't warn you when passing bad values to stream constructor

A classic example is merging or composing null values:

const stream1 = xs.never() const stream2 = xs.never() const stream3 = null xs.merge(stream1, stream2, stream3)

The code don't give error on network setup but only at network run time without telling where the the problem came for.

Would not be bad to add a lite type check on merge and combine, something like

var Merge = /** @class */ (function () {
    function Merge(insArr) {
        // Are all operand streams?
        for (const v of insArr) {
            if (!v || !v._add) {
                throw Error('Must be a Stream')
            }
        }
       //=================
        this.type = 'merge';
        this.insArr = insArr;
        this.out = NO;
        this.ac = 0;
    }
staltz commented 3 years ago

I'm sorry, but runtime type checks do add a lot of checks (if you do this consistently for all operators and all input cases) which negatively impacts both performance and library size. JavaScript users accept the undefined is not a function mantra (which happens even with standard JS data structures, e.g. [10,20,30].findIndex(20)), while TypeScript users get input type safety.

staltz commented 3 years ago

One good thing we could do, though, is to ignore nulls that are passed to combinators like merge and combine.

ftaiolivista commented 3 years ago

agree with you about performance. Filter out null probably will make things harder to debug. Maybe the possibility to run xstream in two flavors? with lite typecheck and without, something like sanctuary?

staltz commented 3 years ago

Maybe the possibility to run xstream in two flavors?

That's possible, but it's a lot of work (I don't have time to build this, so PRs welcome) and requires the default to be production while debug mode has to be opt-in, because otherwise we would force all downstream users of xstream to use a __DEV__-like solution, which they may not necessarily have in place (thus hurting their runtime performance).