Open ftaiolivista opened 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.
One good thing we could do, though, is to ignore null
s that are passed to combinators like merge
and combine
.
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?
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).
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