create a really nice tree-shakable ES module, with flow function

[graingert]

// ES
import * as ix from 'ix/es';

const fn = ix.flow(
  ix.from,
  ix.filter(x => x % 2 === 0),
  ix.map(x => x * x),
);

const results = fn([1, 2, 3]);

for (let item of results) {
  console.log(`Next: ${item}`);
}

[trxcllnt]

@graingert we support importing operators individually at the moment, but we also have work planned to export pipe-friendly variants of each operator.

You can also use the ix/iterable/__modules default export, which I think can be tree-shook automatically (if not, we can change this back to the export * form). We only use this module internally so the operator names survive minification so they're accessible to the tests (setup here), but they're also available in the Ix.internal UMD bundles.

We also recommend using babel-plugin-transform-imports to help decompose large explicit operator imports. Hope this helps!

[graingert]

@trxcllnt the export default is not tree-shakeable.

[trxcllnt]

@graingert no problem then, we can change that easily enough.

It's a default export b/c closure-compiler doesn't work with export *, but considering we don't run the raw ES2015 through CC yet (we'd experimented, but CC ES6 support not ready), we can change it and figure that out later.

[graingert]

@trxcllnt I'd like a true .mjs module available in the package.

[trxcllnt]

@graingert a true .mjs module

do you mind clarifying what you mean? we are publishing the es2015/ESModules compilation target as .mjs in the main ix package:

[graingert]

As apposed to one with a single default export, as in __module

[trxcllnt]

yeah one like this, right?

[graingert]

Yes exactly like that

[trxcllnt]

yeah I said we can do that again

edit: oops, clicked the wrong button

[graingert]

Nice, didn't know it was there

[graingert]

Should I open a new issue for curried, data-last functions?

[trxcllnt]

@graingert nah we already got #23 and #46, so it's planned. would be happy to review a PR if you want to do the manual work of adding all the new pipe-aware impls (and if so, hmu cuz we have thoughts about how to make it less painful), but otherwise it'll happen when we have time.