leisureand those non-lazy libraries is the guarantee that no computations will happen unless the result is actually used. Here's an example:
mapacross the entire list of users. The code will parse 100 addresses. In this trivial example, that computation is likely very fast, but imagine if it were more intensive (say, using computer vision in the browser to detect a landmark). The
filterwill then also run 100 times to find the subset of addresses we are looking for. Then the second
mapwill run 100 more times (admittedly convoluted). The total time of the computation is
mapwould one once on the first user, that resulting address would run once through the
filterand pass, then that address would run once more through the second
map. The total computation would be
O(3). The worst case computation, where there is only 1 match and it is at the very end would be as slow as the original, but every single other permutation would be faster using the lazy approach.
.toArray()to flush the results.
leisurecaps the maximum number of infinite values to
1_000_000. This number is configurable by setting
Seq.MAX_YIELDSto whatever you want your max loop size to be.
leisureimplements the Iterator protocol which means you can use it to lazily pull values using a normal
leisurecan be used as a drop-in replacement for the ES6
reduceAPI. If that's all you need, you can still benefit from the reduction in operations in the non-worst-case scenarios.
leisure's helper methods, you'll be able to write more expressive data computations. With the ES6 API, developers often drop into
reducefor more complex data transformations. These reducer bodies can be difficult to read and understand how they are actually transforming the data.
leisureprovides methods which do these common transformations and names them so your code is more readable. Dropping all the way down into a reducer is quite rare in
yarn perffrom the repository to reproduce these numbers.