Document, optimize code size for client-side use?

[Ed Staub]

A frequent PITA with utility libraries like this is bad behavior when trying to optimize code size in webpack, et al. I'm no expert at this, so I can't make specific recommendations. But folks need to know whether the documented import style

import { map } from 'itiriri';

sucks in a lot of irrelevant code in production, and if so, how they should avoid that. If it works great as documented, you should say that, too, so folks like me don't pester you.

[Dumitru]

just added instructions on how to use it on the web, see:
https://github.com/labs42io/itiriri/tree/dev#bundling

Currently it's in the dev branch, but soon it will be merged to master.

[Ed Staub]

Thanks, but I'm afraid that's exactly the opposite of what I was looking for! If I just need map, say, I want to know that webpack treeshaking will prune off everything irrelevant, or if it doesn't, what is the workaround. I'll pull map and its dependencies into a bundle of my own and minify as part of it. If it's only used in a few pages of the app, the bundle may be one that's dynamically loaded for just those pages.

I'm guessing your usage is mostly or entirely server-side. If you've any friends who do client-side work on production-quality single-page applications using react or similar, you might want to talk it up with them to get a better sense of the ecosystem. It's different!

[Dumitru]

Indeed, currently you will reference entire package, it is not possible to use only map without loading the code for all other methods.
However:

1. Do you really mind the size? I think gzip-ed it will be only 2-3KB for the entire power of advanced manipulation with iterables in JavaScript.
2. if you need only one method like map, it's so simple that I'd even not search for it but directly implement it:

// source is an Iterable
Array.from(source).map(...)

The advantage of itiriri, is that it's interface allows you to chain methods. And this is one of the reasons we have to import all the methods.
If we had to optimize it and allow only specific methods to import, then instead of writing:

import { query } from 'itiriri';

// ...
query(source).filter(...).map(...).sort(...).slice(...)

you would have to write:

import { filter, map, sort, slice } from 'itiriri';

// ...
slice(sort(map(filter(source, ...), ...), ...), ...);

Basically this is how it is handled in itiriri under the hoods.
However, we will appreciate and take into account any suggestion on how we can optimize this for client-side usage.

[Ed Staub]

only 2-3KB for the entire [bundle]

+1!

[Theo]

Sorry for necro-ing, but I wanted to add my 2 cents, in regards to this:

slice(sort(map(filter(source, ...), ...), ...), ...);

You could implement a transducer function, e.g pipeline, that takes any number of operators.
(In Ramda this is called compose)

query(source).pipeline(
  filter(...),
  map(...),
  sort(...),
  slice(...)
}

This way you avoid function nest hell and you allow uses to import the operators they need.

P.s: Here's an article of someone doing something similar with RxJS + Typescript Generics, to ensure code completion stays intact: https://dev.to/rasmusvhansen/rxjs-transducer---harness-the-power-of-rxjs-operators-1ai8