WIP: (Proposal) fp and pipe operators

[david-driscoll]

Description:
This is a code follow up to #2489. I've currently based this off of @benlesh's changes, however (if needed) we can squash / cherry pick or just recreate it since it's mostly a script anyway.

This adds a script that will automatically generate the code to produce the higher level functions from our prototype methods. This makes it a little easier to manage, as we don't have to actually do anything to get these fp functions working (multicast was an edge case however we could probably sit and make it work if needed).

Related issue (if exists):
#2489, #2034

cc @benlesh @jayphelps @kwonoj @staltz @mattpodwysocki

[rxjs-bot]

	Warnings
⚠️	❗ Big PR (1)

(1) : Pull Request size seems relatively large. If Pull Request contains multiple changes, split each into separate PR will helps faster, easier review.

Generated by 🚫 dangerJS

[david-driscoll]

I predict when this build finishes coveralls is going to totally ✂️ me to pieces!

[coveralls]

Coverage decreased (-1.4%) to 96.291% when pulling 315a1f6 on david-driscoll:moar-fp into bc1e1e5 on ReactiveX:master.

[david-driscoll]

Added in pipe operators (return a function taking an observable) and changed fp operators to take the observable as the first argument in a method.

[coveralls]

Coverage decreased (-2.6%) to 95.045% when pulling 158d198 on david-driscoll:moar-fp into bc1e1e5 on ReactiveX:master.

[staltz]

Okay, this would work. I'm just thinking why have separate fp and pipe sections, we can just choose one (amoung all 3 options) and stick to that, without generated src files.

[david-driscoll]

Right now its just a proof of concept so people can kick the tires on it. So we can make a decision from there. Sometimes I find it easier to see the code and prove it out. 😀

On Fri, Apr 7, 2017 at 3:53 AM André Staltz ***@***.***> wrote: Okay, this would work. I'm just thinking why have separate fp and pipe sections, we can just choose one (amoung all 3 options) and stick to that, without generated src files. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2529 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNdpXD0_5tvRqjetEiX6bo9F6dE-gxGks5rtetggaJpZM4M1A1m> .

-- Thanks, David

[benlesh]

I'm not sure what the fp methodology buys us in the long run. It was looking good forever ago when I started working on "RxNext" to use this as the source observable in operators because I thought the bind operator :: had traction. At this point, I'm not sure either the pipe or bind operator will land in JS proper, so I feel like the pipe-able/let-able operators are the best bet, as they can more easily be composed left-to-right without mucking with the prototype.

In short, I think we should try to guide people to using let variations of operators when possible. Ideally with helpers like pipe or compose.

[mattpodwysocki]

@benlesh what I'm doing over in IxJS land is exactly what David is doing here since I didn't think it was necessary to have the this binding and instead let people use each operator as they want them, so basically the fp branch is my main src branch

[david-driscoll]

Updated PR to purely generate operators on the side (no more commit to source). This also makes the PR a little easier to consume at face value.

@benlesh let isn't going away, however instead of using ::, the fp operators (need to 🚲🏠 that) simply expect the observable as the first value. This full type safety in the context of a call to let.

We can still offer the pipe operators, but they won't have the higher level type safety, in fact this PR contains both.

ie:

import { map } from 'rxjs/fp'; // or 'rxjs/fp/map'
let a: Obserable<number>;
let b: Observable<string> = a.let(o => map(o, n => n.toString() +'s'));

import { map } from 'rxjs/pipe';  // or 'rxjs/pipe/map'
let a: Obserable<number>;
let b: Observable<string> = a.let(map<number, string>(n => n.toString() +'s'));

The pipe operators are better for more functional programmers, but the fp operators are easier to consume for a TypeScript consumer, especially once you start working with anonymous return types. In both cases they are more easy to tree shake.

[davidkpiano]

Just curious (bikeshedding, sorry!), why was let chosen over pipe (or similar)? Makes it difficult to destructure; i.e., can't do const { let } = ..., not to mention that using reserved JS keywords as property/method names in general is risky.

[kwonoj]

@davidkpiano you may able to check ongoing discussion for those at #1958.

[trxcllnt]

@davidkpiano the let name is a holdover from LINQ, but was aliased as letBind at one point. I don't remember when the alias was dropped, but I'd be in favor of adding it back.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.