Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: (Proposal) fp and pipe operators #2529

Closed
wants to merge 5 commits into from

Conversation

david-driscoll
Copy link
Member

@david-driscoll david-driscoll commented Apr 6, 2017

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
Copy link

rxjs-bot commented Apr 6, 2017

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

Benjamin Lesh and others added 4 commits April 6, 2017 11:31
Allows composition of pipeable operator functions to avoid mutating Observable prototype
Now we can assert that two observables that originated from TestScheduler.prototype.createColdObservable or TestScheduler.prototype.createHotObservable are equivalent with `expectObservable(cold('--a--b--c--|')).toBe(cold('--a--b--c--|'))` This feature was mostly added to test the new pipe operators
@david-driscoll
Copy link
Member Author

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

@coveralls
Copy link

Coverage Status

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

@david-driscoll david-driscoll changed the title Moar fp WIP: (Proposal) fp and pipe operators Apr 6, 2017
@david-driscoll
Copy link
Member Author

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
Copy link

Coverage Status

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

@staltz
Copy link
Member

staltz commented Apr 7, 2017

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
Copy link
Member Author

david-driscoll commented Apr 7, 2017 via email

@benlesh
Copy link
Member

benlesh commented Apr 10, 2017

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
Copy link
Collaborator

@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 david-driscoll force-pushed the moar-fp branch 2 times, most recently from 5b26242 to 6c00d8b Compare April 10, 2017 18:45
@david-driscoll
Copy link
Member Author

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.

generates the new operators using the existing prototype operators, and a script to generate the resulting fp types.
@davidkpiano
Copy link
Contributor

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
Copy link
Member

kwonoj commented Apr 23, 2017

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

@trxcllnt
Copy link
Member

@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
Copy link

lock bot commented Jun 6, 2018

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.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants