reactivex / ixjs Goto Github PK

On rxjs side, they're implementing lettable operators to make it more friendly with tree shaking.
I think it's better that we also consider to accept the way.

After merging #16, almost operators implementations are disabled (commented out) for enable TravisCI once.

Their disabled codes has not been moved to the current design introduced by #11 yet. Thus we need to reimplement them by the new design.

BTW, I feel Ix's basic operator design has not been fixed. We also need to consider it.

How about using iterall by Lee Byron to replace some stuff in IxJS/src/internal?

IxJS version: 2.0.1

Additional information:

flatMap will always emit the inner result, which is sometimes not desired. we can use an optional resultSelector parameter to inject our own result projection using both the inner and outer values.

Do you have any plan to move to TypeScript?

I think there are some benefits

• for generic collections
• to uniform with https://github.com/ReactiveX/RxJS

Before merging any pull request, we should check the build result.

IxJS version: 2.x

Code to reproduce:

Expected behavior:

Actual behavior:

Additional information:

Add prepend and append to IxJS for both AsyncIterableX and IterableX to support n-ary arguments as they are standard .NET LINQ methods.

IxJS version:
2.3.2

Code to reproduce:
npm install ix in windows

Expected behavior:
ix is installed

Actual behavior:

> [email protected] postinstall C:\...\node_modules\ix
> npm i shx && npm run tslib_mjs && npm run tslib_pkg && npm r shx

> [email protected] tslib_mjs C:\...\node_modules\ix
> shx cp $(node -e "console.log(require.resolve('tslib/tslib.es6.js'))") $(node -e "var r=require,p=r('path');console.log(p.join(p.dirname(r.resolve('tslib')),'tslib.mjs'))")

$(node was unexpected at this time.

C:\...\node_modules\ix>  "C:\...\node_modules\ix\node_modules\.bin\\node.exe"  "C:\...\node_modules\ix\node_modules\.bin\\..\shx\lib\cli.js" cp $(node -e "console.log(require.resolve('tslib/tslib.es6.js'))") $(node -e "var r=require,p=r('path');console.log(p.join(p.dirname(r.resolve('tslib')),'tslib.mjs'))")

npm ERR! Windows_NT 10.0.16299
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "tslib_mjs"
npm ERR! node v6.11.4
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! [email protected] tslib_mjs: `shx cp $(node -e "console.log(require.resolve('tslib/tslib.es6.js'))") $(node -e "var r=require,p=r('path');console.log(p.join(p.dirname(r.resolve('tslib')),'tslib.mjs'))")`
npm ERR! Exit status 255
npm ERR!
npm ERR! Failed at the [email protected] tslib_mjs script 'shx cp $(node -e "console.log(require.resolve('tslib/tslib.es6.js'))") $(node -e "var r=require,p=r('path');console.log(p.join(p.dirname(r.resolve('tslib')),'tslib.mjs'))")'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the ix package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     shx cp $(node -e "console.log(require.resolve('tslib/tslib.es6.js'))") $(node -e "var r=require,p=r('path');console.log(p.join(p.dirname(r.resolve('tslib')),'tslib.mjs'))")

Additional information:
Related commit: 4493754

I'm guessing this is due to $(node being interpreted literally rather than as an embedded expression.

IxJS version: 2.0.1

Additional information:

the proto signature defines the outer iterable as a source param, instead of the this param.

Hi!

Are you planning to add a flatten operator for sync and async iterables?

Thanks,
Oliver

IxJS version:

Code to reproduce:

Expected behavior:

Actual behavior:

Additional information:

IxJS, since it's specialty is in I/O problems, that we need explicit conversions to and from Node.js streams. This will intrinsically support backpressure as you do not pull more than you need. We already have AsyncSink which is a Node.js stream already, but we would like a more explicit approach.

export function fromReadableStream(
  stream: Readable, 
  size?: number)
: AsyncIterable<string | Buffer>;

as mentioned in #66

IxJS version:
v2.3.1

Code to reproduce:

import * as Ix from 'ix';
import { Observable } from 'rxjs';
import 'rxjs/add/observable/interval';

Ix.AsyncIterable.from(Observable.interval(100))
  .forEach(x => console.log(`Next ${x}`));

Expected behavior:
It should iterate the values from the observable.

Actual behavior:
No values are iterated.

Additional information:
PR #150 submitted to address this issue.

Do you have any ideas for how an async iterable, transformed using IxJS, can be cancelled by the consumer?

Obviously, async iterables use Promises which are not cancellable.

I'm really starting to wish async iterables used something that did support cancellation, such as Tasks. Then the user could receive an unsubscribe function, just like in RxJS with the Observable type.

Version 1.9.0 of tslib was just published.

This version is covered by your current version range and after updating it in your project the build failed.

tslib is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

IxJS version:
2.1.4

Code to reproduce:

import { Iterable } from 'ix';

// actually false (count is 1)
const shouldBeTrue = Iterable.of('foo', 'bar').distinct().count() === 2;

Expected behavior:
shouldBeTrue should be true

Actual behavior:
shouldBeTrue is be false

Additional information:
the default comparer should have some more comparator fallbacks to better handle strings and objects. I have been using a custom comparer for a while now, it may be a bit overkill but it works really well with whatever you throw at it.

export interface Comparable<T> {
  compareTo(other: T): number;
}

export function isComparable<T>(obj: any): obj is Comparable<T> {
  return (<Comparable<T>>obj).compareTo instanceof Function;
}

export function isString(value: any): value is string {
  return typeof(value) === 'string' || value instanceof String;
}

export function DefaultComparer(a: any, b: any) {
  if (a === b || (a == null && b == null)) {
    // both are null or the same, so equality is zero
    return 0;
  }
  else if (a == null || b == null) {
    // only one is null, non-null takes higher value
    return a == null ? -1 : 1;
  }
  else if (typeof a === 'object' || typeof b === 'object') {
    // if either side is an object then we have failed referencial equality (first compare)
    return -1;
  }
  else if (isComparable(a)) {
    // implements Comparable
    return a.compareTo(b);
  }
  else if (String.isString(a) && String.isString(b)) {
    // native string comparison
    return a.localeCompare(b);
  }
  else {
    // fallback on a basic equality check
    const c: number | undefined = a - b;

    // it's possible that our basic check failed, so default to zero
    return (c == null || isNaN(c)) ? 0 : c;
  }
}

EDIT: forgot to include the object comparer.

This would be nice as a lint.

This would be nice as a lint.

IxJS version: 2.0.1

Additional information:

groupBy will always emit GroupedIterable or GroupedAsyncIterable instances are results, which are sometimes not desired. we can use an optional resultSelector parameter to inject our own result projection into the operator.

Would be great to have one, the RxJS Gitter channel is one of the best and most active I know

It looks like in the chain example we import the object that has a method we want. I think the idea of the example is to assign the map method itself to a variable, rather than assigning it's parent object.

IxJS version:
"ix": "^2.1.4"

Code to reproduce:

// CommonJS
const Iterable = require('ix/iterable').IterableX;
require('ix/add/iterable-operators/chain');
const of = require('ix/iterable/of');
const filter = require('ix/iterable/filter');
const map = require('ix/iterable/map');

const results = of(1, 2, 3)
  .chain(source => filter(source, x => x % 2 === 0))
  .chain(source => map(source, x => x * x));

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

Expected behavior:
output Next 4

Actual behavior:
error message

IxJS version: 2.x

Code to reproduce:

Expected behavior:

Actual behavior:

Additional information:

Add prettier support for nicer code formatting.

Hey there,

Just looking through the code and noticed the following entry inside asynciterable.js:

  var recurse = function () {
    p = e.next().then(function (result) {
      if (!result.done) {
        cb(result.value, i++);
        recurse();
      } else {
        Promise.resolve();
      }
    });
   return p;
  };

Should this instead be?:

  var recurse = function () {
    p = e.next().then(function (result) {
      if (!result.done) {
        cb(result.value, i++);
        return recurse();
      } else {
        return Promise.resolve();
      }
    });
    return p;
  };

I.e.: Shouldn't the function return a promise? This ensures the promise doesn't resolve on the first element.

IxJS version: 2.3.4

Code to reproduce:

import { IterableX as Iterable } from 'ix/iterable'
import { orderBy } from 'ix/iterable/pipe'

const example = Iterable.of({a: 1}, {a: 3}, {a: 2})
    .pipe(orderBy(item => item.a))

Expected behavior:

An imported pipe-able orderBy.

Actual behavior:

There is no orderBy under src/iterable/pipe, so it cannot be imported or used.

Additional information:

This appears to be a simple oversight / missed operator file in the pipe PR.

IxJS version: 2.3.1

Code to reproduce:

// no error, good!
const xs2: Ix.Iterable<number> = Ix.Iterable
    .from(['foo', 1])
    .filter((x): x is number => typeof x === 'number')

// no error, good!
const xs2b: Ix.Iterable<number> = xs2.map(x => x);

// unexpected error, bad!
const xs3: Ix.Iterable<number> = Ix.Iterable
    .from(['foo', 1])
    .filter((x): x is number => typeof x === 'number')
    .map(x => x)

Related #44

Hi!

Are there plans to add a takeUntil operator to this library?

If so, I was wondering if we would have inclusive (take until and including) and exclusive versions (take until and excluding the first falsy predicate).

IxJS version:
2.1.0

Code to reproduce:

// no error, good!
// TypeScript's Array typings support user defined type guards in the filter predicate
const xs: number[] = ['foo', 1].filter((x): x is number => x instanceof Number);

// unexpected error
const xs2: Ix.Iterable<number> = Ix.Iterable
    .from(['foo', 1])
    .filter((x): x is number => typeof x === 'number');

IxJS version: 2.3.4

Code to reproduce:

The README has the following example on how to use lettable operators:

import { IterableX as Iterable } from 'ix/iterable';
import { map, filter } from 'ix/iterable/pipe';

// CommonJS
const Iterable = require('ix/iterable').IterableX;
const { map, filter } = require('ix/iterable/pipe');

const results = of(1, 2, 3).pipe(
  filter(x => x % 2 === 0),
  map(x => x * x)
);

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

A few issues here:

• Where does of come from?
• import { map, filter } from 'ix/iterable/pipe'; does not seem to work. Rather one has to do import { map } from 'ix/iterable/pipe/map'; etc.

Within an Angular/CLI application (in VS Code), ES imports cannot resolve the modules. For example, these imports fail...

import { IterableX as Iterable } from 'ix/iterable';
import 'ix/add/iterable/of';
import 'ix/add/iterable-operators/map';
import { map } from 'ix/iterable/map';
import { filter } from 'ix/iterable/filter';

However, this import does work...

import * as Ix from 'ix';

That, sadly, does not give me access to 'ix/iterable' functions.

Would be nice to have some methods curried (and because of that switched arguments) to align with FP style.

Example:

// Current
const results = of(1, 2, 3)
  .chain(source => filter(source, x => x % 2 === 0))
  .chain(source => map(source, x => x * x));

// Possible with args switched (and curried)
const results = of(1, 2, 3)
  .chain(filter(x => x % 2 === 0))
  .chain(map(x => x * x));

IxJS version

• TypeScript: 2.5.3
• [email protected]

Code to reproduce

tsc -p ./tsconfig.json

tsconfig.json

{
  "compilerOptions": {
    /* Basic Options */
    "target": "esnext",
    "module": "esnext",
    "lib": [
      "es2017",
      "dom",
      "esnext.asynciterable"
    ],

    /* Strict Type-Checking Options */
    "strict": true,
    /* Additional Checks */
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,

    /* Module Resolution Options */
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": false
  },

  "include": [
    "./src/**/*",
  ],

  "exclude": [
    "node_modules"
  ]
}

example.ts

import Ix from 'ix';
Ix.Iterable.from([1, 2]).forEach(console.log);

Expected behavior:

Threre are no error.

Actual behavior:

tsc causes these error:

node_modules/ix/add/asynciterable-operators/flatmap.ts(10,5): error TS6133: 'thisArg' is declared but never used.
node_modules/ix/add/iterable-operators/flatmap.ts(10,5): error TS6133: 'thisArg' is declared but never used.
node_modules/ix/add/iterable-operators/scan.ts(18,3): error TS2322: Type 'IterableX<T | R | undefined>' is not assignable to type 'IterableX<T | R>'.
  Type 'T | R | undefined' is not assignable to type 'T | R'.
    Type 'undefined' is not assignable to type 'T | R'.
node_modules/ix/asynciterable/from.ts(122,36): error TS2345: Argument of type 'TSource | undefined' is not assignable to parameter of type 'TSource'.
  Type 'undefined' is not assignable to type 'TSource'.

Additional information:

• If I use @reactivex/ix-esnext-esm, then there are no error.

Version 1.8.0 of tslib was just published.

This version is covered by your current version range and after updating it in your project the build failed.

tslib is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

@mattpodwysocki There currently isn't any testing harness. Can we add one? I have no preferences on which one, although it should support promises.

IxJS version: 2.3.4

Whilst import { filter } from 'ix/iterable/pipe/filter'; works, import { orderBy } from 'ix/iterable/pipe/orderby'; does not (module does not exist).

I can see the lettable operator defined in the source code (https://github.com/ReactiveX/IxJS/blob/master/src/iterable/orderby.ts), but this is not in the released npm package: https://unpkg.com/[email protected]/iterable/pipe/

Hi there,

I noticed there are some big changes in master pending a release. When can we expect a release?

Thanks!

IxJS version:
2.3.1

Additional information:

createGrouping returns the grouped items as an array instead of an Iterable.

IxJS version: 2.x

Code to reproduce:

Expected behavior:

Actual behavior:

Additional information:

Deprecate the usage of startWith in favor of prepend which will align with Ix .NET and Rx .NET

IxJS version:

Code to reproduce:

Expected behavior:

Actual behavior:

Additional information:

Add combineLatest which mirrors zip but will track the latest from each AsyncIterable input.

function delay(time) {
  return new Promise(res => setTimeout(res, time));
}

async function* delayEvery(value, time) {
  while (1) {
    await delay(time);
    yield value;
  }
}

const s1 = delayEvery(42, 500);
const s2 = delayEvery(56, 1250);

const s3 = combineLatest(s1, s2);
for await (const [fst, snd] of s3) {
  console.log(`{fst} - {snd}`);
}

curious, would it make sense to transpile the gulpfile down to ES5? when I run gulp build, it complains about the ... spread operator

IxJS version: 2.0.1

Additional information:

When i got started with ix while targetting es5 I did not realize that I would need to add some extra libs to the typescript compiler to get things compiling (I had thought I was missing some @types for shims). by adding esnext.asynciterable to lib I was able to bring in the necessary type definitions to squelch the compiler errors. While it didn't take me too long to figure this out, anyone not very familiar with the typescript compilation process might struggle with this. You could also maybe point them to your own source controlled tsconfig.base.json, but i think the only absolutely required lib is esnext.asynciterable (which itself brings in symbol and iterable).

IxJS version: 2.0.1

Code to reproduce: let source: OrderedIterable<number> = Iterable.from([1]).orderBy(x => x)

Expected behavior: No type definition errors on OrderedIterable

Actual behavior: no exported member OrderedIterable<T>

Additional information:

This is useful if we ever need to define an unassigned ordered iterable variable. It's also convenient if we want to re-assign a variable via dynamic chaining (i.e. orderby, if condition thenby).

This ought to be a relatively simple fix. The simple version is to simply export OrderedIterableBaseX as OrderedIterable in the api surface. A slightly more involved fix is to create an actual OrderedIterable interface and export that (though i doubt it provides any benefits over the simple fix).

I've had trouble using the package with a webpack-based build, the reason being that the types are not colocated with the .js files. Here's the line in tsconfig.json that finally made it work:

"paths" : {
            "ix/*": [ "./node_modules/ix/targets/es5/cjs/*", "./node_modules/ix/types/*" ]
        }

How about documenting this better, and even considering shipping with a package that is more "traditional" in structure and works out of the box - similar to the one for rxjs for instance - this would probably ease adoption.

Hi guys,

I have just committed a full re-write of IxJS in TypeScript, complete with several new operators and tests. I followed the RxJS pattern of things (including extending base types, and npm scripts).

Please see here: https://github.com/christyharagan/IxJS

I haven't published any packages yet as I'd like to make the offer of migrating re-write code to this repository.

It works for CJS, AMD, and ES6, has full test coverage (although I'm sure the tests themselves may need beefing up), and linting.

Let me know what you guys think.

I'd also like to propose the generator* extensions for async-iterators to the TypeScript guys, although if the base spec is likely to change a lot, then I'll hold off.

Let me know what you think...

IxJS version: 2.0.1

Code to reproduce: Iterable.from([1]).orderBy(x => x)

Expected behavior: returns an ordered iterable

Actual behavior: property 'orderBy' does not exist on type 'Iterable<T>'

Additional information:

The operator add import is just missing from the api surface, not sure if that was intentional or not.

IxJS version: 2.0.1

Code to reproduce: Iterable.of([1]).some()

Expected behavior: returns true

Actual behavior: expected 1 params, but got 0

Additional information:

pretty simple fix, just change
if (comparer(item, i++)) { return true; }
to
if (!comparer || comparer(item, i++)) { return true; }

IxJS version: 2.x

Code to reproduce:

Expected behavior:

Actual behavior:

Additional information:

Current implementations of takeUntil and skipUntil accept Promise values as parameters which is problematic given their eager nature. Instead, we should look into the following overloads which support AsyncIterator as well as () => Promise<any>.

export function skipUntil<T>(
  source: AsyncIterable<T>, 
  other: () => Promise<any>);

export function skipUntil<T>(
  source: AsyncIterable<T>,
  other: AsyncIterable<any>);

export function takeUntil<T>(
  source: AsyncIterable<T>, 
  other: () => Promise<any>);

export function takeUntil<T>(
  source: AsyncIterable<T>,
  other: AsyncIterable<any>);

IxJS version: 2.0.1

Under the new publishing regime with its breakdown by target and module type, and since I am already using Typescript myself, I would like to see a @reactivex/ix-ts that is simply a package of the Typescript source files without cruft and loadable directly as is. This would allow me to use my project's existing tsconfig.json target and module settings. This would make it easier to be more nimble in my own builds/packs, for example. It also further reduces the possibility space where TS may be able to load the types for the library, but not, for example, webpack find the JS modules and/or vice versa.